cancel
Showing results for 
Search instead for 
Did you mean: 

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

olivier.scalbert
Associate III

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

This discussion is locked. Please start a new topic to ask your question.
10 REPLIES 10
Andreas Bolsch
Lead II

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
Associate III

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 !

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

olivier.scalbert
Associate III

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 !

;)

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
Associate III

Thanks again Andreas !

olivier.scalbert
Associate III

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

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

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.