Struct probe_rs_rtt::Rtt

pub struct Rtt { /* private fields */ }

The RTT interface.

Use Rtt::attach or Rtt::attach_region to attach to a probe-rs Core and detect the channels, as they were configured on the target. The timing of when this is called is really important, or else unexpected results can be expected.

Examples of how timing between host and target effects the results

1. Scenario: Ideal configuration The host RTT interface is created AFTER the target program has successfully executing the RTT initialization, by calling an api such as rtt:target::rtt_init_print!()

   • At this point, both the RTT Control Block and the RTT Channel configurations are present in the target memory, and this RTT interface can be expected to work as expected.

2. Scenario: Failure to detect RTT Control Block The target has been configured correctly, BUT the host creates this interface BEFORE the target program has initalized RTT.

   • This most commonly occurs when the target halts processing before intializing RTT. For example, this could happen …
     • During debugging, if the user sets a breakpoint in the code before the RTT initalization.
     • After flashing, if the user has configured probe-rs to reset_after_flashing AND halt_after_reset. On most targets, this will result in the target halting with reason Exception and will delay the subsequent RTT intialization.
     • If RTT initialization on the target is delayed because of time consuming processing or excessive interrupt handling. This can usually be prevented by moving the RTT intialization code to the very beginning of the target program logic.
   • The result of such a timing issue is that probe-rs will fail to intialize RTT with an [probe-rs-rtt::Error::ControlBlockNotFound]

3. Scenario: Incorrect Channel names and incorrect Channel buffer sizes This scenario usually occurs when two conditions co-incide. Firstly, the same timing mismatch as described in point #2 above, and secondly, the target memory has NOT been cleared since a previous version of the binary program has been flashed to the target.

   • What happens here is that the RTT Control Block is validated by reading a previously initialized RTT ID from the target memory. The next step in the logic is then to read the Channel configuration from the RTT Control block which is usually contains unreliable data at this point. The symptomps will appear as:
     • RTT Channel names are incorrect and/or contain unprintable characters.
     • RTT Channel names are correct, but no data, or corrupted data, will be reported from RTT, because the buffer sizes are incorrect.

Implementations

impl Rtt

pub fn attach(
    core: &mut Core<'_>,
    memory_map: &[MemoryRegion]
) -> Result<Rtt, Error>

Attempts to detect an RTT control block anywhere in the target RAM and returns an instance if a valid control block was found.

core can be e.g. an owned Core or a shared Rc<Core>.

pub fn attach_region(
    core: &mut Core<'_>,
    memory_map: &[MemoryRegion],
    region: &ScanRegion
) -> Result<Rtt, Error>

Attempts to detect an RTT control block in the specified RAM region(s) and returns an instance if a valid control block was found.

core can be e.g. an owned Core or a shared Rc<Core>.

pub fn ptr(&self) -> u32

Returns the memory address of the control block in target memory.

pub fn up_channels(&mut self) -> &mut Channels<UpChannel>

Gets the detected up channels.

pub fn down_channels(&mut self) -> &mut Channels<DownChannel>

Gets the detected down channels.

Trait Implementations

impl Debug for Rtt

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.