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.

[Amel NASRI]

Hi @richaverma ,

Welcome to our Community!

First recommendation I share is to check the bootloader version for both batch of devices.

Depending on the bootloader version, you may confirm or discard some assumptions.

Your reference is AN2606: depending on the version, please check the table "Table 124. STM32H74xxx/75xxx bootloader version" for the known limitations (mainly what is related to USART1 pins in your case).

Please keep me informed about the outcomes of your checks.

-Amel

[richaverma]

How do we get the details of Bootloader version ? I am attaching the snapshot of Good versus Bad STM32H743 . This is loaded already when we buy the part. is there a way to find the bootloader configuration from the Manufacturer part number?

[Tesla DeLorean]

Fail to identify chip markings on parts working vs not. Large tightly cropped images might help.

If you write your .BIN via SWD/JTAG does THAT work? It should.

[richaverma]

Hi,

 

i have attached some initial picture of the good versus bad. More to get from production . Also i have attached the log file which shows some details of error. The bootloader is already loaded from factory . is there a way to find which bootloader is incorporated just by knowing the manufacturer part number.

Yes through JTAG when we load the .bin file it works fine.

 

 

[Tesla DeLorean]

It think AN2606 provides a location to check version#. Log suggests "3.1"

Both these images seem to depict a part from the exact same production batch, so I doubt they have different Boot Loader versions. Perhaps look for other reasons the programming fails, like noise of other UARTs, or communications failing on the one you're using.

Connectivity here is a one-shot deal, the System Boot Loader might function differently is the FLASH is blank, vs not.

The BOOT0 pin needs to be pulled-high, and a Reset / Power Cycle needed to enter.

On might also look at AN3155, and perhaps walk the devices through initial start sequence and query of command list, etc.  One can use RealTerm in HEX mode to interact.

Other issues potentially : Power, VCAP capacitors/voltages, External Crystal (More USB related)

Perhaps build a test application you load via JTAG/SWD to probe/test part/board functionality, and stress test.

[waclawek.jan]

> The LRU System Test equipment cannot load the programming (.bin ) file to many units.

What does this mean? How do you "load" the bin, exactly, and what are the symptoms of the failure?

JW

[richaverma]

 The original process used  was:

 Load .bin file via JTAG (open box), finish assembly and close box, FTP, ESS, ATP, Load flight code via Serial. In this process , we used USART 3 interface  for RS-232 at the end while loading OPS (.bin file). 

The error first appeared as a “STE fatal error” because that was the first step in the process that serial programming was done. Station encountered the error with the unit and couldn’t continue, so it ended the test. We confirmed functionality of the test station with a “known good” unit.

 

We changed the process to 

Load .bin file via JTAG (open box), Load .bin file via serial using STMCube programmer (USART), finish assembly and close box, FTP, ESS, ATP, Load flight code via Serial

We added the serial loading of test sw (.bin) after JTAG programming in order to catch the serial load error before it went through the whole testing process and failed at the end. Because of this, all failures are occurring at the serial  load in the second step itself now. Please see attached for an example of a failed log at this step.

When loading serially after a JTAG program, the unit will “connect”. The error happens after programming is started (see attached log). Internal memory will fail to erase, and then unit loses connection to STM Cube Programmer. After this happens, in our experience, you cannot “connect” the unit to the Cube Programmer again unless you were to reload SW via JTAG.

 

There is one additional update which we got today .When we click on skip flash erase before programming , there is no issue happening with the serial load. Any specific reason? Please support.

I ahve attached picture of good versus bad STM32 IC in my previous attachments

[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