Hello,
I am having a problem where when in debug mode when I stop my application, occasionally when I let it run again interrupts are no longer handled [preventing my application from functioning properly].
This only seems to happen in projects that use the RL-ARM RTOS. Also, whenever this occurs I have noticed that Keil reads in the value of CPSR's 'I' bit as 0 (implying that all interrupts are disabled). Whether or not this problem occurs seems to depend on where I set a breakpoint in my code (there are certain places that I alway see this problem) -- but I cannot for the life of me figure out what is unique about those places (ISRs are typically enabled, the ARM is in user mode, ...)
I should note that if I am not in debug mode, my application works without any problems.
I am using an LPC2468 ARM MCU with Keil RVMD 4.01 and RL-ARM 4.01.
Any pointers would be GREATLY appreciated. This problem makes debugging my application near impossible.
Thanks, Eric
Tamir,
I have seen this before (where UV3 will hang when view RTX Kernel window), but I am not having trouble with it now. I don't know if this was a bug they fixed -- or maybe it is something unique about my configuration (I have RT Agent disabled and only 6 tasks running).
I'll be sure to mention keeping track of the PC - I would find this very useful too.
-Eric
FYI.
http://www.keil.com/forum/docs/thread15486.asp
by Robert Rostohar
Debugging with breakpoints is usually intrusive in respect to the peripherals. The ARM core is stopped when you hit a breakpoint however what happens with peripherals depends on the silicon vendor (integration of the core with peripherals). Majority of peripherals are usually still running also when the core is stopped (some chips like STM32 have special debug registers which configure for some peripherals what happens when the core is stopped).
As far as I know the LPC2xxx peripherals will continue to run also when the core is stopped. This can lead to debugging side effects which alter the behavior of the application being debugged. So you should keep this in mind and not be surprised if the application behaves differently when debugging with stopping the core.
Alternative would be to use a monitor program like RT Agent which allows to access memory even while the core is running (Cortex-M offers this by default - no monitor required).