Application does not start without debugger connected

[bloobird0]

Hello,

in my current project we develop a BLE firmware which runs on a custom board based on a Telit +s42 module (with integrated nRF52 SoC).

We are able to flash the module via SWDIO/SWCLK connected to the debug out connector of the nRF52DK. After the firmware is correctly flashed via nRFGo studio, the application is running (it is advertising and we see our debug messages in RTT viewer).

Unfortunately, when the debugger is not connected i.e: only power is applied to the module, nothing happens: no advertising nor debug messages in RTT viewer.

Do you have any idea where I can have a look in order to be able to run the firmware without the debugger connected.

Thanks in advance

[bloobird0]

Hello butch, you're right without the debugger connected, RTT viewer can't display anyting ;-)

I've been further and I can't identify where I should look at:

• I updated the firmware to continuously toggle a pin so that I can see the device running with the oscilloscope. The first thing that the firmware does is toggle the pin so I should be able to see it toggling even if a restart occurs soon after power on.
• I flash the custom board from Keil or nRF Go Studio through the nRF52DK. After the flash, the pin does not toggle.
• it starts toggling only when I start RTT Viewer (nRF52DK still connected). I output the RESETREAS value which is 0x0004: software reset. I guess that RTT Viewer writes in the RESET register. Am I right?

Now I disconnect the custom board from the nRF52DK. I apply a power cycle. The pin is not toggling. I expected a power on reset to happen. I plug the nRF52DK debugger: the pin is not toggling. I start RTT viewer: the pin is toggling.

I understand that the custom board remains in a reset state until the RTT viewer sets a software reset.

Do I have to initialize anything in the firmware so that it starts when power is applied?

The reset pin is not used.

[butch]

I would study the sw and hw configuration of the SWD pins (CLK and DIO) on the custom board. I think any debugger can reset (or hold the mcu in reset) by some signal on those pins. For example, maybe the pins must have a pullup resistor so they don't float? (I don't really know, I am just guessing that in your case without a debugger connected, the pins might be holding mcu in reset.)

I assume you have not changed the standard POR reset interrupt vector and the other standard C startup code including SD startup?

BTW, I don't think you should answer, but should comment, so that others don't see that it has been "answered" and skip reading your thread.