Example that logs over Segger RTT requiring no configuration changes by me

[RobMeades]

I'm trying to get debug output to appear in my Segger J-LINK SWO viewer (from an NR52840 SDK board with NRF5 v16) which I understand is a potentially complicated process; I've received nothing in the SWO viewer so far.  Do you have an example which sends debug output to Segger RTT by default, without me screwing anything up, i.e. all I have to do is make flash, just so that I can check that the connection and the Segger tools are good (not that there's much that can go wrong with them)?

FYI, in my sdk_config.h I have NRF_LOG_ENABLED 1,  NRF_LOG_BACKEND_RTT_ENABLED 1, NRF_LOG_BACKEND_UART_ENABLED 0, NRF_LOG_DEFERRED 0 and NRF_LOG_DEFAULT_LEVEL 3 and in main.c I start with:

NRF_LOG_INIT(NULL);
NRF_LOG_DEFAULT_BACKENDS_INIT();

NRF_LOG_INFO("Hello world.\n");

In the Segger SWO viewer I've selected nRF52840_xxAA, let it measure the clock, selected channel 0, the green LED near the PCA10056 on the board is flashing regularly and I pressed the reset button on the board. Nada.

Oh, and I also have the defaults for the Segger RTT settings, i.e.:

#define SEGGER_RTT_CONFIG_BUFFER_SIZE_UP 512
#define SEGGER_RTT_CONFIG_MAX_NUM_UP_BUFFERS 2
#define SEGGER_RTT_CONFIG_BUFFER_SIZE_DOWN 16
#define SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS 2
#define SEGGER_RTT_CONFIG_DEFAULT_MODE 0

Rob

[RobMeades]

My Makefile does have -DCONFIG_GPIO_AS_PINRESET in both CFLAGS and ASMFLAGS but even power-cycling the board doesn't do it for me, the "r" command never has any effect.

I tried the same thing with your .hex file and specifying --reset on the command-line and, interestingly, then "r" stops the processor dead: the LEDs stop flashing and stay stopped.  Only pressing the reset button on the board starts them again.  Is that what you would expect?

[Vidar Berg]

The 'r' command in Jlink commander does a reset then immediately halts the target. You need to type 'g' /go after to start execution.  But I'm not sure why it's not running after power-cycling the board. That is not as expected.

[RobMeades]

Understood, I will use "r" and then "g".  As to the rest of this, I've just had the situation where nothing works once more and have taken a YouTube video of that case, just so that you can see absolutely everything that I can (when my mobile phone's camera wants to focus) and all the things I try.  I've also uploaded a YouTube video I made just before this when I thought everything was in "non working" mode and instead it decide to work, just to prove that it is able to work.  These videos are currently uploading and can be found here:

Non-working case: https://youtu.be/mOo_iqvC8LQ

Working case: https://youtu.be/nuHNP4PzsLA (this is rather shorter and so has now finished uploading)

FYI they are unlisted videos with comments etc. disabled and I will delete them once we're done with this.

What am I doing wrong?

[RobMeades]

A possibility: my code will eventually use GPIO lines and, even though nothing is connected to them at the moment, I was letting it configure those GPIO lines and had chosen 10 & 12 as outputs and 11 & 13 as inputs.  I've just noticed, reading the back of the PCB, that 10 is NFC2, 12 is button 2 and 13 is connected to an LED. Could setting these as output/output/input respectively somehow prevent subsequent downloads of your .hex file from working, 'cos it remembers the GPIO settings (recalling that you said something about the GPIO as reset thing being stored in NV settings, rather than being something which the code sorts out when it loads). Should I always do an --eraseall instead of a --sectorerase to be safe?

[Vidar Berg]

Thanks for the videos. I watched through both. "unfortunately", you're doing everything right. The board switches are also in the correct positions. So I find this very strange. Particularly that it's not consistent and that programming works correctly.

The LED pins will always have the default configuration when coming out of a reset (input - disconnect). P0.18 is different because it has the optional pin reset functionality (NV reg - PSELRESET[n]). The NV register settings changes the reset configuration for that pin only. 

You can use --eraseall to ensure that all NV settings are erased. And you can use --verify for good measure. Eg. nrfjprog --program app.hex --chiperase --verify -r