STM32H753 Rev V Silicon Bug Not Documented in Errata notes ?

[Dub Bartolec]

We have encountered the following issue:

STM32H753 Rev V embedded UART bootloader does not work as in rev Y and earlier.

We've deployed quite a few rev Y devices and now when we got Rev V delivered on PCB boards are failing DFU GO command.

This seems like undocumented bug and it is serious as its nature is such that it prevents running of any custom made bootloaders.

It is easy to reproduce and here are the steps:

1. Configure STM32H753 to use HSI oscillator, UART (PA9 and PA10) and one DO to drive LED
2. Create simple firmware app that uses HSI clock and toggles the LED.
3. Load the code to STM32 using Jlink or STLink.
4. Test that it does what it is suposed to do.
5. Set BOOT0 to high to invoke internal DFU and reset MCU. Keep BOOT0 high for duration of the test. Note that keeping BOOT0 high is most important thing in this test.
6. Start STM32CubeProgrammer and connect to device via UART in DFU mode.
7. Load firmware to programmer and tick "Run After Programming"
8. Program chip and observe output
9. Rev Y MCU will run flash program as expected and LED will toggle.
10. Rev V MCU will fail and it will re-enter DFU bootloader.

Can anyone from STM or community test this too ?

We've tested it on Rev V (fails) and Rev Y (OK) MCUs.

This looks like a serious bug in silicone of STM32H753 Rev V.

[Hugues DE CARVALHO]

Hi,

I am experiencing the same issue and signaled it on the ST bug system.

Hugues

[Imen.D]

Hello @Dub Bartolec​ ,

Please which Bootloader version are you using in memory location @ 0x1FF1E7FE ?

Note that in the AN2606, for the Bootloader version number V13.2 (0xD2): “Go�? Command is not working.

Best Regards,

Imen

[Dub Bartolec]

OK. This now raises 3 more questions :

1. How do we find out version of the Bootloader using STM32CubeProgrammer ? It only reports protocol version as 3.1
2. What is the version of the embedded Bootloader loaded to STM32H753 Rev Y (one that works) and to Rev V (one that fails)
3. Do versions of embedded Bootloader vary within the same revision of the chip ?

The above questions are raised because STM32CubeProgrammer reports bootloader version for STM32H753 Rev Y and Rev V to be 3.1 and as per DFU UART documentation this actually is Bootloader protocol version.

We've actually ran both commands Get(0x00) and GerVersion(0x01) directly to bootloader and version reported was the same, Ver 3.1, not Ver 13.2 or 9.0 or whatever else as suggested in AN2606.

Can you explain what is the difference between Bootloader version 13.2 and Bootloaader protocol version 3.1 ?

Regards

[Imen.D]

Hello,

You should verify the Bootloader version using STM32CubeProgrammer at address 0x1ff1E7FE (please see attached picture: in red means I'm using version 9.0)

Regarding the difference between Bootloader version:

• Bootloader version 13.2 : binary bootloader, it supports UART, SPI, I2C, USB DFU.
• Bootloader version 9.0: it supports UART, SPI, I2C, USB DFU, FDCAN.
• Bootloaader protocol version 3.1 : it's the protocol UART implemented in the bootloader.

Best Regards,

Imen.

[Dub Bartolec]

Hi Imen,

I got all the data for you and here are the versions:

1. STM32H753 Rev Y Bootloader version 0xD2 (13.2) (GO command works OK) - AN2606 states that it should not work.
2. STM32H753 Rev V Bootloader version 0x90 (9.0) (GO command doesn't work) - All issues from 13.2 and 13.3 were supposed to be fixed here as per AN2606

All this is confusing

To summarize here:

Rev V is loaded with Bootloader version 9.0 and it is supposed to have all known limitations of 13.2 and 13.3 fixed (one of them being "Go Command is not working"),

but this is not the case.

In fact 13.2 is OK but 9.0 is not.

[Dub Bartolec]

Hi Imen,

I was wondering if anyone have made some progress on this issue ?

Do you need some more information ?

Regards,

[Hugues DE CARVALHO]

Hi Dub,

The division is currently working on the issue, I will keep you updated as soon as I've got feedback from them.

Regards,

Hugues

[Dub Bartolec]

Hi Hugues and Imen,

Is there any progress on this issue ?

It seems to be fairly serious.

Regards !

Dub

[Hugues DE CARVALHO]

Hi Dub,

The division is working on it. I haven't had any update.

Regards,

Hugues