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

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

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 !

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

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

[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

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

[jeroen]

Thanks, found it.

I first have to fix another issue that just popped up : when starting the debugger (not in attach mode) it erases the memory and the downloads the new code ... or it should at least.During verification it complains about a data mismatch at the first address (0x08000000 (byte = 0xFF instead of 0x00)).

When connecting to ST-LinkV2 with the Cube Programmer (without disconnecting anything physically), the memory is indeed erased !

With the programmer, I can reprogram the last generated .elf file.

So this has something to do with the IDE, the processor and the ST-LinkV2 are OK....

[MM..1]

Try Boot0 pull down with a 1K resistor