NRF LOG + JLINKRTTClientExe

[BEplane]

Hello,

NRF52840

SDK 15.3.0

SoftDevice: s140

OS: Ubuntu

IDE: SES

I am having difficulty getting consistency out of the RTT + NRF_LOG_INFO() print statement. It has printed what I expected in a timely manner before, but also has not responded moments later. Can you confirm the limitations of using the RTT + NRF_LOG_INFO(), and If I am unintentionally breaking it.

I have been connecting the JLinkExe, and the JLinkRTTExe in the terminal, then from there I go about loading software in SES, and debugging, adding breakpoints, loading changes. All without touching, or renewing the JLinkExe or JLinkRTTExe. Is this the expected workflow for using the RTT and NRF_LOG_INFO()? Or should the RTT be reconnected everytime I load new code?

I will say I am able to get the RTT to respond as expected some times, but other times it is either sluggish to print, or does not print at all. I am simply pressing a switch, and printing out, pressed or released.

Does the RTT use any peripherals or support that I may also be using elsewhere?

JLinkExe Setup

SEGGER J-Link Commander V6.52 (Compiled Sep 27 2019 17:53:46)
DLL version V6.52, compiled Sep 27 2019 17:53:31

Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jan  7 2019 14:07:15
Hardware version: V1.00
S/N: 683177789
VTref=3.300V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: NRF52840_XXAA
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "NRF52840_XXAA" selected.


Connecting to target via SWD
InitTarget() start
InitTarget() end
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>

JLinkRTTClient

SEGGER J-Link V6.52 - Real time terminal output
J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 7 2019 14:07:15 V1.0, SN=683177789
Process: JLinkExe

[bjorn-spockeli]

Hi Paul

I have been connecting the JLinkExe, and the JLinkRTTExe in the terminal, then from there I go about loading software in SES, and debugging, adding breakpoints, loading changes. All without touching, or renewing the JLinkExe or JLinkRTTExe. Is this the expected workflow for using the RTT and NRF_LOG_INFO()? Or should the RTT be reconnected everytime I load new code?

RTT uses a control block that is located in RAM on the target device, see this page for more information. Everytime you re-compile your code and flash it to the target, you are most likely also shifting the location of this control block. If this happens you will have to reconnect with Jlink. You can also place the control block at a static location in RAM so that the control block is at the same location all the time. 

Best regards

Bjørn

[BEplane]

That makes sense to the problem I was seeing. 

How would I go about making the module static? My initial guess is to change the RTT files to be static, or at leat the buffers. I am unsure of exactly what I would need to change for the module to be static and work through different uploads.

Thank you,

[bjorn-spockeli]

Hi Paul, 

there are some users that have placed the Segger Control Block at a specific RAM address when they wanted to get RTT output from both the bootloader and application, see https://devzone.nordicsemi.com/f/nordic-q-a/20708/rtt-logging-from-application-started-by-bootloader/80812#80812

Best regards

Bjørn