STM32 Programmer CLI hangs on parsing large file

[GDare.1]

I am trying to program an F4 with an external flash chip in mapped memory mode using the STM32_Programmer_CLI. I use the cli command

STM32_Programmer_CLI.exe --connect port=SWD mode=UR reset=hwRst  -halt --erase all --download <path_to_hex> -el <path>/N25Q128A_STM32469I-DISCO.stldr

Which completes erase on internal flash and external flash, but then sits at parsing file. The file I am trying to write is 12.9MB with some flash existing in internal flash space and some flash existing in the hex position that correlates to the mapped memory modes position.

If I try to write all of just the external hex (11.8MB), I still experience the same issue. If I crop the hex file into smaller parts, it will program the correct locations in external flash.

I can successfully use the ST-LINK Utility with the same external loader to program the same hex file. I require the CLI however, because I require programming this through a script.

Is there a known limitation to the hex size the CLI can accept? How do I solve this issue?

EDIT:

I used the ST-LINK_CLI.exe with the same hex, the same external loader, and similar command line arguments and the programming worked as expected.

[Tesla DeLorean]

Will it ingest the original .ELF file directly?

Could you use the ST-LINK Utilities CLI?

That it works in pieces perhaps means it's not an alignment or normalization issue with the .HEX lines/records.

While all these tools do similar things the code is somewhat divergent and buggy in different ways. It has frustrated me for several years.

[GDare.1]

Thanks for your reply, we use the Cube Programmer CLI for other projects, so I would prefer not change the tool we use that drastically.

Will it ingest the original .ELF file directly?

I am not entirely sure what you mean here? When I use the above command and point it to the hex file with both internal and external flash locations, it hangs on the parsing file step.

[Houda GHABRI]

Hi GDare.1 ,

Can you please tell me the Board are you using ? Are you using STM32CubeProgrammer 2.8.0 version ?

Houda

[Tesla DeLorean]

Linker should be generating a .ELF (or .AXF) first, and then generate .HEX from that. The tools should accept the ELF Object.​

[Tesla DeLorean]

F469I-DISCO or equivalent by looks of command line​

[GDare.1]

@Community member​ is correct. it is a F469I-DISCO. I am using v2.4.0

[GDare.1]

      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0
      -------------------------------------------------------------------
 
STLinkUSBDriver.dll loaded
STLinkUSBDriver.dll loaded
STLinkUSBDriver.dll loaded
ST-LINK SN  : 066AFF303435554157025135
ST-LINK FW  : V2J38M27
Voltage     : 3.26V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x434
Reading data...
r ap 0 @0x40023C14 0x00000004 bytes
Reading data...
r ap 0 @0x1FFF7A22 0x00000004 bytes
Database: Config 0 is active.
flash loader <path>/FlashLoader/0x434.stldr is loaded
Reading data...
r ap 0 @0x40023C14 0x00000004 bytes
Reading data...
r ap 0 @0x1FFF7A22 0x00000004 bytes
Database: Config 0 is active.
Device name : STM32F469xx/F467xx
Reading data...
r ap 0 @0x1FFF7A22 0x00000004 bytes
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M4
 
halt ap 0
Core halted
 
Mass erase ...
 
Flash erase...
halt ap 0
w ap 0 reg 15 PC   (0x20000000)
w ap 0 reg 17 MSP  (0x20000500)
w ap 0 reg 16 xPSR (0x01000000)
w ap 0 @0x20001D80 0x00000200 bytes
w ap 0 @0x20000000 0x00000004 bytes
w ap 0 @0x20000004 0x00001945 bytes
Init flashloader...
halt ap 0
w ap 0 reg 0 R0   0x00000001
w ap 0 reg 1 R1   0x00000000
w ap 0 reg 2 R2   0x00000000
w ap 0 reg 3 R3   0x00000000
w ap 0 reg 4 R4   0x00000000
w ap 0 reg 5 R5   0x00000000
w ap 0 reg 6 R6   0x00000000
w ap 0 reg 7 R7   0x00000000
w ap 0 reg 8 R8   0x00000000
w ap 0 reg 9 R9   0x00000000
w ap 0 reg 10 R10  0x00000000
w ap 0 reg 11 R11  0x00000000
w ap 0 reg 12 R12  0x00000000
w ap 0 reg 13 SP   0x00000000
w ap 0 reg 14 LR   0x20000001
w ap 0 reg 15 PC   0x200002B7
w ap 0 reg 16 xPSR 0x01000000
w ap 0 reg 17 MSP  0x20001D45
w ap 0 reg 18 PSP  0x00000000
run ap 0
halt ap 0
r ap 0 reg 0 R0   0x00000001
Loader mass erase...
w ap 0 reg 0 R0   0x00000002
w ap 0 reg 1 R1   0x00000000
w ap 0 reg 2 R2   0x00000000
w ap 0 reg 3 R3   0x00000000
w ap 0 reg 4 R4   0x00000000
w ap 0 reg 5 R5   0x00000000
w ap 0 reg 6 R6   0x00000000
w ap 0 reg 7 R7   0x00000000
w ap 0 reg 8 R8   0x00000000
w ap 0 reg 9 R9   0x00000000
w ap 0 reg 10 R10  0x00000000
w ap 0 reg 11 R11  0x00000000
w ap 0 reg 12 R12  0x00000000
w ap 0 reg 13 SP   0x00000000
w ap 0 reg 14 LR   0x20000001
w ap 0 reg 15 PC   0x200003C3
w ap 0 reg 16 xPSR 0x01000000
w ap 0 reg 17 MSP  0x20001D45
w ap 0 reg 18 PSP  0x00000000
run ap 0
halt ap 0
r ap 0 reg 0 R0   0x00000001
Mass erase successfully achieved
 
 
Memory Programming ...
Opening and parsing file: file.elf
  File          : file.elf
  Size          : 5847380 Bytes
  Address       : 0x07FFC000
 
 
Erasing Segment <0> Address <0x07FFC000> Size <503720>Bytes
Erasing memory corresponding to segment 0:
Memory erase...
erase: 0071ms
Erasing Segment <3> Address <0x90001000> Size <5343660>Bytes
Erasing memory corresponding to segment 3:
Memory erase...
halt ap 0
w ap 0 reg 15 PC   (0x20000000)
w ap 0 reg 17 MSP  (0x20000500)
w ap 0 reg 16 xPSR (0x01000000)
w ap 0 @0x20001D80 0x00000200 bytes
w ap 0 @0x20000000 0x00000004 bytes
w ap 0 @0x20000004 0x00001945 bytes
Erasing external memory sectors [0 81]
Init flashloader...
halt ap 0
w ap 0 reg 0 R0   0x00000001
w ap 0 reg 1 R1   0x00000000
w ap 0 reg 2 R2   0x00000000
w ap 0 reg 3 R3   0x00000000
w ap 0 reg 4 R4   0x00000000
w ap 0 reg 5 R5   0x00000000
w ap 0 reg 6 R6   0x00000000
w ap 0 reg 7 R7   0x00000000
w ap 0 reg 8 R8   0x00000000
w ap 0 reg 9 R9   0x00000000
w ap 0 reg 10 R10  0x00000000
w ap 0 reg 11 R11  0x00000000
w ap 0 reg 12 R12  0x00000000
w ap 0 reg 13 SP   0x00000000
w ap 0 reg 14 LR   0x20000001
w ap 0 reg 15 PC   0x200002B7
w ap 0 reg 16 xPSR 0x01000000
w ap 0 reg 17 MSP  0x20001D45
w ap 0 reg 18 PSP  0x00000000
run ap 0
halt ap 0
r ap 0 reg 0 R0   0x00000001
Loader sector erase...
w ap 0 reg 0 R0   0x90000000
w ap 0 reg 1 R1   0x90510000
w ap 0 reg 2 R2   0x00000002
w ap 0 reg 3 R3   0x00000000
w ap 0 reg 4 R4   0x00000000
w ap 0 reg 5 R5   0x00000000
w ap 0 reg 6 R6   0x00000000
w ap 0 reg 7 R7   0x00000000
w ap 0 reg 8 R8   0x00000000
w ap 0 reg 9 R9   0x00000000
w ap 0 reg 10 R10  0x00000000
w ap 0 reg 11 R11  0x00000000
w ap 0 reg 12 R12  0x00000000
w ap 0 reg 13 SP   0x00000000
w ap 0 reg 14 LR   0x20000001
w ap 0 reg 15 PC   0x20000419
w ap 0 reg 16 xPSR 0x01000000
w ap 0 reg 17 MSP  0x20001D45
w ap 0 reg 18 PSP  0x00000000
run ap 0
halt ap 0
r ap 0 reg 0 R0   0x00000001
erase: 0622ms
Download in Progress:
  Size          : 503720 Bytes
  Address       : 0x07FFC000
 
 
Buffer program...
w ap 0 @0x07FFC000 0x0007AFA8 bytes
 
 
Error: failed to download Segment[0]
Error: failed to download the File

This is the terminal output when using the elf. It didn't hang but It seems to fail for some other reason. There is a script inbetween the hex in question, and this elf, that bakes in some flash level data. See my edit, I used the hex in question with the ST-LINK_CLI and it just worked, except we are hoping to not change tools.

[Tesla DeLorean]

I don't understand the 0x07FFC000 address, that's 32KB below the base of internal flash at 0x08000000

[GDare.1]

That was the first thing that looked strange to me too! The hex file generated at the same time as the elf (prior to the script) is valid (starts and ends where I expect), the hex file after the script is valid, readelf does not show any sections prior to the base address of 0x08000000.