nrf52832 not working outside debugger.

[Arne Laugstøl]

Hi

I have a wired situation in my project. Everything is working fine when I am running my heart-rate device with the debugger. When I detach the debugger or just power-cycle the device behaviour becomes wired. The device still advertise, so I can see it from my phone. But, when I try to connect to it from my phone, it will not connect anymore. If I do "connect jLink" from Segger studio, then everything works fine again.

I am using SEGGER_RTT_WriteString a lot, and I suspected that it could be that the output to the debugger via SWD was blocking when I am not running the debugger. So, I have checked in my code that I am doing SEGGER_RTT_Init() at start, and I have set the SEGGER_RTT_CONFIG_DEFAULT_MODE to 0 (i.e SKIP when buffer is full).

I am using nRF52832 with our own HW, Segger Studio and j-Link Ultra. The sdk version 14.2.0.

Any idea where to start looking for a solution?

Regards Arne

[Arne Laugstøl]

Tanks for tips, I will try it out when I am back in office. In the mean time I would like to share another observation that I did: When I connected to the debugger via j-link command window, made a reset and then a g (go) command - Everything works perfect. Just power-cycling without the debugger, then the device will not advertise anymore.

Also, if I connect to the debugger using RTT-viewer, then everything is perfect. (The RTT-viewer seems to reset the device when I connect) If I then disconnect from debugger by a disconnect in RTT-Viewer - suddenly everything continue to work fine. So, it seems that a reset from the debugger makes a difference compared to a power-up reset. Does that make sense?

[Nguyen Hoan Hoang]

Reset is the normal initialization procedure for the debugger to access the debug port. Once the debugger starts the firmware it can disconnect without halting the MCU hence it continues to work after disconnect but won't after a power cycle as you observed.

[jublin]

I know this is old, but what are your compile flags like? I had a situation where -O0 -g3 would do this. going down to g2/g1 helped.

[xiaoding]

I have the same trouble before. After comment out the NRF_POWER->DCDCEN = 1; Everything goes right. 

[hmolesworth]

Longshot, but perhaps worth checking if you are still having issues:

1. Measure the impedance between the Gnd connection on the J-Link and the battery; perhaps it isn't quite what is expected.

2. If there are other devices attached (host MCU or external serial port to PC etc) care is required to ensure no port pins are driving into the nRF52832 SoC during a power-down period. In a simple system with a host MCU typically a UART Rx, Tx and the nRF52832 SoC RST pins will be connected between host MCU and nRF52832 SoC. In that simple case either Rx or Reset pins will phantom power the entire nRF52832 SoC if they are left driven high while nRF52832 SoC power is removed. This is perhaps not unexpected if we assume dual internal schottky diode protection (a clamp diode to both GND and VCC) instead of single internal schottky diode (to GND with low breakdown voltage). This means that to power-down the nRF52832 SoC the MCU code must first drive both UART RX and BLE RST pins low, otherwise the supply of (say) 3 volts only drops to 2 volts or so when the supply is switched off and the nRF52832 SoC therefore does not reset.
In a similar manner, connecting a typical FTDI USB serial port to the nRF52832 SoC can unexpectedly phantom power the part, and stop it correctly resetting or powering down unless the FTDI is first removed. This can cause confusing and unexpected behavior. There is an excellent Dialog publication Training_07_DA1458x_prototype_bring_up_guide _Training_07_DA1458x_prototype_bring_up_guide -v1. 2I 2I_ which actually touches on this without mentioning why:
It is recommended that P0_4 and P0_5 are made available for UART communication during production test and board bring-up. Note that, if the two pins are also used as interface to an external MCU, that this MCU will need to be able to high-Z the pin connected to P0_5
The reason is that resetting the test board doesn't work correctly unless drive to the Rx pin is first removed, including drive from any connected FTDI USB serial port or driving low or floating any connected host MCU.