Segger RTT support

[peter9477]

Is there any support for Segger's RTT protocol in PyOCD?

If not, I may be in a position to add something, but I don't want to reinvent the wheel if someone else has already been working on this, or waste my time if there's some reason this isn't feasible in PyOCD. (I've only just installed it, and it's working fine for me talking to an nRF52832 device connected via PicoProbe. The only thing that stops me immediately switching over from openocd is the apparent lack of RTT support, which is crucial to our development flow.)

[flit]

Funny you should ask! 😄 RTT support was just added in #1234 by @mikisama.

This is a very basic implementation, and is only integrated as a command line subcommand (pyocd rtt). There are a lot of features to add:

• Refactor into a reusable component so it can be used from the Python API.
• Automatic enabling while gdbserver is running. (You can use the probeserver to simulate this now.)
• J-Link RTT command support for improved performance. Right now it's generic so it works with all probes, which is nice, but will probably disappoint J-Link users.
• Multiple channels.
• Raw data.
• TCP server.

[peter9477]

I can confirm it works, at least for output from the device. A good start. Thank you @mikisama!

(I will need to add input through the channel as well, since our debug interface is interactive, with a couple dozen single keystroke commands to trigger various behaviours.)

[peter9477]

For others who may follow:

Initially I was having trouble because connecting via pyocd rtt would result in my target hitting an exception handler. I believe this occurs when the process is halted and then resumed. The rtt_cmd.py code has a target.resume() after it finds the RTT control block, and after experimentally adding a if target.is_halted() ahead of that (which I don't think helped and may be redundant, if resume already checks for that), I was led to the -M option supported by some commands, which allowed me to specify -M attach instead of the default (whatever it is), and this allowed me to connect to a running target without interruption, and see the RTT output from the past while and new stuff as it arrives. Perfect.

(The reason my target throws an error when halted and resumed may be related to the fact we're running FreeRTOS with a bunch of threads, and I believe the clocks are configured to keep running when halted. This likely throws off the FreeRTOS scheduler in some way when we resume. I don't think it's related to the RTT stuff at all.)

Another issue I have seen is that exiting (via Ctrl-C, as I don't know of a cleaner way) often results in the probe subsequently being unavailable (e.g. pyocd.core.exceptions.ProbeError: Bad parity in SWD read). Using usbreset Picoprobe (/usr/bin/usbreset is in package usbutils on Debian) cleared that up and I could connect again.

[flit]

Fyi: thanks to @ccattuto, #1253 adds host to target support.

[purpl3F0x]

Hello is RTT suppose to work ? I'm using zephyr and trying to log to RTT but i don't see any output

[letshin]

I am getting a similar error, I think. Using the latest development branch (0.34.3.dev18)

[flit]

@purpl3F0x @letshin Thanks for reporting this. I've created a new ticket #1471 to track your issue, so please see the questions there. (And will be closing this one, since, theoretically at least, RTT support is present now.)