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?

[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]

> 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

[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 ...

[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]

It turns out my fix for the BOOT0 level was shaky (I soldered the SMD pull-up sideways so that it wouldn't touch Vdd, then soldered a wire from Vss to the other end of that pull-up). After resoldering that connection properly, the start problems vanished.

Thanks for the hint about the bootloader, that put me on the right track.

[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.

[Tesla DeLorean]

The original thread for context's sake https://community.st.com/s/question/0D53W00000RQR3uSAH/stm32f746-forgets-flashed-program-and-more

>>What other causes could start the bootloader?

Newer STM32 can also enter this mode if the primary flash (or banked if optioned) doesn't look to contain a valid vector table and entry points at expected address(es), or is simply blank.

L4 and H7 for sure latch BOOT0 at power-up, this is not subsequently cleared by an NRST, but requires a power cycle to run user code.