search

blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.17k stars 761 forks source link

Corrupted EEPROM after flashing on F7 #288

Closed hydra closed 6 years ago

hydra commented 6 years ago

Hi guys,

I work on the cleanflight/betaflight projects and have recently starting using BMP on some baite and stlink probes.

I'm experiencing some flash corruption after uploading, here's what I'm doing:

erase F7

arm-none-eabi-gdb -ex "target extended-remote COM9" -ex "monitor swdp_scan" -ex "attach 1" -ex "monitor erase_mass" -ex "quit"

upload binary via eclipse

image

init commands as follows:

target extended-remote COM9
monitor swdp_scan
monitor connect_srst enable
attach 1
set mem inaccessible-by-default off
set print pretty

then, if I use the eclipse memory view to inspect the flash, i see corruption.

image

vs actual binary

image

800 bytes (0x320) of corruption from 0x3FF40 to 0x4025F.

using STLINK target from commit ad71db05b9c5b167f48f15a42cf9f86255942253

arm-none-eabi-gdb, md5 = 8211e49768b0db23a83a35f335ee44ac

GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 7.12.1.20170417-git

I also tried the baite target and 2 other different probes to confirm this. (See my fork here: https://github.com/hydra/blackmagic/tree/baite-target for that, original patch to support baite target is here: https://wiki.cuvoodoo.info/doku.php?id=jtag - see commit https://github.com/hydra/blackmagic/commit/b1868067d2ca17b4dd9145934507d534c25f3a90 for my updated baite target support)

I should note that when the same binary is uploaded using the flashing tools in the cleanflight-configurator the firmware is uploaded ok, if i then attach the debugger and use the eclipse memory view reveals the expected eeprom content.

Any suggestions?

hydra commented 6 years ago

test-binary.zip

attached the test binary itself, in case it helps.

hydra commented 6 years ago

also, I checked the gdb compare-sections -r command and confirm that it also reports the sections are mismatched. e.g.

Section .isr_vector, range 0x8000000 -- 0x80001e0: matched.
Section .text, range 0x8008000 -- 0x805ceac: MIS-MATCHED!
Section .ARM, range 0x80001e0 -- 0x80001e8: matched.
Section .pg_registry, range 0x80001e8 -- 0x8000698: matched.
Section .pg_resetdata, range 0x8000698 -- 0x8000799: matched.

I can successfully upload and verify similar size binary files to the STM32F405RG without issue. Problem seems to be related to the STM32F722.

UweBonnes commented 6 years ago

I can find no problems. B.t.w. a hex file would help...

unzip test-binary.zip srec_cat test-binary.bin -binary -offset 0x08000000 -o f722.hex -intel arm-none-eabi-gdb f722.hex GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160923-cvs Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from f722.hex...(no debugging symbols found)...done. (gdb) tar ext /dev/ttyACM0 Remote debugging using /dev/ttyACM0 0x080597c0 in ?? () (gdb) mon s Target voltage: unknown Available Targets: No. Att Driver 1 STM32F72x (gdb) att 1 Attaching to program: /tmp/f722.hex, Remote target 0x080597c0 in ?? () (gdb) load Loading section .sec1, size 0x10000 lma 0x8000000 Loading section .sec2, size 0x10000 lma 0x8010000 Loading section .sec3, size 0x10000 lma 0x8020000 Loading section .sec4, size 0x10000 lma 0x8030000 Loading section .sec5, size 0x2b98 lma 0x8040000 Start address 0x0, load size 273304 Transfer rate: 15 KB/sec, 965 bytes/write. (gdb) compare-section Section .sec1, range 0x8000000 -- 0x8010000: matched. Section .sec2, range 0x8010000 -- 0x8020000: matched. Section .sec3, range 0x8020000 -- 0x8030000: matched. Section .sec4, range 0x8030000 -- 0x8040000: matched. Section .sec5, range 0x8040000 -- 0x8042b98: matched.

hydra commented 6 years ago

That's really quite strange then. I don't understand how it always fails to upload and in a consistent manner every time.

I'm using F722RET6, with date/batch code: GH260 VQ, CHN GH 643. This is happening on circuit boards from 3 different manufactures, 3 different designs.

What CPU did you try that on?

hydra commented 6 years ago

When I get a chance I will try the debugger on the OSX laptop to make sure it's not related to COM port drivers, though I doubt it is because I can use the F405RG with no issues but will check to make sure.

Other than a CPU difference, can you think of anything else I should try/check? Let me know if you need more information too. Happy to assist in any way possible to get this fixed and working ASAP.

UweBonnes commented 6 years ago

Hydra, do you use git head?

hydra commented 6 years ago

at the time, yes - ad71db0 as mentioned above

hydra commented 6 years ago

I see there's a few more changes, would you like me to re-test with HEAD?

UweBonnes commented 6 years ago

Yes!

hydra commented 6 years ago

Ok, I should have a chance to try this tonight.

hydra commented 6 years ago

ok, so i grabbed latest head, rebuilt my STLINK target, reflashed and tested again:

compare-sections -r
Section .isr_vector, range 0x8000000 -- 0x80001e0: matched.
Section .text, range 0x8008000 -- 0x804d8e8: MIS-MATCHED!
Section .ARM, range 0x80001e0 -- 0x80001e8: matched.
Section .pg_registry, range 0x80001e8 -- 0x8000698: matched.
Section .pg_resetdata, range 0x8000698 -- 0x800079a: matched.

then i uploaded the same code using the F7 DFU bootloader and connected to the target using the updated STLINK proble and compared again:

compare-sections -r
Section .isr_vector, range 0x8000000 -- 0x80001e0: matched.
Section .text, range 0x8008000 -- 0x804d8e8: matched.
Section .ARM, range 0x80001e0 -- 0x80001e8: matched.
Section .pg_registry, range 0x80001e8 -- 0x8000698: matched.
Section .pg_resetdata, range 0x8000698 -- 0x800079a: matched.

so to confirm, I still have a problem on with latest git head - 19e58a7205e2dfe849b5ac42e470ff489e4ab10d

UweBonnes commented 6 years ago

Please provide the elf file.

hydra commented 6 years ago

test.zip

attached.

UweBonnes commented 6 years ago

Argh, download hangs...

hydra commented 6 years ago

i was able to download it, I'll re-attach it here:
test.zip

UweBonnes commented 6 years ago

(gdb) load ... Loading section .pg_resetdata, size 0x102 lma 0x8000698 Loading section .data, size 0x26e8 lma 0x800079a ...

What strange linker script produced half-word aligned offset/length.

hydra commented 6 years ago

this one:

https://github.com/cleanflight/cleanflight/blob/master/src/main/target/link/stm32_flash_split.ld

hydra commented 6 years ago

in combination with this one:

https://github.com/cleanflight/cleanflight/blob/master/src/main/target/link/stm32_flash_f722.ld

hydra commented 6 years ago

some background, the .pg_registry section is used to load/save/initialise config structures. This system allows modules in the source to have no dependencies on a global config object nor on any config load/save system. The magic is that the structures marked with a particular attribute which are collected by the linker script and stored in a specific section of the flash.

See: https://github.com/cleanflight/cleanflight/blob/master/src/main/config/parameter_group.c https://github.com/cleanflight/cleanflight/blob/master/src/main/config/parameter_group.h https://github.com/cleanflight/cleanflight/blob/master/src/main/config/config_eeprom.c

If you want to read more you can find the initial PR to cleanflight here: https://github.com/cleanflight/cleanflight/pull/1049

Do you think the alignment is the cause of the issues or is it unrelated? If you think something is sub-optimal please do let me know.

gsmcmullin commented 6 years ago

It may be related. It will result in the same word being programmed twice, and will depend on whether that works in the stm32f7. It may also trigger some other bug of which I am unaware.

You can try mon psize x8 to program the flash by byte, rather than by word, and see if that helps.

hydra commented 6 years ago

OK. I tried using mon psize x8. The problem persists.

hydra commented 6 years ago

can you suggest any workarounds that I can try, e.g. by updating the linker script?

UweBonnes commented 6 years ago

Try #293

hydra commented 6 years ago

I tested #293 on my F722RE and confirm the problem I was having is solved!

compare-sections -r
Section .isr_vector, range 0x8000000 -- 0x80001e0: matched.
Section .text, range 0x8008000 -- 0x804d8f0: matched.
Section .ARM, range 0x80001e0 -- 0x80001e8: matched.
Section .pg_registry, range 0x80001e8 -- 0x8000698: matched.
Section .pg_resetdata, range 0x8000698 -- 0x800079a: matched.

I'm close now to having a working debug solution for F1/F3/F4/F7 CPUs. I have opened #295 which I found when testing #293.

Many thanks for your assistance and hard work on this. Much appreciated!