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
I should also mention that I am using the "ULINK ARM Debugger" with a ULINK 2 pod. We have several pods -- I have tried using a different pod and it does not make a difference.
-Eric
Eric,
Unfortunately I can confirm the existence of this problem (I have it too, frequently with a certain flavor of out product). In addition, often when I enter debug mode (ULINK2, RL-ARM 4.00, uv3) the application stops at a memory address associated with APB peripherals and will do so even after continuing using F5 - I am obliged to relink/reflash to get it work again. I know this has something to do with JTAG clock - putting it on RTCK helps, but not always.
can you run your application on an evaluation board? if so, maybe Keil can reproduce it...?
I never tried this, but does it help if you manually change the I bit in CPSR to 0 ? can you then resume the program ?
Hey Tamir,
Thanks for you replies! I just discovered that the problem is tied to whether or not I am browsing the Vectored Interrupt Controller status registers (from the Peripherals menu). If I do not have this open while debugging, the problem seems to go away.
Also, I tried your idea of modifying that CPSR bit, it doesn't seem to fix anything.
I think I will email Keil Support on this.
Have you noticed that if you stop the debugger while on target, then open the RTX kernel aware window and resume the application, uv3 hangs (don't know about uv4 though)...while you're at it maybe you can report that too :-) ho, and please try to persuade Keil to add the value of the program counter per task to the RTX window. I have more requests but this will do for now :-)
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.
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).
Hi,
I also had the problem that interrupts weren't working after setting a breakpoint in the code. I don't use a kernel. Used interrupts: USB, TIMER0, UART, GPDMA and INT0. What I found out after a long time and changing the ULINK2 adapter because I thought that was broken: This 'feature' depends on the watch window. When no watches were set and after new starting the Keil debug window all worked perfectly. Then I added some variables again to the watch window and it still runs. I can't remember what variable caused this phenomenon.