Hi, I finally had some time to look into this again.
> So I conclude there are two problems at play: > > - the firmware on the stm32f4 has to "play well" with swd. Maybe some kind > of initialisation is needed that I'm missing. As Spencer already guessed this has to do with the DBGMCU_CR register and sleep modes. When you use any sleep modes (like WFI or WFE), you have to make sure that the debug section of the core is still clocked. This is not the default to save energy. But when you want to debug, you have to enable it by setting the DBG_STANDBY, DBG_SLEEP and DBG_STOP bits in DBGMCU_CR. The DBGMCU_CR is explicitly mapped on the PPB bus which is available via JTAG/SWD. So I guess STM planned that the regular way to use this is that the debugger enables these bits. But they can be changed by the program too. I did this and all my connection problems went away instantly. This is described in the STM32F4xx reference manual (RM0090) page 1297. > - there is some special initialisation procedure to make it work even with > "non-behaving" firmware on the mcu. The utility from stm does it correctly, > but current openocd (=git head + patches from gerrit) not. "reset_config > srst_only srst_nogate" is not enough. Maybe there are timing restrictions > in the initialisation or reset procedure we have to adhere? I looked into this too: it seems like the reset is activated only for a small part of the initialisation procedure. This can be seen in the log: [...] Debug: 167 9 stm32_stlink.c:665 stm32_stlink_read_memory(): stm32_stlink_read_memory 0xe000ed00 4 1 Debug: 168 10 target.c:1908 target_read_u32(): address: 0xe000ed00, value: 0x00000014 Debug: 169 10 cortex_m.c:1803 cortex_m3_examine(): Cortex-M1 r0p4 processor detected Debug: 170 10 cortex_m.c:1804 cortex_m3_examine(): cpuid: 0x00000014 -> bogus data is read [...] Debug: 231 12 stm32_stlink.c:415 stm32_stlink_assert_reset(): stm32_stlink_assert_reset Debug: 232 12 stlink_interface.c:126 stlink_interface_execute_queue(): stlink_interface_execute_queue: ignored Debug: 233 12 core.c:715 jtag_add_reset(): SRST line asserted -> then the reset line is activated [...] Debug: 248 14 stm32_stlink.c:473 stm32_stlink_deassert_reset(): stm32_stlink_deassert_reset Debug: 249 14 stlink_interface.c:126 stlink_interface_execute_queue(): stlink_interface_execute_queue: ignored Debug: 250 14 core.c:719 jtag_add_reset(): SRST line released -> later reset is released I also hooked up a logic analyzer to SWCLK, SWD and RESET. The trace data confirms what is in the log: several transactions occur prior to the reset. Theses are the ones that are screwed up. So I think to make this work reliably, we have to activate reset from the start. Then we should set the bits in DBGMCU_CR from openocd so that we can continue to access the core even when the programs enables sleep modes later. I will look into the openocd code in the next days and try to make these changes. But I haven't done any coding in openocd itself yet, so maybe someone more familiar with the code can lend me a hand. Kind regards, Gerd ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
