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.

[Antonio Vilei]

Posted on June 11, 2018 at 11:37

Dear Pradeep Choudhary,

how did you implement the printf() function in your code? If you didn't explicitly provide a mechanism to send all messages to a USART port or somewhere else, all printf() calls will end up calling some internal libraries of your debugger tool, and when not connected, your code will fail.

Maybe you could try commenting out those printf() calls and check if this solves your problem.

Best regards,

Antonio 

[Pradeep Choudhary]

Posted on June 11, 2018 at 11:46

Hello Antonio,

I am redirecting _write() function which printf() uses to SWO and hence i get output on SWV console while debugging.And,yeah i  have implemented exactly same code in STM32F401RE where it works fine without debugger so i dont think that printf() is the issue.

Thanks,

Pradeep

[Antonio Vilei]

Posted on June 11, 2018 at 12:29

Hello Pradeep,

I would then try use the

http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-link004.html

 to connect to the chip in HotPlug mode, after you have powered up your board without the debugger. In this way you could try to see if the Program Counter (PC) register can give you any hints about where the actual problem might be.

Best regards,

Antonio

[Tesla DeLorean]

Posted on June 11, 2018 at 14:15

There are some quite significant local variable allocations in main(), make sure you have defined an adequately large stack, and that variables get cleared if required.

[Pradeep Choudhary]

Posted on June 12, 2018 at 12:59

Thanks everyone for the suggestion.I just inserted a delay of 1 sec afterSystemClock_Config() and it started working in stand-alone mode.It would be really great if somebody how insertion of delay after SystemClock_Config() is related with proper booting of MCU.

Hoping for responses from

Turvey.Clive.002

meyer.frank

‌

Vilei.Antonio

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