STM32F4 writing to flash does not work about stlink HOT 11 CLOSED

Using flash write blink.bin 0x8000000 I get messages programming pages 0..12, but the final result is -1.
Uploading by stlink fails too, so I imagine the problem is in the common code. I enabled the write retry in stlink-common.c and get "invalid write @0x8000000(8000000):20004000 != 20000c80, retrying" , then errors "writes operation failure count too high, aborting" I imagine this code is already known to work on the VL? I noticed the coreid is the same as the VL, so it must be something else. I was gonna try to debug this, are there any differences known from VL to F4 besides ram and flash size? Maybe a hint of where to start looking?

from stlink.

One difference I noted was that the FLASH Interface Registers on the F4 are located at 0x4002 3C00 as opposed to 0x4002 2000 on the VL. (According to RM0090) There is a #define in src/stlink/stlink_common.c which defines it incorrectly (for the F4).

I have not yet had time to look for any other differences but it would probably be great to use RM0090 and PM0081 manuals and check that all the #defines are correct.

from stlink.

Well it turns out theres lots of differences. I suggest the L be referred to as the F1, since it actually is STM32F1 and the STM32F4, be referred to as the F4. The flash register mapping is all different, the F4 has variable sector sizes, and the controller sequencing is different. Ive implemented a good bit of the code already and can now erase sectors in the F4.

One problem is that the F1 and the F4 both report the same CORE_ID. The old code determined the flash config this way. In order to retain the conditional code for the earlier models I hard coded the CORE_ID to be different than the other two, and added new condtional code based on this spoofed ID. I need another mechanism to determine F1 or F4, so I can conditionally determine the flash config I am dealing with, and not break the earlier versions. A suggestion would be welcome.

from stlink.

I fixed the code in flash.exe to work with the F4. Still todo is clean up some scraps I left in for debugging, I plan to leave them in until I get the gdbserver fixed too. The relevant code is in my fork. Im not too great with git just yet so bear with me while I get that all sorted out. Hopefully I didn't break the other two devices, any feedback is welcome.

from stlink.

I can confirm that jnosky's code for flash works on Linux with the STM32F4 discovery board.

Thanks!

from stlink.

I've also managed to write and read back ~16kB of data. Have not yet been able to actually run a program (Such as the one in examples/blink.

from stlink.

Changing the flash page size in gdbserver from 0x20000 to 0x4000 will allow it to work for up to 64k of code (using my earlier fixes to common code). I still have some more work todo on that, because the page sizes are variable for the F4. None of the examples work because the F4 is so much different. The startup code etc for standalone flash operation all needs updating. The libraries in the repo are not for the F4. Ive got a good chunk of all that fixed, as soon as I get blink flash working, I will push.

from stlink.

jnosky's code has been merged into mainline texane master, bikenomad, are you still having problems, or can we close this ticket?

from stlink.

Did a git pull, rebuilt and tried to flash to my STM32F4 Discovery. After some initial mistakes with options it appears to work fine. Thanks to all!

from stlink.

Texane! Please close this!

from stlink.

From reports, sounds like it's been fixed. Not able to test right now, but closing.

from stlink.