Closed hydra closed 6 years ago
attached the test binary itself, in case it helps.
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.
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.
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?
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.
Hydra, do you use git head?
at the time, yes - ad71db0 as mentioned above
I see there's a few more changes, would you like me to re-test with HEAD?
Yes!
Ok, I should have a chance to try this tonight.
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
Please provide the elf file.
Argh, download hangs...
(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.
in combination with this one:
https://github.com/cleanflight/cleanflight/blob/master/src/main/target/link/stm32_flash_f722.ld
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.
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.
OK.
I tried using mon psize x8
. The problem persists.
can you suggest any workarounds that I can try, e.g. by updating the linker script?
Try #293
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!
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
upload binary via eclipse
init commands as follows:
then, if I use the eclipse memory view to inspect the flash, i see corruption.
vs actual binary
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?