STM32H7 rev V vs Y DFU UART GO command issue

[Dub Bartolec]

We have deployed quite a few of our products using STM32H753(ZIT6) rev Y and all was OK.

All recent ones that we have around are rev V and they have issues with DFU bootloader over the UART. None of the issues that we have are listed in ERRATA notes for Y vs V revisions,

Problem is that when we program the device using STM32CubeProgrammer using UART DFU, al is OK but GO command ("Run after programming" is ticked off) causes MCU to reset and code is not executed.

The same procedure works fine on rev Y chip.

I can create simple firmware that toggles one LED when it is running to demonstrate this issue and perhaps ST support can look at it.

Looks like a serious issue to us.

[Amel NASRI]

Hello @Dub Bartolec​ ,

ARe you using USART1 with pins PB14 /PB15?

If yes, please pay attention to this note: "To be able to connect to the bootloader USART1 using PB14/PB15 pins, you need to send two synchronization bytes." added in AN2606.

You can refer to https://community.st.com/s/question/0D50X0000BsRUspSQG/stm32h743xx-version-v-bootloader-init-issue- where similar issue is discussed.

-Amel

[Dub Bartolec]

Hi Amel,

Yes I am aware of all errata notes issued for Rev V device and there were quite a few. I've created test case that can be easily executed to reproduce and confirm that bug is in fact in UART DFU of STM32H753 Rev V chip.

Here is the procedure:

In order to reproduce an issues do the following:

1. Configure STM32H753 to use HSI clock, UART (PA9 and PA10) and one DO to drive LED.

2. Create simple firmware app that uses internal HSI 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 (toggles LED)

5. Set BOOT0 to high to invoke internal DFU and reset MCU. Keep BOOT0 high for duration of the 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 and LED will toggle.

10. Rev V MCU will fail and it will re-enter DFU bootloader.

Let me know if this is enough info.

Also there is support case number 00096391 raised at ST support site for this and engineer has managed to reproduce the problem.

To summarize...

Overall impact of the issue is that GO command to correct address executed from UART DFU of STM32H753 Rev V chip will result in reset of the chip.

There is also more info in this thread:

https://community.st.com/s/question/0D70X000007QSjZ/stm32h753-rev-v-silicon-bug-not-documented-in-errata-notes-?s1oid=00Db0000000YtG6&s1nid=0DB0X000000DYbd&emkind=chatterCommentNotification&s1uid=0050X000009yaBl&emtm=1579578846478&fromEmail=1&s1ext=0

[Amel NASRI]

Thanks Dub for these details. We try to reproduce issue from our side, and will keep you informed about progress.

[Amel NASRI]

Hello @Dub Bartolec​ ,

Could you please let me know the bootloader versions on both devices (rev Y and rev V)?

You can get it @0x1FF1E7FE .

• If it version is V13.2, there is already a known limitation ==> “Go�? Command is not working 
• If it is V9.0 , the following is known as a limitation: "First ACK not received on “Go�? Command when using USART or SPI". The impact of this later is that STM32CubeProgrammer will show a failure error message, but really you can jump to the application and run it.

Details about the known limitations on bootloader versions are provided on table Table 91of AN2606. STM32H74xxx/75xxx bootloader version:

-Amel