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.

[PMath.4]

Don't know if it is the same issue or not. I'm launching the bootloader from within code using previously posted examples. This works fine on "Y" and DFU enumerates as expected. On rev "V" this doesn't work - no enumeration. Has the entry point changed on rev "V"?

{
 uint32_t i=0;
 void (*SysMemBootJump)(void);
 
 /* Set the address of the entry point to bootloader */
 volatile uint32_t BootAddr = 0x1FF09800;
 
 /* Disable all interrupts */
 __disable_irq();
 
 /* Disable Systick timer */
 SysTick->CTRL = 0;
 
 /* Set the clock to the default state */
 HAL_RCC_DeInit();
 
 /* Clear Interrupt Enable Register & Interrupt Pending Register */
 for (i=0;i<5;i++)
 {
	 NVIC->ICER[i]=0xFFFFFFFF;
	 NVIC->ICPR[i]=0xFFFFFFFF;
 }
 
 /* Re-enable all interrupts */
 __enable_irq();
 
 /* Set up the jump to booloader address + 4 */
 SysMemBootJump = (void (*)(void)) (*((uint32_t *) ((BootAddr + 4))));
 
 /* Set the main stack pointer to the bootloader stack */
 __set_MSP(*(uint32_t *)BootAddr);
 
 /* Call the function to jump to bootloader location */
 SysMemBootJump();
 
 /* Jump is done successfully */
 while (1)
 {
 /* Code should never reach this loop */
 }
}

[Dub Bartolec]

Hi @Community member​ ,

I assume that if you are mentioning enumeration that you are expecting USB DFU.

Is that correct ?

If answer is YES then this is problem too but you should open another thread for it as it is entirely different problem. Keeping it all together will just confuse people (forum members and ST support people).

It is similar thing but not quite the same.

Similarity is that it does work in Rev Y and not in V and there seem to be cluster of problems in Rev V already. It is taking a quite a while to ST to come up with some answers so far.

However, problem you've discovered looks serious too and needs to be addressed or perhaps they could give us some workarund.

Problem we are discussing here involves UART DFU GO command while BOOT0 is kept high. This effectively makes impossible to run any custom boot loader from RAM (our case).

Your case, equally serious issue, looks like jump into built-in bootloader fails in Rev V.

[Hugues DE CARVALHO]

Hi,

Here is the workaround: use a stack address that is always more than "End RAM @ - 16 bytes". For instance I changed my stack pointer from SP=0x24008000 to SP=0x24007FFF0.

This can be done by changing _estack in the linker file:

This issue originates from a bug in the new bootloader. Here is what happens when the SP is set to the end of RAM:

* A POP on the stack is done by the bootloader after setting the stack value in the code stack.

* As we are using the limit address of the RAM, this POP will cause a hard fault before the jump

This issue should only affect STM32H74xxx/75xxx rev V boards and will be documented in AN2606.

Hugues

[Dub Bartolec]

Hi Hugues,

We've tested suggested workaround and it works. We are not entirely happy that it is needed but nevertheless, it is good we have answers now.

Also at some point ST team mentioned that compiler used to compile application affected the outcome of the test. We did not find that to be the case.

However it is worth mentioning that we are using arm-gcc.

Regards

[Hugues DE CARVALHO]

Hi Dub,

I've been told the following behavior was observed:

-IAR: Works correctly with SP=0x24080000

-Keil, Cube IDE, arm-gcc: Only works correctly with SP=0x24080000-0x10

Please let me know if you have observed a different behavior.

Regards,

Hugues