STM32 Does not boot or work if debugger is not attached to it

[embedonix]

Posted on May 29, 2015 at 20:35

Hi all,

I am facing a strange problem. I have made a usb application on STM32F103RBT6 and it all works good....but if I remove the debugger (J-Link) from the board, the application does not work. I mean nothing works. My board is connected to USB and I am sure there is no power issues.

There might be some settings in the startup.s file or something else that I am not aware of. 

What can be wrong?

#rewrite #flash #stm32f #jlink

[Tesla DeLorean]

Posted on May 29, 2015 at 21:48

Check the state of you BOOTx pins, and what you're doing with the NRESET/NRST pin.

Look more carefully at your code, specifically that you enable all the clocks you are using. The debugger enables things it needs to function, the side effect is that things you're using may also start working despite your code being incomplete/wrong.

Short of that you'll need to waypoint your code with GPIO, LED or USART output so you can understand where it got to or stopped.

[crt]

Posted on May 30, 2015 at 09:47

Hi Clive,

I am facing a similar problem with STM32F4. If the device is not connected to the debugger (i-jet) it starts but it ends up in hard fault during USB Process task. If the debugger is present (or attached during boot) everything works perfectly. Do you have any idea what is the crucial difference between normal boot and boot with debugger?

Thanks, Crt

[embedonix]

Posted on May 30, 2015 at 15:01

Dear Clive, I have checked everything to my limited knowledge...everything seems to be ok...but still not working without debugger. 

I have to point out that this ONLY happens when I generate a project from ST's CubeMX software. If use ST's non-CubmeMX projects as template it works just fine without debugger! I guess there is something with the .s file that CubeMX generates but I have no other clues.

[Tesla DeLorean]

Posted on May 30, 2015 at 17:11

I'm not sure there's a lot of action going on in the .S file. The trick is going to be to identify exactly how far execution is getting, and where it's stuck. I have little insight into your board, or if you have LEDs or USARTs you can use to convey progress.

For Hard Faults you're going to want to implement a functional handler, like those described by Joseph Yiu, and understand where the fault is occurring and the stack/register context. One of the first things to check is that there is an adequate stack allocation, and then whether you have some unhandled interrupts.

[embedonix]

Posted on June 01, 2015 at 03:00

Well....the problem was trivial...I didn't know that I have to remove the deugger complitly from the circuit...apparently unpluggin the debugger from USB is not enough, I had to remove the ribbon cable from JTAG connector as well! I don't know if this is the intended procedure or not maybe you can clear me up. thanks!