STM32F4 Discovery flash problems

[jfuller000]

I'm having some problems flashing an STM32F4 Discovery board on linux.
I can read and write fine with the IAR systems demo, or the ST-Link utility on windows.

On linux, I'm using (the latest, although I've tried a few builds) https://github.com/texane/stlink , which can read data out from the chip fine. The file that's read out passes a verify agains the chip.
Output from a read operation is:

Code: [Select]

st-flash read demo1.bin 0x80000000
2013-04-15T17:02:19 INFO src/stlink-common.c: Loading device parameters....
2013-04-15T17:02:19 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413
2013-04-15T17:02:19 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes

However, trying to write to the chip produces this:

Code: [Select]

st-flash write demo.bin 0x80000000
2013-04-15T16:49:11 INFO src/stlink-common.c: Loading device parameters....
2013-04-15T16:49:11 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413
2013-04-15T16:49:11 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
stlink_sram_flash() == -1

I can (usually, although it will sometimes throw up a libusb error) debug the chip, and load a .elf file using arm-none-eabi-gdb

Does anyone have any suggestions? (I can probably work around the problem using the windows software in a virtual machine, but it's not really ideal!)

[bingo600]

Did you erase the flash before programming ?

/Bingo

[jfuller000]

Yes, I've tried running

Code: [Select]

st-link erase before flashing the device, and the result is exactly the same as before.

I've checked using the windows ST-Link tool, and the memory is being erased - so it's only the flash write process that's having problems. 

[mrflibble]

Curious. Your usb permissions look to be okay since you are able to detect the correct stm32f4 in the chain. I've run into several things, but not this particular combination.

You say the write sometimes works, but not reliably....

Two things spring to mind:
1 - try it on a different USB port. yeah yeah it works on windows on this port. do it anyways.
2 -check version of libusb with this command ldd $(which st-link)

I don't think libusb version is too likely, since I checked on my system here and I have st-link compiled against a boring old libusb-1.0.0 (/lib/libusb-1.0.so.0.0.0).
As for swapping usb ports ... I've had issues under linux for st-link + some usb ports on the motherboard. So for my particular case it matters which usb port I use. Most of them work, but some have issues. USB from an Intel chipset tends to have the least amount of issues in my experience.

[andyturk]

openocd?

[jfuller000]

Still not much luck - USB controller is the Intel integrated one. I tried all 10 ports on the laptop(+docking station) with the same results.

ldd reported that st-flash was dependent on (amongst other things) libusb-1.0.so.0, which I certainly have.

I've found a workaround that certainly seems to be acceptable - an alternative to st-link called qstlink2. It has a functional CLI (along with the GUI), and with a bit of tweaking (namely, while the device runs after programming, pressing the reset button halts it - even through a power cycle! There's a function to run the mcu, so I'm just going to make it run that after programming)

Debugging the chip seems to be working fine now, and I've not had trouble loading an .elf file either.

I'm at the point where I can hit "Run" in netbeans and have the chip programmed reliably - so that's all I need.

[jfuller000]

OK, problem found - I was trying to program the flash at address 0x80000000 (8 digits), rather than the correct 0x8000000 (7 digits). I guess that I somehow added a 0, and failed to notice it - which would also explain the intermittent success (I.E. when I missed it out while typing the command!).

Although qstlink2 works fine, it can be a little slow - it erases all flash sectors, whereas st-flash only erases the ones that will be programmed, so I'm happier to be using st-flash.

That seems to have fixed the problem - the programmer is reliable in all usb sockets that I have tried, and it has survived a reboot.

Code: [Select]

$ st-flash write STM32F4-Discovery_Audio_USB_V1.0.0.bin 0x8000000
2013-04-19T19:52:49 INFO src/stlink-common.c: Loading device parameters....
2013-04-19T19:52:49 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413
2013-04-19T19:52:49 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2013-04-19T19:52:49 INFO src/stlink-common.c: Attempting to write 29332 (0x7294) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erasedEraseFlash - Sector:0x1 Size:0x4000
Flash page at addr: 0x08004000 erased
2013-04-19T19:52:49 INFO src/stlink-common.c: Finished erasing 2 pages of 16384 (0x4000) bytes
2013-04-19T19:52:49 INFO src/stlink-common.c: Starting Flash write for F2/F4
2013-04-19T19:52:49 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 29332
2013-04-19T19:52:50 INFO src/stlink-common.c: Starting verification of write complete
2013-04-19T19:52:51 INFO src/stlink-common.c: Flash written and verified! jolly good!