Program doesn't run properly when debugger is not connected in STM32L476RE MCU

[Pradeep Choudhary]

Posted on June 11, 2018 at 08:33

Hello,

I am using STM32L476RE MCU for one of my application which publishes some data to server using MQTT and my wifi module communicates with MCU with USART2.I am using atollic truestudio to write a code and debug it.I am using ST LINK V2 as my debugger.Now the problem that i am facing is that when i flash a code to MCU and debugger is connected then it runs fine but as soon as i remove debugger and turn off power and again power up the circuit then it doesnt work.I wrote a simple code for GPIO toggling it runs fine without debugger connected.I have attached the code that i have wrote.Same code works absolutely fine with STM32F401RE.Please help as soon as possible.

Regards,

Pradeep Choudhary

#stlink-v2 #stm32l4 #por-issue Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Pradeep Choudhary]

Posted on June 12, 2018 at 12:04

Hello Clive,

I would like to mention one more observation which might lead to some solution.Code runs properly not only when debugger is connected to PC but also when it is connected to any power source like 5V adapter or Power bank.

Regards,

Pradeep

[Tesla DeLorean]

Posted on June 13, 2018 at 15:59

I think I've already provided specific direction about how to figure out what is happening.

You can provide me with hardware, and I'll develop a specific opinion about what is going on.

[Pradeep Choudhary]

Posted on June 13, 2018 at 16:21

Hello Clive,

I have attached schematic of my circuit around MCU.Please have a look at it.

Regards,

Pradeep

________________ Attachments : MCU.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxVX&d=%2Fa%2F0X0000000az3%2FWhjsa7ay9yVgKIqqMi4v96cBY782HFuFO7TskRXbp6E&asPdf=false

[Dirk Vermaak]

Posted on June 14, 2018 at 09:38

Three observations

1) No pull up on the nRST line. All the Nucleo baords etc. and all the designs we have ever done (30+) have a pull up on there to the main rail.

2) Unless they are elsewhere, you have missed off the uF capacitors that should also be placed on the power pins. See Page 113 of Datasheet Revision 7. Basically, we always adhere to to the requirements on this page. In nearly 10 years with the STM32 we have never had a problem starting a device but have always followed these guidelines closely.

3) Check that all your devices will run at the lowest run Voltage of the STM32L47. It might be that the processor is running before other devices are ready. We had this with an FRAM once. The processor started at 2.0V but the FRAM didn't work until 2.7V so we just read back 0. The code didn't expect this. Adding a 1 second delay makes me suspicious that you might have this problem. With the degugger on, the power is up and the reset comes from the debugger hence there is no issue, but from a free power start it wouldn't work.

Definitely sounds like a hardware/power/reset problem to me, although you might be able to work around in the code.

[Wilco van den Brink]

Posted on June 14, 2018 at 12:09

Did you disconnect the USB-cable of the debugger or the connector to your board? I had the same issue and it turned out that the ST-LINK keeps the MCU in reset mode while it's not powered from the USB connection.

[Manoj Hiwarkar]

Posted on June 14, 2018 at 12:53

You need to configure the 'serial wire' in the debug section of stm32CubeMx.

[Evgeny Kirshin]

Posted on June 14, 2018 at 20:40

Hi,

You write that you have a Wifi module. Is it powered from the same board? Wifi modules are quite power hungry, especially at startup. Might it be a drop on your power line, which affects proper MCU start, especially as you seem to be a bit low in capacitance on VDD pins? 

Also, I would look at initialization procedure. How do you start talking to your Wifi module? Do you wait for any response from it? Could it happen that your MCU starts talking to the Wifi module sooner than it is ready at startup? Then, your one second delay fixes this problem by delaying communication with the Wifi module. 

Good luck.

Evgeny

[pskinge]

thanks for sharing bro i am also facing same problem and solved after addding 1sec delay after SystemClock_Config();