On Wed, Jul 6, 2011 at 11:02 AM, Luc ANTOLINOS <[email protected]> wrote: > Hi, > I'm working with an LPC2388 (arm7tdmi-s core). I use the "IDLE" power mode > to stop the arm core to reduce power consumption. All IT and peripheral are > still ON in this mode, only the arm core is sleeping. > > The problem is when we want to use our probe (Olimex ARM-USB-OCD) with > OpenOCD (0.5.0 from git 2011-05-20) we obtain an error message if the > software already running on the board is using the IDLE mode : > JTAG scan chain interrogation failed: all zeroes > Check JTAG interface, timings, target power, etc. > Trying to use configured scan chain anyway... > Bypassing JTAG setup events due to errors > > I the software running on the CPU doesn't use the power reduction mode (arm > core is still ON in this case) then I have no problem with the jtag. The > problem seams to be related only to the power mode. > > Whatever the openocd command I use (reset, halt, soft_reset_halt, resume > 0x00) openocd error is like : > "Halt timed out, wake up GDB. > timed out while waiting for target halted > in procedure 'halt'" > > If I try to directly write to the CPU register to disable the IDLE mode, i > get (a normal error message): > "Target not halted" > So I can not disable the IDLE mode with my jtag. > > I have to use the CPU integrated bootloader to reload a software with no > IDLE mode through the RS232 link before I can use my Jtag again. > > I've seen other messages related to this point on the ML but has anyone > found a solution to this problem ?
>From OpenOCD Manual Chapter 5.6 Target Software Changes : ARM Wait-For-Interrupt... Many ARM chips synchronize the JTAG clock using the core clock. Low power states which stop that core clock thus prevent JTAG access. Idle loops in tasking environments often enter those low power states via the WFI instruction (or its coprocessor equivalent, before ARMv7). You may want to disable that instruction in source code, or otherwise prevent using that state, to ensure you can get JTAG access at any time. For example, the OpenOCD halt command may not work for an idle processor otherwise. As a more polite alternative, some processors have special debug-oriented registers which can be used to change various features including how the low power states are clocked while debugging. The STM32 DBGMCU CR register is an example; at the cost of extra power consumption, JTAG can be used during low power states. Chapter 6.2.4 Warning: On most ARMs, JTAG clock detection is coupled to the core clock, so software using a ‘wait for interrupt’ operation blocks JTAG access. Adaptive clocking provides a partial workaround, but a more complete solution just avoids using that instruction with JTAG debuggers. Chapter 15.2 Target State handling Warning: On ARM cores, software using the wait for interrupt operation often blocks the JTAG access needed by a halt command. This is because that operation also puts the core into a low power mode by gating the core clock; but the core clock is needed to detect JTAG clock transitions. One partial workaround uses adaptive clocking: when the core is interrupted the operation completes, then JTAG clocks are accepted at least until the interrupt handler completes. However, this workaround is often unusable since the processor, board, and JTAG adapter must all support adaptive JTAG clocking. Also, it can’t work until an interrupt is issued. A more complete workaround is to not use that operation while you work with a JTAG debugger. Tasking environments generaly have idle loops where the body is the wait for interrupt operation. (On older cores, it is a coprocessor action; newer cores have a ‘wfi’ instruction.) Such loops can just remove that operation, at the cost of higher power consumption (because the CPU is needlessly clocked). Chapter 22 FAQ You can still debug the ’low power’ situations - you just need to either use a fixed and very slow JTAG clock rate ... or else manually adjust the clock speed at every step. (Adjusting is painful and tedious, and is not always practical.) It is however easy to “code your way around it” - i.e.: Cheat a little, have a special debug mode in your application that does a “high power sleep”. If you are careful - 98% of your problems can be debugged this way. Note that on ARM you may need to avoid using the wait for interrupt operation in your idle loops even if you don’t otherwise change the CPU clock rate. That operation gates the CPU clock, and thus the JTAG clock; which prevents JTAG access. One consequence is not being able to halt cores which are executing that wait for interrupt operation. BR, Drasko _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
