We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hey all,
I wondered if anyone has any experience with ST's uPSD34XX series of MCU's and debugging them via JTAG through uVision3? The chips have an external debug event pin that can apparently be configured as either an input (to cause a break) or an output (to trigger a scope on a break). ST support hasn't provided much help and I can't seem to find ANYWHERE in the IDE to configure this pin. Does anyone know how this is done?
Best Regards,
Jay Daniel
Hi Jay,
uVision/ULINK uses all uPSD break events for access and execution breakpoints which you set in uVision. There is currently no way to use 'Debug Event Pin' as input or output. Even if you would program the break registers yourself, uVision would overwrite these registers with every application program start/stop.
Hans,
Thanks for the update. I've actually finally heard back from ST that requested that Keil contact their development tools support group in Europe so that you can implement support for this feature. It truly would be useful to be able to configure this pin. I unfortunately designed my product around it to be more debuggable and was disappointed to find that Keil doesn't support its use.
"disappointed to find that Keil doesn't support its use."
Worse than that: according to Hans Schneebauer, they don't just not support it; they actively prevent you from implementing your own support!
If it's true, then they really should know better than that!
"they actively prevent you from implementing your own support" All the break registers must be written whenever a breakpoint changes. Since not all debug event registers can handle all conditions (ranges, access breaks), uVision must assign the breakpoints to the debug event registers every time. As long as we don't have a dialog where uPSD specific debug events can be defined, it is impossible for uVision to not overwrite other break registers which might have been programmed by the user. We have not yet decided whether we will extend this driver in this respect.
Obviously, you'd have my vote to go forward with implementing a uPSD-specific dialog to control the functions of this pin. It would allow for some great flexibility in debugging and hardware design. I'm personally a big fan of this series of 8051-derivatives and would like to see Keil fully support all they've got to offer.
-Jay Daniel