# STM32L031 not running after stopping debugging

I'm using a STM32L031 with Eclipse for my application. When in debug mode everything works fine. But when I stop debug mode or power off and on again, the STM32L031 stops working.

And since I'm not using an evaluation board, there is no reset button so I cannot reset it.

How to solve this problem? Or is there a way to reset the chip without requiring the Reset button hardware?

• What is it doing when you 'stop debug mode'? I guess there are some breakpoints still in the code which didn't get cleaned up before you reset. – Sean Houlihane Sep 14 '16 at 11:58
• Have you wired the NRST pin in a way which could prevent normal startup? Do you use some sort of semi-hosting which might prevent normal running (because of hard coded breakpoints)? Is the debugger still connected when you do the power cycle? – Arsenal Sep 14 '16 at 13:18
• If you probably have an SMT resistor on the NRST line, to which you can solder a small wire to pull low for a test reset. Or (at least if your supply is current limited) you can just touch something grounded (or via a low value resistor) to it. – Chris Stratton Oct 14 '16 at 18:56
• You ought to be able to re-attach the debugger to a running target - this will help to investigate where it is stuck. – Sean Houlihane Oct 14 '16 at 19:43
• Supposing you HAVE a pullup resistor on the NRST line just short NRST to ground. If you don't - add a 10kOhm one. Also, how is your BOOT0 wired? – Jan Dorniak Dec 14 '16 at 12:21

When using the debugger, the processor is forced to execute from a certain region.
On power-on reset, the bootloader determines where it should start. Some pins or flash location provide the bootloader with instructions.

One thing that can stop it from running is if you are using semi-hosting. In your project properties, try to remove the following two symbols:

I have multiple projects, and only some of them require the removal of semi-hosting. I haven't yet figured out why it is necessary for some and not others...

Oh, and if powercycling the board doesn't work, then a reset button wouldn't, either.

• Semihosting comes into play if you're using functions that use standard I/O, like printf(). If you don't call those functions, your application is no different with and without semihosting. – duskwuff Oct 15 '16 at 5:51
• @duskwuff No experience with this controller in particular, but AFAIK "hosted application" in C means your code starts with main, as opposed to "unhosted" applications which start at something like __program_start. Incidentally, if you run unhosted, you have to initialize STDOUT yourself before you can use printf, but it may be not the only difference. – Dmitry Grigoryev Jun 27 '17 at 13:26
• @DmitryGrigoryev True, but semihosting is a separate thing entirely. Enabling/disabling semihosting doesn't affect how applications start up. – duskwuff Jun 27 '17 at 16:30

First step is to remove optimization in the compile. You may have some variable that disappears because the compiler optimized it out of existence. If turning off opitmization works, go through the code and declare suspicious variables "volatile"

With debug in place, chances are pretty good that compile optimizations haven't been applied, and then when you turn debug off, those optimizations are performed, and any issues with them become apparent.

• Can you explain how this would cause use of the debugger to change behavior? – Chris Stratton Oct 14 '16 at 18:54
• @ChrisStratton good point – Scott Seidman Oct 14 '16 at 18:58
• I think you're off-base here. The OP isn't uploading a new non-debug build of their software; they're just closing the debugger on their computer. The code is the exact same. – duskwuff Oct 14 '16 at 20:02
• @duskwuff -- at least in my IDE, firmware is uploaded every time you run the debugger. That seems to match the OPs description. – Scott Seidman Oct 14 '16 at 21:03
• When the debugger starts, sure -- I can see that. But when it's closed? – duskwuff Oct 14 '16 at 21:21