SEGGER RTT (Real-time-transfer)?

[Liviu Ionescu]

[SEGGER RTT](https://www.segger.com/products/debug-probes/j-link/technology/real-time-transfer/about-real-time-transfer/)

Although a proprietary solution, this is very, very fast, and I'd love to have something similar available for RISC-V too.

I know of two different usages for this RTT mechanism:

- an independent debug trace channel, like semihosting or SWO, but at least an order of magnitude faster.
- a real time tracing mechanism, used by System View (https://www.segger.com/products/development-tools/systemview/)

For those who do not know how RTT works (if Alex from SEGGER is reading these messages, please correct me if I'm wrong), RTT is a software-only solution from the application point of view.

Instead of having the traced application forward the (fast) data stream to a physical device (like UART, ARM SWO, qSPI, I2C, etc), there is a local driver that writes the debug/trace stream to a local RAM circular buffer, and, in background for the application, the J-Link reads this buffer via JTAG and the debugger makes use of it in real-time, without any interaction with the running application, totally transparently.

Is this even possible with the current RISC-V debug specs?


Regards,

Liviu

[kr...@berkeley.edu]

The debug spec allows for an optional bus master port on the debug
module to read/write system memory without interrupting the CPU - I
think that's the primary feature required to implement RTT.

Krste

| --
| You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
| To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
| To post to this group, send email to de...@groups.riscv.org.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/4E49DF06-4D95-42CF-A677-C7400968F5BC%40livius.net.

[Liviu Ionescu]

> On 1 Jan 2018, at 19:40, kr...@berkeley.edu wrote:
>
>
> The debug spec allows for an optional bus master port on the debug
> module to read/write system memory without interrupting the CPU - I
> think that's the primary feature required to implement RTT.

"optional" probably means it is not available in none of the existing implementations, right?

on ARM, RTT works even on the small Cortex-M devices.


regards,

Liviu

[SEGGER - Alex Gruener]

Hi Liviu,

Krste is right. The RISC-V debug spec specifies something similar to ARMs "AHB-AP"
that allows direct access to the memory without interrupting the CPU.
However, it is optional and I have not seen it being implemented so far. (Maybe it is implemented on some RISC-V implementations we did not have on our desks so far)
It is like on Cortex-A/R cores: Vendor specific availability. Cortex-M is luckily *always* equipped with an AHB-AP so it always allows to use RTT.

This "direct memory access" feature would be required to allow RTT being used.

AFAIK, for RISC-V there are 2 levels of "direct" support:
1) AHB-AP like that allows next to no CPU disturbance
2) Ultra-short CPU stall/halt that allows the debugger to place some instructions to be executed in a buffer and then trigger the execution of them, which temporarily switches the CPU to debug mode, executes the instructions and switches back to normal execution mode (like an interrupt + interrupt handler)

However, 1 & 2 are both optional and have not been seen as being implemented so far :(

  Alex Grüner
  Product Manager
  alex.g...@segger.com
  T +49-2103-2878-0
  www.segger.com

SEGGER Microcontroller GmbH & Co. KG  *  In den Weiden 11  *  40721 Hilden  *  Germany  *  Tel. +49-2103-2878-0  *  Fax. +49-2103-2878-28
Amtsgericht Düsseldorf, HRA-Nr.: 19694  *  Komplementärin: SEGGER Verwaltungs GmbH, HRB-Nr.:57453  *  Geschäftsführer: Ivo Geilenbruegge

[Liviu Ionescu]

> On 2 Jan 2018, at 10:06, SEGGER - Alex Gruener <alex.g...@segger.com> wrote:
>
> ... However, 1 & 2 are both optional and have not been seen as being implemented so far :(

What a pity...

It might be a detail, but it is the sum of such small details that defines the user experience, and for the bare-metal world, the RISC-V does not stand very well when compared with the Cortex-M... :-(

Actually I think that the desire to keep the RISC-V specs unique and to impose to the bare-metal devices the same criteria from the Unix devices is not beneficial, there are too many differences between them to justify two different 'profiles', with two different specs.

And in the 'embedded' profile, the direct memory access should not be optional.


I think that SEGGER should try to promote this approach.


Regards,

Liviu

[SEGGER - Alex Gruener]

Hi all,

We plan to have an RTT implementation available for RISC-V that is 2)
emulated by J-Link firmware, if the target does not support it natively.

2) Ultra-short CPU stall/halt that allows the debugger to place some instructions to be executed in a buffer
and then trigger the execution of them, which temporarily switches the CPU to debug mode,
executes the instructions and switches back to normal execution mode (like an interrupt + interrupt handler)

Because these actions are performed *inside* the J-Link FW if the target
does not provide an instruction buffer, the intrusiveness is not too bad.
This makes RTT available on *all* RISC-V implementations and the intrusiveness is still very low
so that it will work for most customers and most applications / setups.

Plan to be available at end of February.

  Alex Grüner
  Product Manager
  alex.g...@segger.com
  T +49-2103-2878-0
  www.segger.com

SEGGER Microcontroller GmbH & Co. KG  *  In den Weiden 11  *  40721 Hilden  *  Germany  *  Tel. +49-2103-2878-0  *  Fax. +49-2103-2878-28
Amtsgericht Düsseldorf, HRA-Nr.: 19694  *  Komplementärin: SEGGER Verwaltungs GmbH, HRB-Nr.:57453  *  Geschäftsführer: Ivo Geilenbruegge