"Don't have the number of threads in FreeRTOS" and does not stop on `main` (OCD-1311)

[iampi31415]

• Development Kit: esp32c6-devkit
• Module or chip used: esp32c6-wroom-1
• Debug Adapter: jtag
• OpenOCD version: Open On-Chip Debugger v0.12.0-esp32-20250707
• Operating System: MacOS
• Using an IDE ? No
• OpenOCD command line: openocd -f board/esp32c6-builtin.cfg
• JTAG Clock Speed: default
• ESP-IDF version: Does not apply.

Problem Description

I'm flashing this program:

#![no_std]
#![no_main]

// ....

#[main]
fn main() -> ! {
    let config = esp_hal::Config::default().with_cpu_clock(CpuClock::_80MHz);
    let _peripherals = esp_hal::init(config);

    let delay = Delay::new();
    let mut a = 5;
    loop {
        a += 1;
        println!("hi");
        delay.delay_millis(1500);
        println!("{a}");
    }

}

with .gdbinit:

target extended-remote localhost:3333
b main
layout src

and openocd.cfg:

gdb breakpoint_override hard
source [find board/esp32c6-builtin.cfg]

It connects and after c I get:

Don't have the number of threads in FreeRTOS!

[sobuch]

Hi @iampi31415 could you try adding set ESP_RTOS hwthread line to your openocd.cfg file (before the line with "source")?

As far as I understand you are not using FreeRTOS, so OpenOCD should be configured accordingly.

[iampi31415]

I am not, no (It's included in OP.) Now it does not error, still does not stop in main. My new openocd.cfg

debug_level 2
log_output ./openocd.log
gdb breakpoint_override hard
set ESP_RTOS hwthread
source [find board/esp32c6-builtin.cfg]

[iampi31415]

If I add a new breakpoint with: break main.rs:19 where there is the variable a it does stop, and does show the source as expected.

But otherwise it would halt in the loop I guess.

But I just find odd it never stops in main. Seems there is something wrong with that (I don't even see the B+ there, so I guess it is named something else?)

[sobuch]

Hm, I dont see any reset in the gdbinit, could it be just that the breakpoint in main was already passed before gdb connects?

Maybe something like

target extended-remote localhost:3333
mon reset halt
b main
layout src
c

[iampi31415]

I'd tried with a few combinations, all the same from what I can tell:

#set remotetimeout 10
# default port opened by open ocd.
target extended-remote localhost:3333
monitor reset halt
#maintenance flush register-cache
b main
layout src
c

The result is what I showed in the last screenshot.

I created a public test repository: https://github.com/iampi31415/test-gdb-esp32c6

[iampi31415]

I've found br gdb_hello_world::__risc_v_rt__main does work.

Should using just br main work though?

[JurajSadel]

Hi @iampi31415, using GDB with Rust has always been rough and will likely stay that way unless Rust language support improves upstream. You could try the rust-gdb wrapper, which might give you a bit more luck. Another option is probe-rs, though it has its own issues as well.

[iampi31415]

@JurajSadel

You could try the rust-gdb wrapper

Indeed, br main does work with gdb-rust.

Another option is probe-rs, though it has its own issues as well.

probe-rs seems to me a akin to openocd since probe-rs still needs us to connect with gdb. To be frank, I found openocd more reliable.

The issue that gdb-rust fixes though, does not seem to happen in all boards, for example they don't have it in this tutorial for STMDISCOVERY or they would mention it.