STM32U5A9 boot fail at low temperatures

[NPato]

Hi,

We have a design that at normal temperatures runs fine (21C). If it goes below 0C it starts failing to boot.

The system has the Secure Boot Secure Firmware Update (SBSFU) system on it. We found that putting a delay at the start of the main() function in bl2_main.c seems to allow it to run. The delay needs to be about half a second.

Then as we reduce the temperature towards -40C we find we need to increase the delay to over a second to get it to work.

Does this sound familiar to anyone? Any ideas what could be going on?

Thanks

Nigel

[Uwe Bonnes]

Do your crystals/oscillators have slow startup times?

[Andrew Neil]

Probably an external hardware issue; eg, clocks (as @Uwe Bonnes said), power supply, reset ...

[STOne-32]

Dear @NPato ,

I tag @CMYL to help , it seems with cold the timing of oscillators are changing , most probably HSI or Similar used inside the SBSFU .

Ciao

STOne-32

[NPato]

Hi,

Thanks all.
We don't believe it's external, we've checked reset against Vdd coming up and Vdd is stable before reset starts rising. The HSE is not active yet, the SBSFU uses the MSI clock. If I connect a debugger using STM32CubeProgrammer (v2.16.0) and use the 'Fault Analyzer' it indicates both instruction and data access faults (IACCVIOL, DACCVIOL).

Could some setup of the MSI in SBSFU need changing?

Thanks

Nigel

[Uwe Bonnes]

Is external memory involved?

[NPato]

No, only using internal memory (FLASH and RAM)

[CMYL]

I don't think so, we need to check the board components, that's why I asked this question.

[NPato]

Thanks all for the suggestions, we've found the problem.
It's related to the MCUBOOT_EXT_LOADER functionality. In boot_platform_init() towards the end there is a check for a BUTTON_PIN state and if high it tries to run a loader image. In our system this pin is not connected and must be floating high when cold causing it to attempt to run the loader image which also looks like it doesn't work.

It is not obvious to know this has to be configured and it is not helped that this pin is defined within the boot_hal.c file see https://github.com/STMicroelectronics/STM32CubeU5/blob/main/Projects/B-U585I-IOT02A/Applications/SBSFU/SBSFU_Boot/Src/boot_hal.c

To solve this we will probably disable MCUBOOT_EXT_LOADER as we probably don't need it.

[Tesla DeLorean]

Watch for this floating/thresholding issue on pins like BOOT0, this should be pulled down in designs to ensure as the voltage ramps and the part attains viability the level is not ill defined. Some people ground the pin directly, but that makes diagnostic/recovery options difficult later. BOOT0 floating issues are recurrent topic on the forum.

The speed the supplies ramp can change based on temperature, humidity, and input voltages, etc. External POR circuits with higher thresholds, or those managing multiple supplies/sequencing can help startup robustness.

[NPato]

BOOT0 has been handled as we knew about that functionality. The problem was the SBSFU loader pin was not obvious functionality, would have helped if this had to be explicitly implemented (maybe in a config function) rather than defaulting to a random pin. That way if you are expecting the functionality you'd implement the required code.