SES debugging session with pynrfjprog RTT issue

[JediVille]

I am working on a project that is implementing the segger_rtt framework.
It's based on an NRF52840, it's running FreeRTOS and we're using Segger Embedded Studio (SES).
Using SWD interface through a Segger Flasher.

I have both custom hardware and the PCA10056 NRF DK.
I get same behaviour on both.

I am using pynrfjprog to run some tests externally through the Segger Flasher.
Ideally I would like to do this while debugging using SES.

We are using NRF_LOG to output log information to the debug terminal window in SES.
The script works, however after the end of the script there is no longer a proper connection between the hardware and SES.
No more debug output in the debug terminal window.
But the software is still running ( I am toggling an LED in a task every 1 second-ish ).
And the test script can be executed again with proper connection into the software and any debug output that has been buffered meanwhile will get output ( until buffers are full ).
If I break the software all registers show 0xdeadbeef, and the LED contiues to blink.

Shouldn't it be possible to have two simultaneous connections one through pynrfjprog and one through SES to the same hardware ( here a Segger Flasher ) ?

Below is a copy of the JLINK log that shows JLINK_IsHalted() begins to return ERROR.
This should be around the time where the script is completed.

T3EB4 053:108.064 JLINK_RTTERMINAL_Read(BufferIndex = 0, BufferSize = 0x00008000)
T3EB4 053:108.088 - 0.033ms returns 0
T3EB4 053:108.200 JLINK_IsHalted()
T3EB4 053:109.644 - 1.466ms returns FALSE
T2640 053:111.752     JLINK_RTTERMINAL_Control(Cmd = JLINKARM_RTTERMINAL_CMD_STOP)
T2640 053:112.632       CPU_WriteMem(4 bytes @ 0x20018E30)
T2640 053:113.380     - 1.640ms returns 0x00
T3EB4 053:113.536 JLINK_RTTERMINAL_Read(BufferIndex = 0, BufferSize = 0x00008000)
T3EB4 053:113.560 - 0.028ms returns 0
T3EB4 053:113.636 JLINK_IsHalted()
T3EB4 053:114.388 - 0.766ms returns FALSE
T3EB4 053:121.232 JLINK_RTTERMINAL_Read(BufferIndex = 0, BufferSize = 0x00008000)
T3EB4 053:121.256 - 0.027ms returns 0
T3EB4 053:121.328 JLINK_IsHalted()
T3EB4 053:122.384 - 1.073ms returns ERROR


It doesn't matter how I end the script, if I call any of the below functions or not it is the same behaviour.
disconnect_from_device(), disconnect_from_emu(), rtt_stop(), close()


I also have another issue that I am having trouble wrapping my head around..
The task that is handling segger communications calls
SEGGER_RTT_Read
in a while(1) loop and if anything has been received it gets processed.

But if I insert a vTaskDelay(0) in case nothing has been read then RTT communication stops working.
rtt_write completes in the script writing the required number of bytes.
But in the device the SEGGER_RTT_Read function never reads anything.

[Vidar Berg]

Hello,

You may run into some conflicts when you have two or more debugger connections to the same target. For instance, the debugger scripts will usually disable the debug interface on the chip before they disconnect to prevent the chip from staying in debug interface mode. This means you are likely to lose both connections if you terminate one.

Below is a copy of the JLINK log that shows JLINK_IsHalted() begins to return ERROR.
This should be around the time where the script is completed.

 The nRF52840 is probably no longer in debug interface mode at this point

I also have another issue that I am having trouble wrapping my head around..
The task that is handling segger communications calls
SEGGER_RTT_Read
in a while(1) loop and if anything has been received it gets processed.

 Are you also the NRF logger module with the RTT backend?

Best regards,

Vidar

[JediVille]

Thank you for your reply.

That is probably what is happening, Something in the Nordic DLLs probably disables the debug interface when an object gets destroyed.

I can live with the behaviour - I just got curious and wanted to understand what was happening and see if there was a way around it.

For the other question I am not sure what you mean.

I am using the NRF logger and the RTT backend.

The NRF logger and the RTT backend are running on separate channels.

In the device the function SEGGER_RTT_Read is called in a while(1) loop ( a FreeRTOS task ).
If anything is read it gets processed - and NRF logger may be used depending on the content.
However I felt like trying to insert a vTaskDelay in case nothing is read and that resulted in SEGGER_RTT_Read never returning anything read - even if the PC running the script claims to have delivered data usign the rtt_write function in pynrfjprog.
I haven't digged further into it - it is debug and test code and it is not important to add a task delay really. I was just curious.

Thanks again,
//Jesper

As a curiosum I can mention that I wanted to try out the Telnet connection according to this:
https://wiki.segger.com/RTT#TELNET_channel_of_J-Link_software
I couldn't succeed in sending the configuration command within 100ms of connecting using any telnet application I could find ( PuTTY, MobaXterm and plenty of others ) - except for one, Telnet Scripting Tool 1.0.
I even asked on the Segger forums how to achieve this since they even mention PuTTY but have yet to receive an answer.

I could write my own client if I wanted to go through that interface - and even create a DLL I could use with test scripts.
And that should leave the debug interface untouched.
But seeing as there really isn't a need I will leave it at that.

[Vidar Berg]

Sorry, my question was not clear. I meant to ask if you were enabling RTT in the logger module in addition to the direct Segger RTT API calls you mentioned, but I realize now that this had already been answered in your initial post. The question was not as relevant either considering the problem occured after adding vTaskDelay(0). I thought maybe there was an issue with both multiple accesses to the log buffer at first.

Anyway. I'm afraid I can't think of any good reasons for why vTaskDelay(0) causes RTT data to not become read in this case.  Did you debug the code to confirm if SEGGER_RTT_Read() kept getting called after vTaskDelay(0)?

[JediVille]

Thanks for your reply!

I did debug the code to ensure that SEGGER_RTT_Read() kept getting called.

The PC side using pynrfjprog claims that the data has been delivered.
But on the device side the function SEGGER_RTT_Read() is called again and again and never returning any data.

As mentioned - I have moved on to other tasks.

Thanks again for your suggestions!

//Jesper