New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F4 writing to flash does not work #12

Closed
bikeNomad opened this Issue Oct 20, 2011 · 11 comments

Comments

Projects
None yet
6 participants
@bikeNomad
Copy link
Contributor

bikeNomad commented Oct 20, 2011

I'm seeing the same flash write problems described earlier.

I can debug in SRAM fine.

I updated to "master 56c4ba7 [merge] patches from uwe".
Re-built library, gdbserver, and flash tool (after fixing code in flash tool).
Ran the gdbserver as:

ned@linux-asus:~/src/stlink$ gdbserver/st-util usb /dev/stm32l_stlink2 

Then ran arm-none-eabi-gdb on the blink_flash example:

ned@linux-asus:~/src/stlink/example/blink_flash$ arm-none-eabi-gdb blink.elf
GNU gdb (Sourcery G++ Lite 2010.09-51) 7.2.50.20100908-cvs
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi".
Reading symbols from /home/ned/src/stlink/example/blink_flash/blink.elf...(no debugging symbols found)...done.
(gdb) tar ext :4242
Remote debugging using :4242
0x0800422c in ?? ()
(gdb) load
Loading section .isr_vector, size 0x10c lma 0x8000000
Loading section .text, size 0x9c lma 0x800010c

And then it never came back to me.

The output from the gdbserver debug was this:

stlink current mode: mass
*** looking up stlink version
st vid         = 0x0483 (expect 0x0483)
stlink pid     = 0x3748
stlink version = 0x2
jtag version   = 0xe
swim version   = 0x0
    notice: the firmware doesn't support a swim interface
stlink current mode: mass
stlink current mode: mass

*** stlink_enter_swd_mode ***

*** stlink_read_mem32 ***
data_len = 4 0x4
 11 64 00 20


*** stlink_core_id ***
data_len = 4 0x4
 77 14 a0 2b

core_id = 0x2ba01477
Fixing wrong chip_id for STM32F4 Rev A errata
Chip ID is 00000413, Core ID is  2ba01477.
Device connected: F4 device
Device parameters: SRAM: 0x20000 bytes, Flash: up to 0x100000 bytes in pages of 0x20000 bytes

*** stlink_read_mem32 ***
data_len = 4 0x4
 22 00 2d 00

Flash size is 34 KiB.

*** stlink_force_debug_mode ***

*** stlink_reset ***

*** stlink_write_mem32 ***
KARL - should read back as 0x03, not 60 02 00 00

*** stlink_read_mem32 ***
data_len = 4 0x4
 61 02 00 00


*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_read_mem32 ***
data_len = 4 0x4
 01 00 00 00


*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***
Listening at *:4242...
GDB connected.

*** stlink_read_all_regs ***
data_len = 84 0x54
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 0c 00 20 ff ff ff ff 2c 42 00 08 00 00 00 01 80 0c 00 20 00 00 00 00 00 00 00 00 00 00 00 00

xpsr       = 0x01000000
main_sp    = 0x20000c80
process_sp = 0x00000000
rw         = 0x00000000
rw2        = 0x00000000

*** stlink_read_mem32 ***
data_len = 4 0x4
 04 48 01 68


*** stlink_reset ***

*** stlink_read_mem32 ***
data_len = 4 0x4
 00 00 00 00


*** stlink_read_mem32 ***
data_len = 4 0x4
 00 00 00 00


*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_read_mem32 ***
data_len = 4 0x4
 00 00 00 00


*** stlink_read_mem32 ***
data_len = 4 0x4
 00 00 00 00


*** stlink_write_mem32 ***

*** stlink_write_mem32 ***

*** stlink_write_mem8 ***

*** stlink_write_reg
data_len = 2 0x2
 80 00


*** stlink_write_reg
data_len = 2 0x2
 80 00


*** stlink_write_reg
data_len = 2 0x2
 80 00


*** stlink_write_reg
data_len = 2 0x2
 80 00


*** stlink_write_reg
data_len = 2 0x2
 80 00


*** stlink_read_mem32 ***
data_len = 4 0x4
 00 00 00 00


*** stlink_write_mem32 ***

*** stlink_run ***

*** stlink_status ***
data_len = 4 0x4
 80 00 00 00

  core status: running

*** stlink_status ***
data_len = 4 0x4
 80 00 00 00

  core status: running

The stlink_status messages repeated ad infinitum until I killed the server.

@jnosky

This comment has been minimized.

Copy link
Contributor

jnosky commented Oct 27, 2011

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?

@lbuchy

This comment has been minimized.

Copy link

lbuchy commented Oct 27, 2011

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.

@jnosky

This comment has been minimized.

Copy link
Contributor

jnosky commented Oct 28, 2011

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.

@jnosky

This comment has been minimized.

Copy link
Contributor

jnosky commented Oct 30, 2011

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.

@gdimike

This comment has been minimized.

Copy link

gdimike commented Nov 3, 2011

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

Thanks!

@lbuchy

This comment has been minimized.

Copy link

lbuchy commented Nov 3, 2011

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.

@jnosky

This comment has been minimized.

Copy link
Contributor

jnosky commented Nov 3, 2011

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.

@karlp

This comment has been minimized.

Copy link
Contributor

karlp commented Nov 16, 2011

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

@emeb

This comment has been minimized.

Copy link

emeb commented Nov 21, 2011

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!

@karlp

This comment has been minimized.

Copy link
Contributor

karlp commented Jan 10, 2012

Texane! Please close this!

@bikeNomad

This comment has been minimized.

Copy link
Contributor

bikeNomad commented Jan 21, 2012

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

@bikeNomad bikeNomad closed this Jan 21, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment