2013-05-29 07:34 AM
Hi, I have an STM32F407IE on a custom board and I am programming/debugging with an Olimex ARM-USB-TINY-H using OpenOCD. I have come across this error with two separate microcontrollers now. It seems as though the microcontroller enter some type of error state while running (I have not had it attached to the debugger when this error happens). Once it occurs, I try running it through the debugger and it refuses to run. When running it through gdb, it gives me the following:
stm32f4x.cpu -- clearing lockup after double faultProgram received signal SIGINT, Interrupt.Using OpenOCD, I can issue a 'reset halt' command to halt the microcontroller, but when I do a 'flash probe 0', I get the following response:device id = 0x10016413JTAG-DP STICKY ERRORMEM_AP_CSW 0x23000051, MEM_AP_TAR 0x1fff7a24STM32 flash size failed, probe inaccurate - assuming 1024k flashflash size = 1024kbytesflash 'stm32f2x' found at 0x08000000If I try to erase the flash and write a new image, I get the following error:auto erase enabledstm32x device protectedfailed erasing sectors 0 to 7in procedure 'flash'I know all of this is specific to OpenOCD, but it seems like this is a hardware issue. It seems like occasionally something is happening to the flash. I am not using any flash-specific calls in code from the stm32f4xx_flash.h library. Does anyone have any suggestions? Any other logging information that I could provide to help? #solution-stm32f407-flash-openocd #jtag #flash-openocd-jtag-sticky-error #jtag-olimex2013-05-29 07:49 AM
All the open stuff is rather half-assed, you do however have the source if you want to dig in. You could perhaps address this with the devs in an OpenOCD forum, but I suspect the response will be disappointing.
The errors are somewhat indicative of a JTAG/SWD communication issue, perhaps also power, clocks, or resets. You might want to try something designed with more rigor, like a Segger J-Link, and see if it spits out any more useful diagnostics, or recovers in a more elegant fashion. As this is a custom board, your biggest hurdle will be to validate your own hardware, and understand what it's doing, and why.2013-05-29 10:28 PM
Something caught my eye:
''stm32x device protected''Could this be the cause of your troubles? The inexpensive ST-LINK/V2 has a nice GUI that can quickly unlock the flash. Ref https://my.st.com/st-extranet-web-active/active/en/catalog/tools/PF251168 Sometimes available from Digikey: http://www.digikey.com.au/product-search/en/programmers-development-systems/in-circuit-programmers-emulators-and-debuggers/2621880?k=st-link
2013-05-30 07:53 AM
custom board ... [most boards work, but] I have come across this error with two separate microcontrollers now
if my edit above is correct, this would be a typical result of a missing pullup/pulldown resistors
2013-05-30 12:39 PM
In my experience JTAG resistors aren't needed on F2 and F4 parts; the internal pullups/pulldowns seem to work fine unless the GPIO settings are altered. I have a custom board with an STM32F205 that works fine (using Segger J-Link) without resistors.
I seem to recall there was some errata on F1 parts about the internal resistors though. Jack Peacock2013-05-30 12:48 PM
2013-05-30 08:43 PM
Recent versions of the OpenOCD software do support the STM32F4xx series. There is a specific target config file for that CPU. Make sure you have it specified in your board config file. For example, I'm using an Olimex H407 demo board with the same JTAG adapter you are and my board file looks like this:
source [find interface/olimex-arm-usb-tiny-h.cfg]source [find target/stm32f4x.cfg]I also have a programming issue with the F407, but it's not the same as yours. I am able to erase and program the first time after OpenOCD is started, but the next time through on the same session results in a programming error:Error: timeout waiting for algorithm, a target reset is recommendedError: error executing stm32x flash write algorithmError: flash write failed = 00000040Error: error writing to flash at address 0x08000000 at offset 0x00000000in procedure 'flash'Error: stm32f4x.cpu -- clearing lockup after double faultThe way around this is to kill the OpenOCD server and restart it. I strongly suspect this is an OpenOCD error, because it was working ok on earlier versions of OpenOCD.2015-01-13 03:19 AM
I had the exact same issue. The fix is in
/ee76e9e1
.