• State Not Answered
  • Replies 22 replies
  • Subscribers 65 subscribers
  • Views 3593 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 246839
Options
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

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

  • 0 in reply to RobMeades

    Interestingly, downloading your .hex file, I can see that sometimes it simply doesn't run (the LEDs don't flash in sequence).  It worked the first time I downloaded, but not subsequent times.  What might I be doing wrong?  Download command-line (which is apparently successful) is:

    C:\>nrfjprog --sectorerase --program c:\temp\blinky_pca10056.hex
Parsing hex file.
Erasing page at address 0x0.
Erasing page at address 0x1000.
Applying system reset.
Checking that the area to write is not protected.
Programming device.

  • 0 in reply to RobMeades

    Strange. So just to confirm, are you testing this on a nRF52840 DK with the onboard Jlink debugger?

    RobMeades said:
    What might I be doing wrong?  Download command-line (which is apparently successful) is:

    As you may know, the target is halted after programming. Does it make any difference if you append -r/--reset when you program?

    I also did a quick test with SWO here but was not able to view the messages in the SWOViewer, only in SES:

  • 0 in reply to Vidar Berg

    Ooo, very nice, I like your SWO, I will try that.  Yes, this is an nRF52840 DK with the onboard JLink debugger.

    On the reset, that's curious.  I just tried with --reset on the command-line and it did indeed work, but I took it off again and tried downloading many times, manually pressing the reset button afterwards each time, and that also worked, my system is in a "I don't want to fail" mood now: half an hour ago pressing the reset button did nothing at all, no matter how many times I did it after my download, and no matter how many downloads (of your .hex file) I performed.  It's almost like I'm suffering from bad downloads consistently for some period.  Could I have some setting or other wrong on the board? nRF power source is set to VDD, the nRF ONLY/DEFAULT switch is set to DEFAULT, nothing else is connected to the board, no jumpers etc.  Faulty reset button perhaps (it feels fine to me, pops up nicely)?

  • 0 in reply to RobMeades

    Other things in case they give you any clues:

    1.  It never works the first time after powering the board on or programming the board, I always get a short output, i.e.:

    Starting up...
Printing a hex count 256 * 10 times in a loop...
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDC

    2.  When there is character loss it is a whole NRF_LOG_INFO()'s worth that is lost, so in my case two characters representing a hex number; I never see just a single lost character.

    3.  The "r" command in the JLink commander window never does anything, it never resets the target. It says:

    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.

    ...but your .hex file's LEDs don't start flashing (or re-start flashing if they were already flashing) unless I press the reset button.

  • 0 in reply to RobMeades

    Thanks for confirming. The pinreset functionality is enabled by the startup code during first boot by writing to the non-volatile NRF_UICR->PSELRESET registers (if compiled with CONFIG_GPIO_AS_PINRESET). So the device must be reset through the debugger or by a power-cycle in order for the pinreset to be enabled. Could this possibly explain the inconsistent behavior earlier? 

    startup code:

Related