STM32L562QEI6 does not start up at power on

[jeroen]

Hi All,

I have a start up problem with the STM32L562QEI6.

While using the STM32CubeIDE debugger, the code runs fine but without the ST-LINK/V2 connected, the board remains "dead" after applying the power supply.

When I manually pull the nRST pin down before applying 3V3 and then release it, the board remains "dead". If I then pull it down a second time and release it, the board starts as expected.

So it looks like the first reset puts it in some (boot?) mode in which my code is not executed.

Some facts:

• nRST is connected to a 100nF capacitor (and the STLINK debug connector)
• nBoot0 is pulled down with a 2K resistor
• All power pins (VDD, VDDIO, VDDA, VDDUSB, VBAT) are connected to the same 3.3V supply
• The power supply ramps up with a straight line to 3.3V in 0.8 ms
• The nRST pin ramps up in accordance with the connected capacitor (RC curve) in about 10ms
• (see attached screen dump, yellow = power supply, purple = nRST)
• I have tried different settings for BOR, from 1.7V to 2.5V without no change

The current board is a migration from a previous version which is exactly the same except for the processor which used to be an STM32L433CCU6. All equivalent pins are connected in the same way.

With the 'L433' variant, we never did have any startup problem.

The only two differences are :

• STM32L562QEI6 instead of STM32L433CCU6
• Development with STM32CubeIDE instead of IAR EWARM

Both variants use the STM32 HAL drivers.

As you may understand, I'm out of ideas. It is probably a minor detail that I'm missing.....

Any help is highly appreciated !

Jeroen

[MM..1]

As first try remove 100n from nRST

[jeroen]

Nope, removing the 100n did not change anything. I still have to manually apply an external reset after power up before my firmware starts.

Thanks for the suggestion anyway !

[TDK]

Attach a debugger when the board is in the stuck state to determine where it is. Could be in the bootloader, but could also be stuck in user code waiting for something to come up.

[jeroen]

Good suggestion, I'll try it as soon as I have found out how to attach the debugger to a running target with STM32CubeIDE.

[TDK]

To debug your program without downloading it:
Go to Debug Configurations... -> Startup -> select load image -> Edit... -> uncheck Download
To debug without resetting the device:
Go to Debug Configurations... -> Debugger -> in Reset Behavior, select "None"
Ensure the st-link is powered before you connect it.

[ssipa.1]

I don't know much about the STM32s so I can only speak in general about what my be the problem...

It sounds like your oscillator is either failing to start or is locking up. You might switch to the internal RC oscillator just to see if you have start-up issues with it. If not then that will narrow it down.

An oscillator will fail to start if there is too little or too much capacitance on the oscillator pins. I assume you have something like figure 31 from the datasheet (page 84.) You might play around with the values of CL1 and CL2 to see if it helps.

Also, supposedly, an oscillator can lock up if there is too much noise in the environment. The recommendation, in that case, is to use mismatched values for CL1 and CL2, with the capacitor at the input pin being slightly larger. (I'm guessing that would be CL1.)

[jeroen]

Thanks for your help.

First of all, there is no external oscillator, so I'm already using the internal clock.

It would also not be logical that the oscillator works better after a second reset. It's not a matter of startup time since I still have the problem when I force nRST low when the supply comes up and I can keep it low for several seconds, still without success. I need a second reset to start my code

[MM..1]

Try Boot0 pull down with a 1K resistor

[jeroen]

I can even tie it directly to GND without any change. In fact, I already monitored this pin on the scope at the same time as Vdd and nRST and it is always at e few mV max.

[MM..1]

then only debuger to problem can help seems as hardfault or other while 1 error

[jeroen]

Problem solved. The source of the problem was the (windowed) watchdog. By disabling it, the firmware executes as expected.

I still have to find out what happens exactly since I need the watchdog to function. But that's another issue...