How to flash STM32CubeDemo_STM32769I-DISCO_V1.0.1.hex on board with Linux ?

olivier.scalbert · ‎2019-09-30

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

Andreas Bolsch · ‎2019-09-30

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/.

olivier.scalbert · ‎2019-09-30

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 !

Andreas Bolsch · ‎2019-09-30

Yes, clone (master!), and afterwards download the patchset and apply the patch. On linux, the build procedure should be straightforward.

olivier.scalbert · ‎2019-10-01

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 !

😉

Andreas Bolsch · ‎2019-10-01

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 ...

olivier.scalbert · ‎2019-10-01

Thanks again Andreas !

olivier.scalbert · ‎2019-10-02

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

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

Andreas Bolsch · ‎2019-10-03

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

Andreas Bolsch · ‎2019-10-03

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.