ChibiOS/RT 7.x.x Debug View error message in TraceBuffer tab

[wolf]

Linux Mint 22.3 - Cinnamon 64-bit

ChibiStudio_Linux_2023_02.7z actual version as of 2026-03-19 freshly downloaded and installed

Demo: RT-STM32F303-DISCOVERY running on a genuine ST board

chconf.h settings: ALL debug switches set TRUE

Everything else unchanged

Hi all,

when i run and debug the demo with a.m. settings and halt it in order to inspect it with ChibiOS/RT 7.x.x Debug View, everything seems to work fine - apart from : TraceBuffer (after refreshing the view of course).

I get attached error message.

Am i missing something out?

Best rgards, Wolf

[Giovanni]

Hi,

Which RT version are you using?

Giovanni

[wolf]

Hello Giovanni,

it is the RT version included in the freshly downloaded: ChibiStudio_Linux_2023-02.7z (881.6MB) as of today.

In there i used:
chibios_stable-21.11.x

chibios_stable-21.11.x/os/rt/include/ch.h says:
#define CH_KERNEL_VERSION "7.0.4"

BTW: I set this in chconf.h too:
#define CH_DBG_TRACE_MASK CH_DBG_TRACE_MASK_ALL

Best regards, Wolf

[wolf]

Hello Giovanni!

I dug a bit further into this and made a strange observation:

I enabled #define CH_DBG_TRACE_MASK CH_DBG_TRACE_MASK_READY in chconf.h.

Then i put a breakpoint at the end of void __trace_ready(thread_t *tp, msg_t msg) { in chtrace.c.

I got a valid output in the TraceBuffer view, no error message.

Then i made this breakpoint a counting one and increased the ignore count step by step.

It works fine until I increase the ignore count to 20. After this i get an error as described before. This is consitent.
I changed the value many times between 19 and 20. With 19 it works, with 20 it failes - consitently.

Maybe this might help to detect the cause? Maybe a buffer overflow in the plugin? Or a problem in GDB/openOCD? Very strange.

BTW: the output of the test in the demo program shows:

Code: Select all

--- Test Case 1.2 (Kernel Info)
--- Product:                            ChibiOS/RT
--- Stable Flag:                        1
--- Version String:                     7.0.5
--- Major Number:                       7
--- Minor Number:                       0
--- Patch Number:                       5
--- Result: SUCCESS

Best regards, Wolf

[Giovanni]

What is the configured size of the trace buffer?

I just noticed that it is a debugger timeout, what is the value of the pointer stored at that location? perhaps it is invalid and causes an error on fetch.

Giovanni

[wolf]

Hello Giovanni.

The trace buffer is sized 128 (default):

Code: Select all

#define CH_DBG_TRACE_BUFFER_SIZE            128

in chconf.h

The address its trying to fetch is located in the ch0.trace_buffer.buffer starting at 0x20000a28 (ch0+144).

For example it tires to fetch from 536875240d = 0x200010E8, which is offset by 0x6C0 from the buffer base.

I tried different setting for

Code: Select all

CH_DBG_TRACE_BUFFER_SIZE

I found that it works OK up to a setting of

Code: Select all

#define CH_DBG_TRACE_BUFFER_SIZE            91

Trying

Code: Select all

#define CH_DBG_TRACE_BUFFER_SIZE            92

it fails consitently.

Very strange, I'd rather expect a power of two to be the limit and maybe give a hint to what happens.

BTW, I updated the ST-Link on the STM32F303-Discovery to the latest version using the STM32CubeProgrammer.

Can you reproduce the behavior?

Best regrads Wolf

[Giovanni]

Hi,

The "expert" found a problem with the debugger plugin, it could be causing the problem you are seeing, I will upload a new one "soon", setting up testing will take some time because I have to re-create the env on my new PC.

The functional fix is in the trace-buffer scanner: before the first ring wrap,
ptr is the next free slot, not the oldest valid record, so the plugin was
walking unused entries and could end up decoding garbage. It now detects the
pre-wrap case by checking the slot at ptr; if that slot is
CH_TRACE_TYPE_UNUSED, it scans only [buffer[0], ptr). After wrap, it still
scans from ptr as the oldest record. I also fixed the unrelated but real 0x...
parse bug where hex strings were being parsed with radix 20 instead of 16.

Verification was limited to reviewing the svn diff. I did not build or load
the Eclipse plugin here. Also worth tracking for the later full review: the
same radix bug still exists in the RT3/RT4/RT6 plugin variants.

Once uploaded you will need to update it in ChibiStudio.

Giovanni

[Giovanni]

Good news, I unleashed the power of Codex-CLI and Claude Code (yes, both of them...) on the problem and they fixed the plugin. Now it fetches the whole buffer in a single read and it is much faster than before. The error was probably caused by some quirk of the Eclipse debugger in evaluating expressions, now it is done in Java code directly.

Will upload the plugin tomorrow after some extra testing, the code is committed already.

Giovanni

[Giovanni]

I uploaded as-is, you may try to update, make a copy of the eclipse folder first just in case.

Giovanni

[wolf]

Hi all!

I just updated the ChibiOs extensions via the eclipse update feature.

A quick test with the initial setting of 128 entries in the trace buffer worked flawless.

Great job and great news getting a useful feature up and running, quite a bit faster too!

I'll do some more in depth testing and report if anything stange comes up.

Many thanks for your effort, Wolf