Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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 0NRF_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

Parents
  • I've generally had more success with the RTTClient. Could you try that as well? I have included some screenshots below to show how I tested it here. We do not have any examples for SWO that I'm aware of. I'm actually not sure if this output is even available on the Jlink lite we have on our DKs. I will find out if you are interested.

    RTT viewer:

    RTT Client:

  • Yes, I would be interested in SWO I think, seems simpler for me.

    I did have auto-detect on in the RTT Viewer.  Just did what you suggested and started JLink in one DOS box:

    Connecting to target via SWD
    Found SW-DP with ID 0x2BA01477
    Found SW-DP with ID 0x2BA01477
    Scanning AP map to find all available APs
    AP[2]: Stopped AP scan as end of AP map has been reached
    AP[0]: AHB-AP (IDR: 0x24770011)
    AP[1]: JTAG-AP (IDR: 0x02880000)
    Iterating through AP map to find AHB-AP to use
    AP[0]: Core found
    AP[0]: AHB-AP ROM base: 0xE00FF000
    CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
    Found Cortex-M4 r0p1, Little endian.
    FPUnit: 6 code (BP) slots and 2 literal slots
    CoreSight components:
    ROMTbl[0] @ E00FF000
    ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
    ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
    ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
    ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
    ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
    ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
    Cortex-M4 identified.
    J-Link>g
    
    **************************
    WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
    **************************
    
    J-Link>r
    Reset delay: 0 ms
    Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    Reset: Halt core after reset via DEMCR.VC_CORERESET.
    Reset: Reset device via AIRCR.SYSRESETREQ.
    J-Link>

    ...but when I start jlinkrttclient in another window it looks the same as yours except no debug is printed below it:

    C:\Program Files (x86)\SEGGER\JLink_V641a>jlinkrttclient
    ###RTT Client: ************************************************************
    ###RTT Client: *               SEGGER Microcontroller GmbH                *
    ###RTT Client: *   Solutions for real time microcontroller applications   *
    ###RTT Client: ************************************************************
    ###RTT Client: *                                                          *
    ###RTT Client: *       (c) 2012 - 2016  SEGGER Microcontroller GmbH       *
    ###RTT Client: *                                                          *
    ###RTT Client: *     www.segger.com     Support: [email protected]       *
    ###RTT Client: *                                                          *
    ###RTT Client: ************************************************************
    ###RTT Client: *                                                          *
    ###RTT Client: * SEGGER J-Link RTT Client   Compiled Nov 27 2018 14:10:37 *
    ###RTT Client: *                                                          *
    ###RTT Client: ************************************************************
    
    ###RTT Client: -----------------------------------------------
    ###RTT Client: Connecting to J-Link RTT Server via localhost:19021  Connected.
    SEGGER J-Link V6.41a (beta) - Real time terminal output
    J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 21 2020 17:30:48 V1.0, SN=683253856
    Process: JLink.exe
    

    This is with the ble_peripheral build still on the NRF52840 DK board.  What am I doing wrong?

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

  • 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?

  • 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?

  • 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

  • Thanks for watching and understood on the other points.  I've made my default to do --chiperase --verify -r to reduce paranoia.  I've also moved those GPIOs of mine to 20, 21, 22 and 23 which seems safest.  My first run after a power-on/download still doesn't work proprly but the rest seem to work at the moment and, though there is still character loss, it is not huge.

    Thanks for all your persistent/consistent attention with this.  I will try SWO later and see if that is any better for me.  If I ever find out what the root cause is I will update this ticket.

    That's good for now, happy isolation!

Reply
  • Thanks for watching and understood on the other points.  I've made my default to do --chiperase --verify -r to reduce paranoia.  I've also moved those GPIOs of mine to 20, 21, 22 and 23 which seems safest.  My first run after a power-on/download still doesn't work proprly but the rest seem to work at the moment and, though there is still character loss, it is not huge.

    Thanks for all your persistent/consistent attention with this.  I will try SWO later and see if that is any better for me.  If I ever find out what the root cause is I will update this ticket.

    That's good for now, happy isolation!

Children
Related