cancel
Showing results for 
Search instead for 
Did you mean: 

Observed delay during bootup

sameeksh
Associate

Hi,

I have two batch of boards with STM32F437 controllers.
Batch1: It takes the controller 1.2seconds to come up
Batch2: It takes the controller 200msec to come up
Both the hardware and the firmware are same.
In the Batch1, when the power up is done it takes 1.2second, but when I press hard-reset switch it takes only 200ms to come up. But in Batch2, it takes 200ms with power cycle or with hard reset.


By toggling a gpio pin for execution of every function, we got to the point where the delay is happening. It was in the image_validation() function in the bootloader code. Here the function does a CRC check using a while loop, that is taking 970ms in batch1 boards and 120ms in batch2 board. But how can a purely software operation causes this delay?!

 

Apart from the bootup speed, all the other functionality is working as intended.
We have already thoroughly analyzed the BOM, there to no difference that was seen.

The only difference I can see is that the label imprinted on the STM32 controller is different for these two batches:
Batch1:

ALPHA_controller.jpg

Batch2:

BETA_controller.jpg
Any help is appreciated.

 

Thanks, and regards,
Sameeksh Shetty



 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Danish1
Lead II

One possibility - if you have an external crystal - is that it takes a certain time for that crystal to start singing from power-on, but much shorter from reset (as it was already oscillating before the reset).

One second is a long time in microcontroller terms, so that makes me think it could be the LSE crystal. Quite why that would make things slow in image_validation() I don't know.

But it might also be HSE, and if HSE doesn't start then the processor clocks itself off the power-up default of HSI. But if HSE does start, then your startup code turns on the PLL so the processor is much faster (perhaps 8 times faster).

As for consistency between batches. That could be slight differences in the gain of the amplifier used in the crystal oscillator for the two batches of stm32, or different characteristics in the crystals mounted on the boards. ST have an application note on how to check that you have enough gain "in reserve" to cope with process variations.

View solution in original post

2 REPLIES 2
Danish1
Lead II

One possibility - if you have an external crystal - is that it takes a certain time for that crystal to start singing from power-on, but much shorter from reset (as it was already oscillating before the reset).

One second is a long time in microcontroller terms, so that makes me think it could be the LSE crystal. Quite why that would make things slow in image_validation() I don't know.

But it might also be HSE, and if HSE doesn't start then the processor clocks itself off the power-up default of HSI. But if HSE does start, then your startup code turns on the PLL so the processor is much faster (perhaps 8 times faster).

As for consistency between batches. That could be slight differences in the gain of the amplifier used in the crystal oscillator for the two batches of stm32, or different characteristics in the crystals mounted on the boards. ST have an application note on how to check that you have enough gain "in reserve" to cope with process variations.

Hi Danish,
The things you pointed out was on point.
Here are the waveforms of VCC,Reset and clock for both the batches:
Batch1:

sameeksh_0-1717562638908.png

Batch2:

sameeksh_1-1717562659837.png

As you can see form these snippets, in batch1 the STM is coming up before the clock. Since the HSE is not available it utilizes the HSI for the booting up. That is why it boots up slowly. Where as in the batch2 boards, HSE is utilized for booting.

This happened because of the faulty 25MHz oscillator. When we physically removed the oscillator from batch2 and placed on batch1 boards, it too started booting quickly.

sameeksh_2-1717562985703.png

Thank you for guiding me in this direction. It really helped to find the root cause and mitigate it.

Best Regards,
Sameeksh Shetty