3
votes

I recently bought an STM32F7 discovery board [1], and I am therefore trying to flash it using openocd, since the board has an embedded st-link debugger. I have my toolchain working (I am using makefiles and arm-none-eabi-gcc), but I would like to flash the board using eclipse so I can have a graphical debugger.

In order to do so, I installed openocd from their git repo and I launch it with the following config file :

source [find board/stm32f7discovery.cfg]

And then I use the following commands in eclipse with arm-none-eabi-gdb to flash the board :

target remote localhost:3333
monitor flash protect 0 0 11 off
monitor flash erase_address 0x08000000 0x100000
monitor flash write_image erase "/absolute/path/hello-world.hex" 0 ihex
monitor reset halt

I tried different list of commands, including th one from the tutorial I used to set up my debug chain on eclipse [2] or from other SO posts [3][4]. Sometimes the write operation fails, and when it doesn't I end up with a wrong PC (e.g. 0xfffffffe instead of 0x080004ac which is the address if the reset handler). Therefore the CPU will try to execute something that doesn't even exist (outside my memory) and it fails.

Do you have any idea of what might be wrong ? A small precision : I am working on Linux.

Cheers,

Antoine.

[1] : www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641?sc=stm32f7-discovery

[2] : vedder.se/2012/12/debugging-the-stm32f4-using-openocd-gdb-and-eclipse/

[3] : stackoverflow.com/questions/5535110/stm32-gdb-openocd-commands-and-initialization-for-flash-and-ram-debugging

[4] : stackoverflow.com/questions/17003519/stm32f4discovery-openocd-telnet-uploading-demo-program

[5] : github.com/texane/stlink

[Edit]

I also tried to use an st-link program from github [5] and to load with gdb, and I get a similar error :

2016-03-23T09:22:22 INFO src/stlink-common.c: Attempting to write 32768 (0x8000) bytes to stm32 address: 134217728 (0x8000000)
2016-03-23T09:22:22 WARN src/stlink-common.c: Failed to unlock flash!
EraseFlash - Sector:0x0 Size:0x8000
Flash page at addr: 0x08000000 erased
2016-03-23T09:22:22 INFO src/stlink-common.c: Finished erasing 1 pages of 32768 (0x8000) bytes
2016-03-23T09:22:22 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-03-23T09:22:22 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2016-03-23T09:22:23 INFO src/stlink-common.c: Starting verification of write complete
2016-03-23T09:22:23 ERROR src/stlink-common.c: Verification of flash failed at offset: 0
1
You could try texane's st-link program from github instead of openocd. It tends to work pretty well for ST parts. Have you tried doing an explicit hardware reset or power cycle after programming?Chris Stratton
I also tried the st-link from github, and I can't flash my board neither, I always get an error (see edited post). Since I can't program it, it doesn't do anything when I power cycle my board.Antoine
Try using the st-flash command line tool in that, I don't know if flashing from gdb works. You might also check on github for any known issues with that particular chip/board.Chris Stratton
That did not work neither. I solved the problem, please see my answer below :) Thanks for your help !Antoine

1 Answers

1
votes

I managed to solve the problem. It turns out I must have modified the internal option bytes, and this was blocking me when I was trying to flash the board.

I used st-link utility to set them back to their default values, and now everything is working fine ! It is probably possible to use openocd instead, but I haven't tried yet. If someone knows how to do it, it would be nice of him to share it.

For more details on the option bytes, you can have a look at the reference manual [1], page 80 to 83.

[1] : http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/DM00124865.pdf