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.
Hello,
I am encountering an issue which is becoming tedious when I am using the Keil IDE (v5) to perform debugging my application.
I am using the Keil IDE v5 environment. The target processor is LPC43xx (Cortex-M4). I am using the startup and system source files provided by Keil. We are using the Keil ULINKpro JTAG interface pod with the setting "ULINK Pro Cortex Debugger". I have tinkered a bit with the "Settings" dialog box but have generally returned most of them to their default selections.
The issue begins when the IDE is executing through the source file "system_LPC43xx.c" (provided by Keil: c:/Keil/ARM/Startup/NXP/LPC43xx). When performing a "Run to breakpoint", the IDE will not stop at the breakpoint claiming that it is unable to stop the Cortex-M target. I usually can coax the IDE to begin again and subsequently perform "line-by-line" debugging. The IDE will continue to trace through each instruction but eventually fails to return from one of the line executions. The error condition is the sames as given above. Additionally, I also encounter the error message, "Cannot access target. Shutting down debug session". This issue appears to occur during the execution of the function "SetClock()" (in the system_LPC43xx.c file).
I have reviewed at least some of the Keil on-line documentation and have found values that will work for me. I am interested in finding a group of setting for the debugging that will allow me to continue on with my work (arg.......!). Any future attempts to re-invoke the IDE debugger will result in a NO-GO (Can
It is interesting to note that the LPC-Link2 debugging interface does not exhibit this behavior, so I can only imagine that my debugging settings are not valid. It should be noted that the core frequency does change as it is ramped up from the original 12MHz to the current frequency of either 96MHz or 204Mhz. So...setting the core frequency for 10 or 12 MHz does not appear to be a valid selection as the program progresses through its paces.
So far, the very expensive ULINKpro debugger appears to be flaky! I must have one or more of a thousand selections incorrect. As I have said, I have reviewed the on-line Keil documentation for setting up the debugging selections, but it does not seem to address this issue.
Again...for clarity....I am using the Embedded Artists LPC43xx evaluation kit and the Keil IDE (v5) environment. The target is the NXP LPC43xx Cortex-M4 micro-controller.
I can provide screen shots of these settings and selections if it is deemed necessary. I am not sure that this posting service will allow it.
Any suggestions....help!
Not sure what settings are relevant for your processor, but it sounds like you are changing one of the clocks controlling the clocking of the JTAG interface. Wrong clock settings is a well-known way to lose JTAG connectivity.
Hello Westermark,
Thank you for your reply.
Are you saying that I can not change the core clock during program execution? If not, how would I raise the frequency for the power-up default to the higher steady-state frequency?
Regards,
Rob
I'm not really sure for your chip. You need to check for any graph of clock routing for the chip. Or consider asking NXP or Keil.
But failing the clocking for the JTAG interface when reprogramming PLL etc is a strong reason why that type of action should always happen late enough (even if a dummy delay is needed) to make sure that the user have time to stop the processor in case the clocking code overclocks the processor or hangs the JTAG interface.
Rob;
NEVER attempt to step through start-up code or any code that might be interrupted with an ISR. Always use the Run To Cursor mode. That will allow a Timer ISR to service the interrupt and then return to your debug code.
Bradford
Bradford,
Thanks for the info. I am still learning how to use the Keil IDE.
I have not encountered these issues while debugging with the Stellaris (lm3s3748) or the LPC43xx using the LPC-Link2 debugging pod.
Thanks again.