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]

Hi you

Thanks for trying to help me out!

I commented out all the code in SEGGER_RTT_printf and SEGGER_RTT_WriteString. That's the only call I am doing to RTT. That gave the same results as earlier. Everything works fine when J-link is connected. When I disconnect j-link or power-cycling, then I am not able to connect anymore, even if my device is advertising.

Regards Arne

[Nguyen Hoan Hoang]

Try to look for rtt in sdk_config.h. There is a define that enabled it in there some where and disable it there. If it is enabled in there, most likely be used throughout the sdk not just in your code. Do a clean compile after you disable it in the sdk_config.h. That is what I did and it worked for me.

[RK]

Well removing all the RTT calls wasn’t likely to actually help as RTT itself isn’t the problem, as explained, by me and by Segger. So what else could it be, one possibility is that when you connect the debugger that also connects up the UART, did you leave the UART enable code in? That actually can block trying to do UART writes.

Another option is to get it blocked, THEN attach the debugger which you can do to a running board and breakpoint and find out where you are. Segger’s ozone (free) debugger is kind of handy for that, it’s very bare bones, or just use the command line.

[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.