[Rust] Cannot open RTT channel with micro:bit v2.20 board

[romancardenas]

I'm trying to setup a embedded Rust development environment with VS Code. I'm using the following tools:

• MacOS
• A micro:bit board (v2.20)
• OpenOCD (v0.11.0+dev-00698-gcc8b49185)
• Cortex-Debug (v1.4.4)
• For RTT, I'm using the rtt-target crate (v0.3.1)

The project is available in this repository.
My launch configuration is the following:

{
    "version": "0.2.0",
    "showDevDebugOutput": true,
    "configurations": [
        {
            "name": "Debug (Blinky)",
            "type": "cortex-debug",
            "preLaunchTask": "build",
            "request": "launch",
            "servertype": "openocd",
            "interface": "swd",
            "cwd": "${workspaceRoot}",
            "executable": "${workspaceRoot}/target/thumbv7em-none-eabihf/debug/blink-led",
            "device": "nrf52833_01AA",
            "svdFile": "${workspaceRoot}/nrf52833.svd",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/nrf52.cfg"
            ],
            "rttConfig": {
                "enabled": true,
                "address": "auto",
                "clearSearch": false,
                "decoders": [
                    {
                        "port": 0,
                        "type": "console"
                    }
                ]
            },
            "runToEntryPoint": "main",
        },
    ]
}

The debugging works great. I can set break points and analyze all the variables etc. However, it is not able to open the RTT communication for logging. The output of the gdb server is the following:

Open On-Chip Debugger 0.11.0+dev-00698-gcc8b49185 (2022-06-03-14:19)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : Listening on port 50004 for tcl connections
Info : Listening on port 50005 for telnet connections
Info : Using CMSIS-DAPv2 interface with VID:PID=0x0d28:0x0204, serial=99053602000528336a7989d907e3befb000000006e052820
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.1.0
Info : CMSIS-DAP: Serial# = 99053602000528336a7989d907e3befb000000006e052820
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : [nrf52.cpu] Cortex-M4 r0p1 processor detected
Info : [nrf52.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 50003
Info : Listening on port 50003 for gdb connections
Info : accepting 'gdb' connection on tcp/50003
Info : nRF52833-xxAA(build code: A0) 512kB Flash, 128kB RAM
undefined debug reason 8 - target needs reset
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000100 msp: 0x20004000
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000100 msp: 0x20004000
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000100 msp: 0x20004000
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000100 msp: 0x20004000
Info : Listening on port 60000 for rtt connections
Info : rtt: Searching for control block 'SEGGER RTT'
Info : rtt: No control block found
Info : accepting 'rtt' connection on tcp/60000

In the last 4 lines, it seems that OpenOCD is not able to open the RTT channel. Does anyone know what I'm missing?

[romancardenas]

By the way, I forgot to say that I am able to see the RTT logs using cargo-embed.

[haneefdm]

The trouble is that with OpenOCD, it only tries to look for the control block once and never tries again. I have a version that will keep trying but it is not in the public release and I don't think the OpenOCD folks will accept the fix. JLink on the other hand does not have this problem because it keeps looking for RTT being initialized. This is documented in our WiKi

Info : rtt: Searching for control block 'SEGGER RTT'
Info : rtt: No control block found

Question. In your FW, in the RTT struct, there is an ID string. Is it set to 'SEGGER RTT' (default) or some other string?

In your FW, set a breakpoint right after the RTT is initialized. The in the Debug Console, do the following

monitor rtt start

Please let me know if this works. We will try to see if there is some way to automate it.

By the way, I forgot to say that I am able to see the RTT logs using cargo-embed.

Could you expand on this? I mean you can always open an TCP connection using something line netcat/nc on port 6000 and you should see stuff come out.

[romancardenas]

Question. In your FW, in the RTT struct, there is an ID string. Is it set to 'SEGGER RTT' (default) or some other string?

I'm not 100% sure, but I think it uses the default value. In rtt-target crate, for the RttHeader struct, the init function is defined as follows (source):

pub unsafe fn init(&mut self, max_up_channels: usize, max_down_channels: usize) {
        ptr::write_volatile(&mut self.max_up_channels, max_up_channels);
        ptr::write_volatile(&mut self.max_down_channels, max_down_channels);

        // Copy the ID in two parts to avoid having the ID string in memory in full. The ID is
        // copied last to make it less likely an unfinished control block is detected by the host.

        ptr::copy_nonoverlapping(b"SEGG_" as *const u8, self.id.as_mut_ptr(), 5);

        fence(SeqCst);

        ptr::copy_nonoverlapping(
            b"ER RTT\0\0\0\0\0\0" as *const u8,
            self.id.as_mut_ptr().offset(4),
            12,
        );
    }

I did as you requested: I added a breakpoint just after executing rtt_init_print!(). In the Debug Console, after executing monitor rtt start, I got the following output:

rtt: Searching for control block 'SEGGER RTT'
rtt: Control block found at 0x20000000

As you said, now OpenOCD finds the RTT control block, and the RTT monitor terminal outputs my messages. I guess that, today's date, the only thing I can do to get the logs is using this workaround, don't I?
I'll try to install a JLink driver to my board and see if JLink does not behave this way.

[haneefdm]

I will see if I can automate that for OpenOCD. It will be ugly. With JLink, you will have zero issues. It is their idea after all.

Glad to see some Rust code in action

[romancardenas]

Thank you very much! I'll close this issue, as it is already solved.