On Friday 26 March 2010, Martin Zenzes wrote: > Hi! > > I'm have some problems/oddities using openocd (0.5.0-dev-00128-g721502f) > with an "Olimex Ltd. OpenOCD JTAG" adapter and a STM32-CPU. Finally, I > figured out how to get a connection with ddd/gdb, but one point stays > unclear for me: > > I can't stop a running core with "reset halt". This is what it looks > like with fresh-booted chip on a telnet connection:
I tried this with two non-STM32 Cortex-M3 cores ... works for me, no problems stopping. Might this be specific to STM32? (odd, if so...) Maybe related to http://sourceforge.net/apps/trac/openocd/ticket/5 Alternatively, does your reset_config enable SRST? If it doesn't, poking cores executing WFI or WFE instructions will be futile in most cases ... they stop the clock used for JTAG and thus OpenOCD won't be able to tell the NVIC to reset the chip. This partial log isn't much help for diagnosing things, by the way... better would be full server startup messages. > Open On-Chip Debugger > > init > > stm32.cpu curstate > running > > reset > JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: > 0xba00, ver: 0x3) > JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: > 0x6414, ver: 0x0) > > stm32.cpu curstate > running > > reset halt > JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: > 0xba00, ver: 0x3) > JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: > 0x6414, ver: 0x0) > Halt timed out, wake up GDB. > timed out while waiting for target halted > TARGET: stm32.cpu - Not halted > Command handler execution failed > in procedure 'reset' called at file "command.c", line 650 > called at file "command.c", line 361 > > > > However, I am able to halt the chip issuing a "soft_reset_halt" before > the "reset halt" (in a script, I have to add some sleeps): > > > init > > stm32.cpu curstate > running > > soft_reset_halt > requesting target halt and executing a soft reset > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x00000f64 msp: 0x20005000 > > stm32.cpu curstate > halted > > reset halt > JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: > 0xba00, ver: 0x3) > JTAG tap: stm32.bs tap/device found: 0x06414041 (mfg: 0x020, part: > 0x6414, ver: 0x0) > target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x00000f64 msp: 0x20005000 > > stm32.cpu curstate > halted > > The same counts for "reset init". > > Why this? I heard from a collegue, who used a very early version of > openocd, that this sequence worked for him with the very same hardware. > But the old SVN is dead and I can't test this. However, since I can work > around this in the moment (soft resets before hard reset), I suppose > that this is not a real problem for me right now? I'm just beginning to > use this kind of technology, I don't know what is expecting me... > > I know from the manual, that a hard reset resets "harder" than a soft > reset (some registers can be written to during bootup or something...) I've never had occasion to use "soft reset_halt"; For Cortex-M3 a quick glance suggests that if that works, a "real halt" shoul work too. - Dave > -- I have to keep that in mind. > > Greetings > Martin _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
