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

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

Vidar Berg — Fri, 27 Mar 2020 08:17:38 GMT

I just wanted to make sure it wasn't a driver issue, so I repeated the tests on my end with JLink v6.64b, but it didn't seem to make any difference. The Segger project I used for test is attached below (extract to /examples/peripheral/ to build)

devzone.nordicsemi.com/.../blinky_5F00_logging.zip

Stay safe!

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

RobMeades — Thu, 26 Mar 2020 14:54:09 GMT

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!

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

Vidar Berg — Thu, 26 Mar 2020 14:05:49 GMT

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

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

RobMeades — Thu, 26 Mar 2020 13:51:12 GMT

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?

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

RobMeades — Thu, 26 Mar 2020 13:17:49 GMT

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?

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

Vidar Berg — Thu, 26 Mar 2020 12:28:19 GMT

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.

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

RobMeades — Thu, 26 Mar 2020 12:10:24 GMT

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?

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

Vidar Berg — Thu, 26 Mar 2020 11:56:40 GMT

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:

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

RobMeades — Thu, 26 Mar 2020 11:52:12 GMT

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.

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

RobMeades — Thu, 26 Mar 2020 11:32:25 GMT

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

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

Vidar Berg — Thu, 26 Mar 2020 10:56:52 GMT

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

[quote userid="68812" url="~/f/nordic-q-a/59495/example-that-logs-over-segger-rtt-requiring-no-configuration-changes-by-me/241786"]What might I be doing wrong? Download command-line (which is apparently successful) is:[/quote]

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:

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

RobMeades — Thu, 26 Mar 2020 10:50:00 GMT

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.

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

RobMeades — Thu, 26 Mar 2020 10:28:30 GMT

There seem to be two distinct behaviours. I've switched to the release version of the JLink tools (6.64B) and I find that sometimes I get absolutely nothing at all from the target, no matter how many times I power it down, restart JLink, restart jlinkrttclient etc. Other times it bursts into life and stays working for a while and in that situation I see lost characters, sometimes all of them past a certain point in execution, sometimes just a few.

I changed main() to just do this:

int main(void)
{
    NRF_LOG_INIT(NULL);
    NRF_LOG_DEFAULT_BACKENDS_INIT();

    NRF_LOG_RAW_INFO("\nStarting up...\n");
    NRF_LOG_RAW_INFO("Printing a hex count 256 times in a loop...\n");
    for (size_t count = 0; count < 256; count++) {
        NRF_LOG_RAW_INFO("%02x", count);
    }
    NRF_LOG_RAW_INFO("\nDone.\n");
    while (1) {};
}

...and sometimes it just stops in the middle, which you can see in the second case here:

Starting up...
Printing a hex count 256 times in a loop...
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
Done.

Starting up...
Printing a hex count 256 times in a loop...
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF
Starting up...
Printing a hex count 256 times in a loop...
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
Done.

Other times it loses characters, which if you look carefully you can see in the output here where it loses four prints, eight characters on the 6th iteration (I've inserted spaces so that you can see the gap):

Starting up...
Printing a hex count 256 * 10 times in a loop...
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2F3        03132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
Done.

In these cases the viewer is still running, if I press the reset button on the target and it's in a "working" phase it reads the new output, it seem that the target either stopped or lost all further characters or lost some characters. I had assumed that with NRF_LOG_DEFERRED 0 the NRF_LOG_RAW_INFO() call should act just like a printf() and block until all characters are sent, so there shouldn't be a timing/buffering issue.

Maybe I should go try that SWO, see if it is more reliable...? Are there any other reliability things you might suggest? I'm using a 15 cm long USB cable and I've tried this on all the USB ports on my (Dell) laptop.

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

Vidar Berg — Thu, 26 Mar 2020 08:34:50 GMT

I have seen some issues with the RTT viewer, but the RTT itself has been reliable in my experience (I'm usually viewing the logs in the SES IDE). I noticed now from your logs that you are using a beta release for the J-link, maybe that's the problem. Could you try to update it?

Simple Blinky example with RTT logging:

devzone.nordicsemi.com/.../blinky_5F00_pca10056.hex

I found this old thread I had on SWO: https://devzone.nordicsemi.com/f/nordic-q-a/31263/itm_sendchar-with-pca10056-nrf52840. As you can see, it will still require some configuration to get working plus we do not have a logger backend for it.

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

RobMeades — Wed, 25 Mar 2020 18:15:36 GMT

No, even that's not consistent, it just seems to be unreliable.

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

RobMeades — Wed, 25 Mar 2020 18:05:27 GMT

It seems to work only the first time after JLink connects. If I do a reset (pressing 'r' in JLink commander, or pressing the reset button on the board) nothing more comes out; I have to restart JLink commander and then does stuffs appear in the RTT viewer once more.

Any clues as to why that might be?

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

RobMeades — Wed, 25 Mar 2020 17:59:31 GMT

Hmmm. Haven't been able to do it again though. Any hints on reliability? I've tried reducing the speed from 4000 kHz to 1000 kHz but that doesn't seem to have helped.

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

RobMeades — Wed, 25 Mar 2020 17:39:34 GMT

Ooo! Belay that, I just built and download my own build to my board and J-Link RTT client suddenly burst into life:

<info> app: Hello world.

<info> app: CELLULAR_PORT_TEST: tick time now is 0.

<info> app: CELLULAR_PORT_TEST: creating a mutex...

<info> app:                     returned error code 0, handle 0x20000978.

<info> app: CELLULAR_PORT_TEST: creating a queue...

<info> app:                     returned error code 0, handle 0x200009c0.

<info> app: CELLULAR_PORT_TEST: creating a test task with stack 2048 byte(s) and priority 12, passing it the pointer 0x20000220 containing

Obviously I'm doing something right, just need to figure out the sequence. Thanks for your help, if you have anything on using SWO then do let me know.

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

RobMeades — Wed, 25 Mar 2020 17:02:34 GMT

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: support@segger.com       *
###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?

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

Vidar Berg — Wed, 25 Mar 2020 16:43:53 GMT

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:

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

RobMeades — Wed, 25 Mar 2020 16:29:03 GMT

Ah, apologies, I thought RTT was the same thing as SWO. Do you have SDO out also, nice and standard...?

Anyway, RTT shows the same thing: all seems to start up OK but no sign of any of my debug.

I tried that example you pointed to, which built and downloaded fine, but I still don't see anything in the RTT viewer. RTT viewer connects (see output below) and the green LED on the board flashes more rapidly but no text ever appears in the terminal window. What else might I be doing wrong?

LOG: Connecting to J-Link via USB...
LOG: Device "NRF52840_XXAA" selected.
LOG: InitTarget() start
LOG: InitTarget() end
LOG: Found SW-DP with ID 0x2BA01477
LOG: DPIDR: 0x2BA01477
LOG: Scanning AP map to find all available APs
LOG: AP[2]: Stopped AP scan as end of AP map has been reached
LOG: AP[0]: AHB-AP (IDR: 0x24770011)
LOG: AP[1]: JTAG-AP (IDR: 0x02880000)
LOG: Iterating through AP map to find AHB-AP to use
LOG: AP[0]: Core found
LOG: AP[0]: AHB-AP ROM base: 0xE00FF000
LOG: CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
LOG: Found Cortex-M4 r0p1, Little endian.
LOG: FPUnit: 6 code (BP) slots and 2 literal slots
LOG: CoreSight components:
LOG: ROMTbl[0] @ E00FF000
LOG: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
LOG: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
LOG: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
LOG: ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
LOG: ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
LOG: ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
LOG: RTT Viewer connected.

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

Vidar Berg — Wed, 25 Mar 2020 16:18:30 GMT

Hi Rob,

RTT is printed out on the SWDIO line instead of SWO. Could you try the RTTViewer instead and see if it works?

Thre are several examples which have RTT logging enabled by default. ble_app_uart is one of them (located in \nRF5_SDK_16.0.0_98a08e2\examples\ble_peripheral\ble_app_uart\pca10056\s140). Note: remember to load the Softdevice since it's a BLE app: make flash_softdevice && make flash

Vidar

Edit: RTTViewer is not available for Linux MacOS if I recall correctly. So if you are not working in Windows, try to first connect the debugger with Jlink commander (JLinkExe) first, then run the RTTClient executable from another terminal window.