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

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

[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 12:30

I'd suppose if you knew what the issue was you wouldn't be asking the question. What happens if you comment out the printf or supporting code?

Is this a custom board? Do you pull BOOT0 low?

[Pradeep Choudhary]

Posted on June 11, 2018 at 12:34

Yes,it is a custom board and Boot 0 pin is pulled low and i would comment out all printf() and will share the result.

Thanks and regards,

Pradeep          

[Pradeep Choudhary]

Posted on June 11, 2018 at 13:07

Hello Clive,

I removed all the printf() from my entire project,still the same problems persists.I have exactly same kind of circuitry around STM32F401RE and when i use same code with it,then code runs fine without debugger.

Regards,

Pradeep

[AvaTar]

Posted on June 11, 2018 at 13:29

Did you modify the startup-code ?

I use the Rowley Crossworks IDE, and they use to keep debug version of the code in an endless loop at startup, waiting for the debugger to connect.

[Pradeep Choudhary]

Posted on June 11, 2018 at 13:37

No,i dint modified startup code and it is as follows:-

♯ Set flash parallelism mode to 32, 16, or 8 bit when using STM32 F2/F4 microcontrollers

♯ 2=32 bit, 1=16 bit and 0=8 bit parallelism modemonitor flash set_parallelism_mode 2

♯ Load the program executable

load

♯ Reset the chip to get to a known state. Remove 'monitor reset' command

♯ if the code is not located at default address and does not run by reset. monitor reset

♯ Enable Debug connection in low power modes (DBGMCU->CR)

set *0xE0042004 = (*0xE0042004) | 0x7

♯ Set a breakpoint at main().

tbreak main

♯ Run to the breakpoint.

continue

If you find something wrong in it which can halt execution,then please let me know.Also,i have used same startup code for a simple GPIO toggling code and it works fine when debugger is not connected.

Regards,

Pradeep