STM32F4 Discovery - can't flash-program device

[pacman]

Posted on December 17, 2014 at 08:31

(Note: I'm experienced with flash-programming microcontrollers from other vendors, but this is my first go with STM)

I have a STM32F4 Discovery board (with a STM32F407VGT6 fitted).I use GCC-4.8.3 with OpenOCD-0.9.0.So far, I've gotten the drivers to build with no errors and warnings (I had to modify them and clean the code).But when it comes to flash-programming, I had some problems where I got a 'write-protected' error from OpenOCD. After messing around with it, I found out that I should remove 'unlock' and 'erase' from this line...

flash write_image erase unlock file_to_flash.elf

...so it becomes ...

flash write_image file_to_flash.elf

...and it seems that OpenOCD sends the data to the microcontroller.-But where do the data end up ?The LED-animation stops (expected after a RESET / HALT), but my program does not seem to start.In OpenOCD, I can do a ...

mdw 0x20000000 32

...and a...

mdw 0x10000000 32

...but both...

mdw 0x00000000

...and...

mdw 0x08000000

fails with the message:

in procedure 'mdw'

-Nothing else. This suggests that OpenOCD had some kind of (read) access-error, and could not read the data from the Flash memory.All that said, This is the output I get from OpenOCD:

Open On-Chip Debugger 0.9.0-dev-00101-gb15a0ee (2014-11-27-08:50)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

jtag_ntrst_delay

♯♯♯ Flashing/Board/stm32f4.cfg

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 1000 kHz

adapter_nsrst_delay: 100

&sharp0 : stm32f4x.flash (stm32f2x) at 0x00000000, size 0x00000000, buswidth 0, chipwidth 0

runNow

Info : clock speed 1000 kHz

Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 2.893577

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash

Info : flash size = 1024kbytes

wrote 1020 bytes from file output/STM-test8.elf in 0.162985s (6.112 KiB/s)

shutdown command invoked

-I suspect that the file I sent was only transferred to the STM32F4's RAM (although my disassembly clearly indicates that the code should go to 0x08000000, which I understand is where the Flash-memory is located) #openocd #stm32f4-discovery #flash_cr-flash_keyr-lock #mass_erase-unlock #nwrp #optcr #unlocked-writable-solution

[Tesla DeLorean]

Posted on December 17, 2014 at 15:59

Are you familiar with Windows, and do the ST provided ST-LINK Utilities function correctly? If so you should probably pursue support for OpenOCD through it's support/developer community.

[pacman]

Posted on December 17, 2014 at 20:04

Hi Clive.

Thank you for the quick reply. Sorry, I'm not able to run Windows (and have only very little experience with it).

(Note: I have only PowerPC based Macintosh, thus I had to write my own IDE and build GCC+OpenOCD myself)

I'm already subscribed to the OpenOCD developer list. I could be wrong, but I believe this might be an issue with the board, more than it's an OpenOCD issue, as it works very well with the other devices I've been using. When I searched for a solution to the problem on the Web and in this forum, I came across a few similar problems; they gave me hints, but not specific solutions. At first, the board seemed to be write-protected; I could read the hardware registers using the mdw command; thus I read the FLASH_CR register, unlocked it manually by writing the unlocking sequence to FLASH_KEYR (as in RM0090 section 3.6.1), and saw that the LOCK bit was cleared. -But OpenOCD issues this sequence already, so it was completely obsolete to do this manually. Update: I just tried the standard OpenOCD 'program' script, which gave me the following output:

$ openocd -f board/stm32f4discovery.cfg -c ''program output/STM-test8.elf verify reset''

Open On-Chip Debugger 0.9.0-dev-00101-gb15a0ee (2014-11-27-08:50)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 1000 kHz

adapter_nsrst_delay: 100

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : clock speed 1000 kHz

Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 2.889882

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

** Programming Started **

auto erase enabled

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash

Info : flash size = 1024kbytes

Error: stm32x device protected

Error: failed erasing sectors 0 to 0

** Programming Failed **

shutdown command invoked

The output is very similar to the previous output. The reason it fails is that it's issuing an 'erase' along with the flash image_write (as I mentioned previously). I've

/public/STe2ecommunities/mcu/Lists/STM32Discovery/Attachments/12870/STM-test8.tar.gz

, in case someone want to try flash-programming a board using the same commands I used. If instead of flashing the .elf file, I try flashing the .bin file, I get slightly different output:

$ openocd -f board/stm32f4discovery.cfg -c ''program output/STM-test8.bin verify reset''

Open On-Chip Debugger 0.9.0-dev-00101-gb15a0ee (2014-11-27-08:50)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 1000 kHz

adapter_nsrst_delay: 100

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Info : clock speed 1000 kHz

Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 2.891873

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

** Programming Started **

auto erase enabled

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash

Info : flash size = 1024kbytes

Warn : no flash bank found for address 0

wrote 0 bytes from file output/STM-test8.bin in 0.012019s (0.000 KiB/s)

** Programming Finished **

** Verify Started **

Error: timed out while waiting for target halted

target state: halted

target halted due to debug-request, current mode: Thread

xPSR: 0x81000000 pc: 0x2000000e msp: 0xfffffffc

Error: error executing cortex_m crc algorithm

** Verify Failed **

** Resetting Target **

shutdown command invoked

________________ Attachments : STM-test8.tar.gz : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzpZ&d=%2Fa%2F0X0000000bQ5%2FEl.bOF8GvVk18F1AnbsAgHMafAGwDoNQ_JeWOD8C3FM&asPdf=false

[Tesla DeLorean]

Posted on December 17, 2014 at 20:56

I could be wrong, but I believe this might be an issue with the board..

Does it effect more than one of them? The DISCO's only support SWD mode, not full JTAG, and most of them have PB3 (SWO) used for SWV applications run through a solder-bridge which is not consistently made across the DISCO series. And one supposes the've shipped several hundreds of thousands of boards with this same design. I'd focus on your software and how it's configured/connected. My boss would send me to Walmart to pick up a cheap Windows laptop for a few hundred dollars than spend man-hours/days fighting with something.

[pacman]

Posted on December 18, 2014 at 01:17

I'm using hla_swd (via the built-in stlink-v2).

My reason for believing that it's not a problem with OpenOCD, is that there are a lot of STM32F4 Discovery users, who can successfully flash-program their boards.Since I could not find anyone having the same problem as me, I am convinced that the problem may have to do with some board protection OR of course, it could be a Big Endian problem in OpenOCD (although the OpenOCD team spent quite a lot of time fixing BE problems).As I have only a single DISCO board, I have no chance of testing other boards at the moment. I'm planning on getting some STM32F427 as raw components in a couple of weeks, though; then I'll solder them on a breadboard adapter.My test-program is very minimal (it's attached to the previous post).Even if there was a bug in my code, causing it to HardFault, I doubt it would affect the problem described.-Remember: After flashing the board, and OpenOCD says 'success' (without verifying the data), the LED animation (PD12-PD15) is stopped. When I turn off the power and turn on the power for the board, it re-starts the demo, which means that the demo is not erased, thus my test-firmware must have gone to /dev/null or the big (void).I definitely understand your boss; but unfortunately the few hundred dollars have already been spent on development in this case... ;)-Luckily, Mac OS X is UNIX. That means there's virtually no difference between using Mac OS X and Linux for writing/flash-programming microcontroller firmware.

[macfrenz]

Posted on December 21, 2014 at 20:14

I tried flashing your files to a working Disco board. The bin file didn't flash at all, and the elf file flashed but any LEDs didn't blink. That leads me to believe that it's a problem with your code or linker script. I'd suggest that you wrote a minimal LED blinking program, stripping away everything unnecessary, and try with that...

[pacman]

Posted on December 22, 2014 at 19:30

Thank you so much, John, for helping out. :)

At the moment, I am stuck before the flash-point (eh).The OpenOCD team is helping me pinpoint the exact cause.I can 'unlock' the device, but when I try to 'mass_erase', the operation fails with a 'device protected' error.-That means that I will need to have this issue resolved, before I can attempt flashing the device.1: I get an error, if I try flashing the .elf file (about flash bank 0x10000000 does not exist)2: If I try flashing the .bin file, I get no error (the operation actually returns 'success'), but when I look at the flash memory, all bits are set (the entire flash memory contains 0xffffffff).-I'll try simplifying and reducing the LED-blinker (that's actually what this small program was intended to be).

[macfrenz]

Posted on December 22, 2014 at 20:29

Still it could be a faulty linker script, hence I suggested stripping everything unnecessary away from the linker script. The STM chip has some regions that aren't meant to be written by programmer, and the error messages might be because openocd is for some reason trying to write to them.

You mentioned about error that flash bank doesn't exists at 0x10000000. If you look at devices memory map you see that it is correct, the flash is at 0x0800 0000 - 0x080F FFFF .

[pacman]

Posted on December 23, 2014 at 00:27

(Note: I updated this post with a new attachment, unfortunately this resulted in the history being messed up; I'm sorry for that. The error is now found and fixed; the included attachment should work.)

You're absolutely right, but I would still expect that OpenOCD didn't complain about writing to RAM (which to my understanding, address 0x10000000 is). This evening, I tried dumping some of the hardware registers, and I've posted my findings to the OpenOCD list. To me it seems that the values of the OPTCR and OPTCR1 are both incorrect; however, as I'm not very experienced with the 407 yet, I can't say for sure; here's a snip from my post:

0x40023C14, OPTCR: 00aaaae1 (looks strange)

0x40023C18, OPTCR1: 110000c0 (looks even more strange)

Notice the first 0xAAA; they're the nWRP bits. To me it looks like protection is enabled for every 2nd sector, which means I would never be able to write to the Flash memory, as long as the option bits are configured this way. -But still I might be completely wrong here. Note: I would expect the 0xAAA to be either 0xFFF or 0x000. The 0xAA for the Read-protection would be correct, though. What does the following commands give you ?

> mdw 0x40023C14

> mdw0x40023C18 -If your results differ, those values might help hinting whether the values that OpenOCD writes are correct or not. I've

/public/STe2ecommunities/mcu/Lists/STM32Discovery/Attachments/12927/STM-test9.tar.gz

again,it simplified in the following ways: 1: Instead of a main() function, I now directly execute the code from the Reset_Handler. 2: It does not use any macros for LED values or port values (except from the STM definitions) 3: It writes values directly to hardware registers, resulting in very short code. 4: No RAM section is used, so everything should go into the Flash memory. 5: Only the STM-test9.c file, the startup.c file and the library files needs to be compiled. 6: A snort disassembly is included. 7: The project is tested and the device is flash-programmed. The linker script is the same as before. ________________ Attachments : STM-test9.tar.gz : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzpP&d=%2Fa%2F0X0000000bQ6%2F6r5NC9YmmNNPKBw6Ugr.Z1xAC2sBRQoGNaAAvf_Haz0&asPdf=false

[macfrenz]

Posted on December 23, 2014 at 12:09

> You're absolutely right, but I would still expect that OpenOCD didn't

> complain about writing to RAM (which to my understanding, address > 0x10000000 is). 0x1000 0000 is CCM (core coupled memory) data ram. On F4 devices it isn't connected to instruction bus, meaning that you can't execute code from it. If you want to execute code from internal RAM in must be stored to SRAM1. I'm not sure if OOCD is supposed to issue errors, though... > This evening, I tried dumping some of the hardware registers, and > I've posted my findings to the OpenOCD list. To me it seems that the > values of the OPTCR and OPTCR1 are both incorrect; however, as > I'm not very experienced with the 407 yet, I can't say for sure; > here's a snip from my post:

> 0x40023C14, OPTCR:      00aaaae1 (looks strange)

> 0x40023C18, OPTCR1:     110000c0 (looks even more strange)

OPTCR1 register doesn't exist on 407 -devices. > Notice the first 0xAAA; they're the nWRP bits. To me it looks like > protection is enabled for every 2nd sector, which means I would > never be able to write to the Flash memory, as long as the option > bits are configured this way. -But still I might be completely wrong >here. Note: I would expect the 0xAAA to be either 0xFFF > or 0x000. The 0xAA for the Read-protection would be correct, > though. What does the following commands give you ?

> > mdw 0x40023C14

> > mdw 0x40023C18 > -If your results differ, those values might help hinting whether the > values that OpenOCD writes are correct or not. According to mdw command my device's OPTCR register is at reset value, 0x0FFF AAED. Have you tried issuing ''stm32f2x unlock 0'' on openocd? Also make sure you have latest version of oocd.