Process Change Information (STM32H74x/75x - Microcontroller product - Bootloader enhancement)

[richaverma]

We are using STM32H743 Controller in one of our LRU (Line replaceable unit).

Since February end, The LRU System Test equipment cannot load the programming (.bin ) file to many units. This is the first time this specific failure mode has appeared. This is also the first time that any kind of OPS programming failure has appeared that isn't an operator or facility issue.

We have tried loading the  .bin file using STM32Cube programmer as well but still the issue exists.

We have recently come across this PCN where Bootloader version of 9.1 is Changed to V9.2 resolving abnormal data output on the USART1_TX PB14.

1. We are using USART3_TX on PB14 and USART3_RX on PB11.  Do you think OPC bootloader V9.1 to V9.2 has any impact on USART 3 interface used for RS-232 ?

Note , once we replace the STM32 IC with the old batch code , this issue is resolved.

More details :Here are our connections.

USART1_TX : PB14 (PULL DOWN 100K), series resistor 47 ohms.

USART1_RX :PB15  (PULL DOWN 100K ) series resistor 22 ohms .

USART1 connections are currently not used but has the above connections available in the design. Do you suggest removing the pull-down resistor of 100K  when USART1 is not used?

We are using USART3 for programming using serial port.

Connections:USART3_RX : on PB11 and USART3_TX on PB10 .

None of them have a pull up currently. Used RS232 driver MAX3232MPW. Do you suggest the pull up resistors on these Tx and Rx lines?

Can we get the bootloader code for 9.1 and 9.2?

Is anyone else has faced similar issues in the past ?

Request you to please provide some support as this is our production issue and needs to be resolved immediately.

[Tesla DeLorean]

>>Internal memory will fail to erase, and then unit loses connection to STM Cube Programmer.

More likely an issue with VCAP

Should be 4.7uF total capacitance across VCAP pins, or 2.2uF per pin. Should measure 1.25V

The FLASH and related charge-pump can fail is there's inadequate bulk capacitance. Say production use wrong tube of parts.

Loader version seems like a red-herring, check for other causes.

Add CRC / Checksum to assure integrity of image on device.

Instrument Hard Fault and Error Handlers so failure there can be determined.

I doubt ST will furnish source to Boot Loader

[richaverma]

Hi,

Please note , we have already done the Functional tests, Acceptance tests etc. and there are no issues found. Also this issue is happening recently after February 2025 wherein no changes has been done to the code or design or setup/process.

 Looking at the log shared , it is confirmed that the issue is happening because its not erasing the internal memory. There is a known limitation on the erase option for STM32H74 "Erase on bank2 not working as expected
– Root cause: check bad busy value while erasing on
bank2.
– Behavior: when erase on bank2 is requested, SW
exits while the operation is ongoing. Sending a new
command invoking the flash memory after the
erase can hang the system.
– Workaround: worst case erase timing from the
product datasheet can be added after the erase
command to allow the FLITF to complete the erase.
A safer method is to use a RAM patch for the erase
command."

As per the log also , when we try to load the SW using Serial load , it fails the erase 

10:43:10 : Memory Programming ...
10:43:10 : Opening and parsing file: Bobafet.bin
10:43:10 : File : Bobafet.bin
10:43:10 : Size : 49160 Bytes
10:43:10 : Address : 0x08000000
10:43:10 : Erasing memory corresponding to segment 0:
10:43:10 : Erasing internal memory sector 0
10:43:17 : Error: failed to erase memory
10:43:19 : Timeout error occured while waiting for acknowledgement.
10:43:19 : Error: GETID command not acknowledged!
10:43:19 : Reemission of GetID command
10:43:20 : Timeout error occured while waiting for acknowledgement.
10:43:20 : Error: GETID command not acknowledged!
10:43:20 : Reemission of GetID command
10:43:21 : Timeout error occured while waiting for acknowledgement.
10:43:21 : Error: GETID command not acknowledged!
10:43:22 : Timeout error occured while waiting for acknowledgement.
10:43:22 : Error: GETID command not acknowledged!
10:43:22 : Reemission of GetID command
10:43:23 : Timeout error occured while waiting for acknowledgement.
10:43:23 : Error: GETID command not acknowledged!
10:43:23 : Reemission of GetID command
10:43:24 : Timeout error occured while waiting for acknowledgement.
10:43:24 : Error: GETID command not acknowledged!
10:43:24 : Warning: Connection to device 0x450 is lost
10:43:25 : Disconnected from device.

Per the log its continuously failing the acknowledgement. And disconnects the device on failing to detect the acknowledgement. Since this issue is happening only on few units , also when we click on skip erase options , we can program even the bad STM32 IC .

How can we add erase timing in SW code ?

Any suggestions?

[richaverma]

 Isn't the  erase timing  controlled by bootloader and cannot be modified in our SW code.

Can this error  be caused due to ST cube programmer times out before the erase cycle completion. We are using STM32CubeProgrammer API v2.9.0?

[Amel NASRI]

Hello @richaverma ,

To ensure your case is properly followed up and managed promptly, could you kindly submit a request through Online Support (OLS)?

If you encounter any issues, please don’t hesitate to reach out to me.

-Amel

[richaverma]

Sorry I accidentally marked this as the solution,but this problem is still there.

Please have alook at the latest queries and clarify

[Amel NASRI]

Hi @richaverma ,

I unmarked the solution.

As previously suggested, please submit a request on OLS as this case may require quality check. We cannot handle this on community.

-Amel

[richaverma]

Hi all,

As a additional information to issue we were using software method to enter boot mode i.e. JumpToBootloader() function using discretes. We observed that the STM32 MCU enters the boot mode (UART) and responds to the ID, but after the erase command no response .  We were using STM32CueProgrammer version v2.9.0.

1. On using latest STM32CubeProgrammer version v2.19, this issue is resolved. Any rationale on the same ?

2. We are using STM Bootloader ST Version 0x91.Will Shifting from STM32CueProgrammer version v2.9.0 to STM32CubeProgrammer version v2.19 have any impact to  STM Bootloader ST Version 0x91 ?

Request you please respond. We are almost at the verge of closing this issue.

Regards,

Richa.

[richaverma]

Hi ,

I have already raised request on OLS and so far no response.

We have already found a solution for the issue , but have some below queries. As i mentioned , this is the production stoppage issue for us, can you please help in getting the response on below.

1. We were using STM32CubeProgrammer API v2.9.0 initially .On using latest STM32CubeProgrammer version v2.19, this issue is resolved. Any rationale on the same ?

2. We are using STM Bootloader ST Version 0x91.Will Shifting from STM32CubeProgrammer version v2.9.0 to STM32CubeProgrammer version v2.19 have any impact to  STM Bootloader ST Version 0x91 ?

3. What versions of  STM Bootloader will be supported by STM32CubeProgrammer version v2.19? If the old stock of micro with old bootloader say 0x9 is been used , will the STM32CubeProgrammer version v2.19 throw error as compatibility issues?