Hey together,
I discovered a super strange a critical behaviour of the STM32H750 chip. Maybe you can help me to prove this issue.
We have a firmware which is split into 2 parts (bootloader, application). Both BL and APP are using the UARTs to communicate internally. We created a new APP which changes some clock mux settings for the UART for testing. Important is the change from PCLK2 to PLLQ2, in the last APP we used in both PCLK2.
But now when we jump from the APP to the BL with NRST, we stuck from time to time at the "HAL_UART_Init()" in the line 371
return (UART_CheckIdleState(huart));The UART is wating for the TEACK flag after enabling the TE flag of the UART. This polling is important as the TE flag is set by the CPU while the TEACK flag is set by the UART peripheral which is clocked by the clock mux. Here is a link to the description:
EFTON - STM32 gotchas - Gotcha 141
But when you stuck here, you can do whatever you want, pull NRST down as long as you want, or even reflash the bootloader, you will stuck here. The only way to get out of this is either by power cycle the full chip or reflash the bootloader so that it is using the same clock mux setting the UART was using in the APP before (in this case change it to PLLQ2). Then the UART can reinitialize and go back to work. I proved this on multiple PCBs and different clock settings.
This is easy to prove:
- Create a BL which is using PCLK2
- Create an APP which is using PLLQ2 and jump with a GPIO into the BL.
It does not happen always, but often enough to catch it.
So it seems that NRST is not completly reseting the UART peripheral and then a change of the clock source bricks the peripheral from setting the TEACK. This is super dangerous, as this makes the BL dependent from the APP.
Just imagine during a firmware update, there is a corrupted file programmed which uses PLLQ2. You want to run a new firmware update, jumping into the BL and you stuck in the UART initialisation.
Did anyone else discovered this behaviour?
HAL Version STM32H7 v1.11.1-0
