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.

[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

[Dub Bartolec]

Hi Hugues,

That is good. It is good idea to put that into AN2606 too.

Dub