OpenOCD or AttolicGDB flash error with STM32F030 (F05x ok)

[hub]

Posted on September 24, 2014 at 09:37

We have good experience with STM32f100, STM32F05x but for our new product we used STM32F030 and I am not able to program it over GDB. The interesting think is that F05x can be programmed over GDB without errors (monitor reset halt, then load and it is programmed). Is there something special with SWD on F030 devices?

F030 works perfectly over ST-link utility (I use ST-link programmer - tried v1 and v2 result is the same), I can download compiled binary and my program works, but I need also to debug. I use Atollic GDB server which crashes when I send ''monitor reset halt'' command. When I use OpenOCD I get luckily more information, see below. monitor reset halt ========== OpenOCD: C:\Users\mhubacek\Downloads\openocd-0.8.0\openocd-0.8.0\bin>openocd -f stm32f0di scovery.cfg Open On-Chip Debugger 0.8.0 (2014-04-28-08:39) Licensed under GNU GPL v2 For bug reports, read         http://openocd.sourceforge.net/doc/doxygen/bugs.html srst_only separate srst_nogate srst_open_drain connect_deassert_srst Info : This adapter doesn't support configurable speed Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 2.929224 Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints Info : accepting 'gdb' connection from 3333 Info : device id = 0x10006444 Info : flash size = 32kbytes Error: timed out while waiting for target halted TARGET: stm32f0x.cpu - Not halted in procedure 'reset' GDB client: C:\kepler\workspace\stm32f0_sb9\Debug>arm-none-eabi-gdb GNU gdb (GDB) 7.2.50.20100908-cvs Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.  Type ''show copying'' and ''show warranty'' for details. This GDB was configured as ''--host=i686-mingw32 --target=arm-none-eabi''. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (gdb) target remote localhost:3333 Remote debugging using localhost:3333 0x08001d4e in ?? () (gdb) monitor reset halt timed out while waiting for target halted TARGET: stm32f0x.cpu - Not halted in procedure 'reset' (gdb) So it seems that I am not able to reset the core, if I download my code with ST-link and then use command ''monitor halt'', the application really halts. So I thougt that maybe if I dont use reset command... monitor halt load ===== OpenOCD For bug reports, read         http://openocd.sourceforge.net/doc/doxygen/bugs.html srst_only separate srst_nogate srst_open_drain connect_deassert_srst Info : This adapter doesn't support configurable speed Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 2.940605 Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints Info : accepting 'gdb' connection from 3333 Info : device id = 0x10006444 Info : flash size = 32kbytes undefined debug reason 7 - target needs reset target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x21000000 pc: 0x080018e0 msp: 0x20000fc0 Error: timed out while waiting for target halted TARGET: stm32f0x.cpu - Not halted in procedure 'reset' Error: Target not halted Error: failed erasing sectors 0 to 7 Error: flash_erase returned -304 GDB (gdb) monitor halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x21000000 pc: 0x080018e0 msp: 0x20000fc0 (gdb) load stm32f0 stm32f0.map      stm32f0_sb9.elf  stm32f0_sb9.map (gdb) load stm32f0_sb9.elf Error erasing flash with vFlashErase packet (gdb) When I use load, it seems that the target is not halted. At this point I have no idea what can be wrong. Is there something special in F030? Hardware watchdog? If I open ST-link utility the all checkboxes are checked (factory default) which tells me that watchdog has to be turned on by software, I down use watchdog in my app. My board uses F030 without external crystal, BOOT0 is grounded (same as with F05x on my discovery board which works) #stm32f030 #openocd #stm32f03

[Tesla DeLorean]

Posted on September 24, 2014 at 14:26

How is NRST/NRESET wired?

Is BOOT0 physically attached to ground, or pulled low? Does the behaviour change if pulled high? Not sure there are much differences between F03 and F05 parts, older software may not support newer parts. If the code in the part changes the pins or goes into low power mode, you'd want the debugger to ''connect under reset''

[hub]

Posted on September 24, 2014 at 15:06

>How is NRST/NRESET wired?

/RST pin is connected via RC to 3v3.

>Is BOOT0 physically attached to ground, or pulled low? Does the behaviour change if pulled high? BOOT0 directly to ground, behaviour does not change when its floating or pulled high (even the code runs when is in flash no matter what BOOT0 is set to). To set logic one to the BOOT0 I used 330ohm resistor to 3v3. Also VDDA is connected correctly to 3v3. There is no code in the chip. I cleared the chip with ST-link utility before any test above.

[hub]

Posted on October 21, 2014 at 16:46

Solved with GDB server from Em::Blocks.

Still have no idea what was wrong with OpenOCD.