STM32h747 MCU missing chunk of memory when flashing with stm32flash tool

[amandayun]

Hello!
I'm using an STM32H747 MCU on a custom board. We typically flash the STM32 from a Jetson using stm32flash over UART, and this process has worked reliably on over 50 boards.

However, I recently discovered that a couple of boards from a new manufacturing batch, using the same MCU, are experiencing issues with the CM4 core failing to boot.

To investigate, I used STM32CubeProgrammer to inspect the flash memory directly and found a consistent gap. The CM4 firmware starts at 0x08100000, but the region from 0x08100040 to 0x081002F0 remains erased every time the firmware is programmed using stm32flash.

Interestingly, the memory regions before and after this gap appear to be programmed correctly, and the same issue occurs consistently on the affected boards.

So far, i have found two MCU’s where this problem occurs and both have the same chunk of memory missing.
 

I am able to fully flash successfully using the JTrace. Its just when we try to flash with  the stm32flash tool that this fails.

I was wondering if this is apart of a “known limitation” in the ST Community or if this issue is rooted from our custom boards. 

Bootloader version 0x90

Thanks!
Amanda

[TDK]

stm32flash is not an ST tool. Use STM32CubeProgrammer or contact stm32flash maintainers for support.

[Andrew Neil]

the firmware is programmed using stm32flash.

You mean this: https://sourceforge.net/p/stm32flash/wiki/Home/ ?

That’s a 3rd-party utility - so you really need to take any issues up with the author.

The last update there seems to be 2022-03-26.

 

You say that JTrace and CubeProgrammer work - so why not stick with them?

[amandayun]

J-Trace and STM32CubeProgrammer are great tools when direct debugging access is available. However, our application requires programming the STM32 remotely over UART, so a direct SWD connection isn't always practical.

[Andrew Neil]

Cube programmer can use the UART connection - it doesn’t rely on just SWD

[amandayun]

Hello thank for responding so quickly 

Yes, I am aware that stm32flash is not an ST tool, but it is  a well established, widely used open source tool in the STM32 community, particularly for flashing stm32 microcontrollers over uart. 

My reason for bringing this up is that we've successfully used this exact flashing process on over 50 boards without any issues. Only a couple of boards from a newer batch are exhibiting this behavior.

Given that the tool has been reliable for us and the issue appears to affect only a small number of boards, I'm curious whether anyone has encountered something similar or has any insight into what might cause such a consistent gap in flash memory during programming.

I'm trying to understand whether this could be related to the MCU itself, the ROM bootloader, or something specific to these boards, rather than assuming it's an issue with the flashing tool.

[TDK]

Yes, I am aware that stm32flash is not an ST tool, but it is  a well established, widely used open source tool in the STM32 community, particularly for flashing stm32 microcontrollers over uart. 

You may be overselling it a bit, given it was last updated 1.5 years ago. It is well used, but it’s not at the same caliber as STM32CubeProgrammer CLI functionality, especially on newer chips.

I'm trying to understand whether this could be related to the MCU itself, the ROM bootloader, or something specific to these boards, rather than assuming it's an issue with the flashing tool.

It’s unlikely to be a hardware issue, either on the chip or the bootloader or the board.

but the region from 0x08100040 to 0x081002F0 remains erased every time the firmware is programmed using stm32flash

It may be a parsing issue on the HEX file. If you could include that here, it could be examined.

[amandayun]

Thank you for the suggestion! We're actually using a raw .bin file rather than a HEX file, and the same binary and flashing procedure works successfully on over 50 boards
.
I am curious whether this could be related to the MCU’s internal ROM bootloader. 
Is it possible for the STM32H7 MCUs with the same device ID and reported USART bootloader version to have different internal ROM bootloader revisions?

Are there any known ROM bootloader limitations that could cause a Write Memory command to be acknowledged without the data actually being programmed?
 

The unusual part is that the same flash region (0x08100040–0x081002FF) remains erased on every attempt, while the surrounding regions are programmed correctly.

I'm trying to understand whether there are any known MCU or ROM bootloader behaviors that could explain this before assuming the issue is with our flashing process or board hardware.