STM32F746 doesn't start up

[Lars Beiderbecke]

A STM32F746 on a custom board powered by the step-down regulator TPS62082 by TI doesn't start in about 90% of cases.

I flashed (which always works fine) a simple test program, which flashes two LEDs alternately:

int main(void)
{
 HAL_Init();
 SystemClock_Config();
 MX_GPIO_Init();
 
 while (1) {
 LED1; // LED1 on, GPIOx->BSRR = ...;
 LED20; // LED2 off, GPIOx->BSRR = ...;
 HAL_Delay(1000);
 LED10; // LED1 off
 LED2; // LED2 on
 HAL_Delay(1000);
 }
}

The STM32 runs at 200 MHz, using HSI and LSI. In about 10% of cases after power on, the LEDs light up. The other 90%, both LEDs remain dark. If the LEDs remain dark, a manual reset by pulling NRST low always starts the STM32.

The first idea was that there is a power issue, but I set the Brown Out Reset level in the option bytes to around 3V. Looking at Vin (3) and Vout (1) of the regulator, voltage seems to be fine. (2) is the output of a GPIO output which was initialized to HIGH in MX_GPIO_Init() -- but it remains LOW, which means the program is not executed.

The duration until the voltage has risen to 3.3V is more than 1ms, but according to the datasheet the rise time doesn't matter (if it's not too short).

Looking at the NRST pin (with only a 10K pullup attached, but no flasher device), this is curve (3) while (1) is Vout, i.e., Vdd of the STM32.

The increased BOD level seems to work; the STM32 starts working after the voltage is stable.

Thus, the voltage doesn't seem to play a role in the STM32 not starting up. What else could prevent a startup?

[TDK]

Is BOOT0 pulled low?

[Tesla DeLorean]

I think we crossed that bridge already.

Probably is starting

Get the Error_Handler() and HardFault_Handler() properly instrumented so you can see if it dies there.

Get code in the Reset_Handler to set some GPIOs or squawk a couple of bytes to a UART using the HSI the chip starts with.

[Lars Beiderbecke]

The problem with that is that the debugger doesn't even reach the main() breakpoint. That implies that an error handler (if that is the issue) is hit before peripherals are initialized, thus lighting LEDs via GPIO doesn't work.

So far I couldn't think of anything that would signal the outer world that an error handler was hit -- without using the debugger.

[Altamash Abdul Rahim]

• Also check verify the clock configuration(SW+HW)
• Please check the value of capacitor and resistor in the reset(NRST) circuit.
  • I had this issue in a different MCU because the supply was no that good. In my case the value of resistor used was less than the actual advised value.

[Lars Beiderbecke]

As said, I'm using HSI and LSI, and that is what's configured in CubeMX.

I don't have a capacitor for NRST (I missed it), but then should its effect not be similar to raising the BOD level? If you look at the last graph, you see that NRST goes HIGH well after the voltage is stable. If I'm not mistaken, that's the entire point of the NRST capacitor (together with the resistor, an RC delay element).

[Altamash Abdul Rahim]

I still feel that the problem is related to the rise time. You give it a try with appropriate hardware RC elements.

[waclawek.jan]

> PC = 1FF01752

That's bootloader.

> I think we crossed that bridge already.

Obviously, not quite.

JW

[Lars Beiderbecke]

At first, I did connect BOOT0 incorrectly, but I fixed it with a wire on my board. I did measure the fixed BOOT0 pin, and it is LOW now. Also, in about 5-10% of cases, the STM32 starts normal.

And if I switch to a power plug (the board has two power sources), the start rate is above 90%.

What other causes could start the bootloader?

[MM..1]

Try use other point to wire BOOT0 , short and maybe to same stm packge pin gnd. Your measurement is need on starting power transition, after this is maybe LOW, but this isnt relevant ...

[waclawek.jan]

> At first, I did connect BOOT0 incorrectly, but I fixed it with a wire on my board.

Post photo.

Check continuity between ground and the *pin* (by that I mean physically the pin as it protrudes from the plastic).

> What other causes could start the bootloader?

See AN2606, or direct jump from your program.

JW

[TDK]

> So far I couldn't think of anything that would signal the outer world that an error handler was hit -- without using the debugger.

You can write code within the error handler that toggles an LED. Enable the GPIOx clock, then set GPIOx->BSRR appropriately.

Still think it's a BOOT0 issue.

> If I'm not mistaken, that's the entire point of the NRST capacitor (together with the resistor, an RC delay element).

The cap is there to avoid spurious resets which happen if high frequency noise is transferred to the NRST line. The BOR takes care of ensuring the voltage is sufficient.

[Lars Beiderbecke]

Thanks and sorry, you were right the entire time!

Would've selected you as best answer, but Jan also had the hint with the bootloader, which put me on the right track.