App only works properly when debugging

[Jandyman]

I have an app that works perfectly when run from the debugger, but not when started by HW reset.

We use the serial port to communicate to a control processor (STM32) The Nordic sends a notification to the control processor over the UART after program initialization. The symptom is that when started via toggling the reset line, the UART communication isn't happening properly, because this ACK is never received.

This all used to work fine in both modes, and as mentioned previously it works perfectly if the program is run in the debugger.

Although I've made quite a few changes to the app since it last worked outside the debugger, all of the changes are seemingly unrelated, except one. I now use RTT logging extensively, through the SWD port (not the UART port). I've also cleaned up the UART init code.

Can you think of anything that might cause the serial port to behave differently when run in debug mode?

I can try to open up our target HW, but it is really tiny, so I'm grasping at straws, and I'm not sure how much it will tell me anyway. I also could try running the app on the eval board. It can't really function completely there, but at least I can see whether there is any activity on the UART line and compare debug mode to normal mode.

Thanks in advance for any help!

[FormerMember]

Which LFCLK source does your application use, internal RC or external 32kHz crystal? If external 32 kHz crystal, does your board have a 32 kHz crystal?

[Jandyman]

Hello,

It appears that the LFCLK source is the XTAL:

// <e> CLOCK_ENABLED - nrf_drv_clock - CLOCK peripheral driver
//==========================================================
#ifndef CLOCK_ENABLED
#define CLOCK_ENABLED 1
#endif
#if  CLOCK_ENABLED
// <o> CLOCK_CONFIG_XTAL_FREQ  - HF XTAL Frequency
 
// <0=> Default (64 MHz) 
// <255=> Default (16 MHz) 
// <0=> 32 MHz 

#ifndef CLOCK_CONFIG_XTAL_FREQ
#define CLOCK_CONFIG_XTAL_FREQ 255
#endif

// <o> CLOCK_CONFIG_LF_SRC  - LF Clock Source
 
// <0=> RC 
// <1=> XTAL 
// <2=> Synth 

#ifndef CLOCK_CONFIG_LF_SRC
#define CLOCK_CONFIG_LF_SRC 1
#endif

We do have a 32 kHz crystal between P0.26 and P0.27.

I have few additional pieces of information since I first posted.

First, everything seems work properly on the nRF51 (PCA10028) eval board - I can see the UART init notification whether running from the debugger or pressing the reset button. That's mysterious.

Second, I mentioned before that this used to work, so it isn't HW problem per se. It seems that it was introduced when I moved to SDK 12. I'm sure it is not the SDK 12 at fault, but it was a disruptive change. I had to basically start over again from example projects and then move our app specific code back in.

I tried searching for something that might have changed in the code, but I'm not finding much. Partly because so much has changed. I did see this in the old code though:

    // Setup nReset pin for chip reset (after using as SWDIO for debugging/programming)
    NRF_POWER->RESET = 1;

Finally, I did open up our HW and solder some wires so I could look at the reset and UART lines. It's exactly as I thought. When I start from the debugger, the UART init notification can be seen on my scope. But when I start the program by pulling the reset line low and releasing it, I get no UART notification. But I can see that the program is not dead, because it is still advertising our service. So the issue seems related to the UART peripheral.

[FormerMember]

Okay, I see.  When RTT is running, (I'm quite sure that) the HFCLK is running. And UART does also require HFCLK. In main, could you try to manually start the HFCLK, to check if that could be the problem?

[Jandyman]

That didn't help. But I did find the problem. It turns out that there is a bit in one of the registers that redefines the operation of the nReset pin. It seems that when you start a debug session, the function of the reset pin is changed to "debug mode". So when I pulled on the reset pin after a debug session, my program was actually not resetting at all. Which explains why the startup notification was not being sent.

In a "normal" system, this wouldn't cause an issue, because the first time power is removed from the system, presumably the reset pin will be restored to normal operation. But in our system, the Nordic chip power is always connected to the battery. So you have to explicitly write to this register in the application to restore the normal reset pin function. It's all pretty odd, and essentially means you have to modify the source code every time you want to debug, because writing to this register during debug would screw up the debugger.

I don't know why things worked on the eval board, but I have to conclude that pressing the reset button does a lot more than pulling the nReset line low.

I hope this helps others suffering from the same problem. I didn't find any information about this in the Nordic docs, I had to pore through some old code looking for differences between it and the newer code

- Andy

[FormerMember]

Good work!