2019-09-30 06:25 AM
I am trying to flash STM32CubeDemo_STM32769I-DISCO_V1.0.1.hex into the board, under Linux, with st-flash. And it does not work:
$ st-flash --serial /dev/ttyACM0 --format ihex write STM32F769I-Discovery/Demonstration/Binary/STM32CubeDemo_STM32769I-DISCO_V1.0.1.hex
st-flash 1.5.1-38-gc3577b5
2019-09-30T15:13:15 INFO common.c: Loading device parameters....
2019-09-30T15:13:15 INFO common.c: Device connected is: F76xxx device, id 0x10006451
2019-09-30T15:13:15 INFO common.c: SRAM size: 0x80000 bytes (512 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2019-09-30T15:13:16 INFO common.c: Ignoring 108 bytes of 0xff at end of file
2019-09-30T15:13:16 INFO common.c: Attempting to write -2004393772 (0x888760d4) bytes to stm32 address: 134217728 (0x8000000)
2019-09-30T15:13:16 ERROR common.c: addr too high
stlink_fwrite_flash() == -1
What should I do ?
Thanks
Olivier S
2019-09-30 08:21 AM
Looks like the hex file is interpreted as binary file. But even if it would be interpreted correctly: The hex file in question contains not only the contents of the internal flash, but also of the external NOR flash on the board. I don't know whether st-flash can actually deal with that external memory, probably not.
Either use STM32CubeProgrammer with a suitable external loader (should be included in the package) or use http://openocd.zylin.com/#/c/4321/.
2019-09-30 09:16 AM
Hi Andreas,
Thanks for your help.
I have never used openocd. Time to do it now !
I have installed it on my debian buster, but I think I need to download your version and compile it.
But how to I get your repo (git clone ???).
Thanks !
2019-09-30 10:06 AM
Yes, clone (master!), and afterwards download the patchset and apply the patch. On linux, the build procedure should be straightforward.
2019-10-01 12:19 AM
Ok it works now !
For those, like me, who are not fluent with openocd, here are the different steps.
I have patched, compiled and installed openocd
I get the board serial:
$ st-info --probe
Found 1 stlink programmers
serial: 303637314646353635323531383837303637303135313133
openocd: "\x30\x36\x37\x31\x46\x46\x35\x36\x35\x32\x35\x31\x38\x38\x37\x30\x36\x37\x30\x31\x35\x31\x31\x33"
flash: 2097152 (pagesize: 2048)
sram: 524288
chipid: 0x0451
descr: F76xxx device
I create a openocd.cfg file:
source [find interface/stlink.cfg]
source [find board/stm32f769i-disco.cfg]
hla_serial "\x30\x36\x37\x31\x46\x46\x35\x36\x35\x32\x35\x31\x38\x38\x37\x30\x36\x37\x30\x31\x35\x31\x31\x33"
Then I load the hex file:
$ openocd -f openocd.cfg -c "program .... path to /Cube_FW_F7_V1.4.0/Projects/STM32F769I-Discovery/Demonstration/Binary/STM32769I-DISCO_DEMO_V1.0.0_FULL.hex" -c "reset" -c "run"
7m46.658s later the board is up and running !
Thanks Andreas !
I also be able to load the new Qt demo for mcu.
So it is a good day !
;)
2019-10-01 02:56 AM
That's good. BTW: You don't need an extra cfg-file. Just '-f board/stm32f769i-disco.cfg' should be sufficient, as long as only one ST-Link is attached.
Using STLink-V3 would give *MUCH* higher speed, but I don't know if is possible to isolate the SWD from the onboard STLink and attach an external easily.
Checked this only for stm32f746g-disco, and there it's somewhat delicate ...
2019-10-01 03:00 AM
Thanks again Andreas !
2019-10-02 06:01 AM
Hi,
Still a little problem with "verify":
$ openocd -f board/stm32f769i-disco.cfg -c "program STM32Cube_FW_F7_V1.4.0/Projects/STM32F769I-Discovery/Demonstration/Binary/STM32769I-DISCO_DEMO_V1.0.0_FULL.hex verify reset exit"
Open On-Chip Debugger 0.10.0+dev-00937-gd10aa40f (2019-10-01-07:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J31M21 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.228346
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08028b5c msp: 0x20080000
** Programming Started **
Warn : continuing after end-of-file record: :020000040810E2
Warn : continuing after end-of-file record: :020000040818DA
Info : device id = 0x10006451
Info : flash size = 2048 kbytes
Info : Single Bank 2048 kiB STM32F76x/77x found
Info : Flash write discontinued at 0x080b9fce, next section at 0x08100000
Info : Padding image section 1 at 0x0816e381 with 72831 bytes
Info : Padding image section 2 at 0x081801f8 with 8 bytes
Info : flash size = 1024 bytes
Info : flash1 'mac 25l51245' id = 0x1a20c2 size = 65536kbytes
Info : Flash write discontinued at 0x9082f1f0, next section at 0x91000000
Info : Flash write discontinued at 0x92ca9a64, next section at 0x93000000
** Programming Finished **
** Verify Started **
Warn : continuing after end-of-file record: :020000040810E2
Warn : continuing after end-of-file record: :020000040818DA
Error: checksum mismatch - attempting binary compare
** Verify Failed **
shutdown command invoked
2019-10-03 12:14 AM
Oh, that's a wrong read command in QPI mode, probably I deleted the wrong line when removing the SPI branch in the cfg file. Replace in the cfg
mww 0xA0001014 0x0F003F13 ;# QUADSPI_CCR: FMODE=0x3, DMODE=0x1, DCYC=0x0, ADSIZE=0x3, ADMODE=0x1, IMODE=0x1, INSTR=READ
by
mww 0xA0001014 0x0F283FEC ;# QUADSPI_CCR: FMODE=0x3, DMODE=0x1, DCYC=0xA, ADSIZE=0x3, ADMODE=0x1, IMODE=0x1, INSTR=4READ4B
2019-10-03 12:22 AM
BTW: The 'verify' option for 'program' uses memory mapped reads for checksumming. For H7 and L4+ this causes a rather catastrophic failure due to a silicon bug if the image extends up to the end of the external flash (not very likely, but ...). So, better don't use the 'verify' option but a separate 'flash verify_image' command, as this does indirect reads only.