ChibiOS Free Embedded RTOS

I'll have a better look later. However it's worth pointing out that in my case, using identical code, reading the trace works with ChibiStudio21, and not with ChibiStudio_2020. And the other tabs on the Chibi plugin work as expected.
(I did also have a problem if the thread name contained the '&' character)

Giovanni wrote:StkUnused == 0 means a likely stack overflow.

You should have some filler left in each stack.

Giovanni

I do have a filler - 280 bytes still at 0x55.

In fact it seems to be a conversion error, I tried 6k and it showed zero, 8k showed 8192 and 9k also showed 8192.

Mike

mikeprotts wrote:When using a demo, I can refresh on the TraceBuffer fine, and still works fine if I turn off tickless mode.

When I use my code, the refresh takes a long time, then pops up an error message. The popup title bar is:
ChibiOS/RT Views

The error message is:
Error:error reading memory at 134401324

That address is 0x0802cd2c which I can find in the listing as posted earlier. So there's a difference between the demo and my code that's triggering this issue.

I also notice that in the threads view, my TCPIP thread shows StkUnused as zero, I suspect because it's allocated at too high a memory address (Address 0x2407FF48, StkLimit 0x2407FB78, Stack 0x2407FDFC, StkUnused 0) as the other threads report a sensible value. I don't know if that calculation is from ChibiOS or ChibiStudio.

Mike

Just revisited the project that prompted my original post, and Mike's post above mirrors my problem.
I've updated various things, so should be running everything current:
Nucleo F767.
Chibistudio 2020-04 with Chibi plugin 4.2.0.202102201557
Chibi 20.3.3
Statistics enabled.
OpenOCD
Initially Rocco's compilation: Open On-Chip Debugger 0.10.0+dev-00226-g1c2e3d41d (2017-12-23-10:15)
Then Version 0.11 (released a few days ago)
GCC
Initially 9.3.1
Then 10.2.1


In most cases pProgram is halted in an ISR - at the beginning of OSAL_IRQ_PROLOGUE(), in my OSAL_IRQ_HOOK() routine, but same problem if randomly paus program (usually in the idle loop).

Two problems (as described by Mike):
a) Most features of the Chibi plugin retrieve and display data OK (which suggests that there is no fundamental problem in reading memory locations on the target). However attempting to download the trace buffer results in an error message (after a delay of about 10-30 seconds):

"Error: error reading memory at xxxxxxx."

where address xxxxxx holds the pointer to the name of the ISR where the breakpoint occurred.

OpenOCD doesn't flag up an error.

The Eclipse log has entries of the form:

!ENTRY org.eclipse.cdt.dsf 4 10005 2021-03-10 10:25:37.286
!MESSAGE Request for monitor: 'RequestMonitor (org.eclipse.cdt.dsf.debug.ui.actions.DsfSuspendCommand$4$1@7364e379): Status ERROR: org.eclipse.cdt.dsf.gdb code=10004 Interrupt failed. null' resulted in an error.
!SUBENTRY 1 org.eclipse.cdt.dsf.gdb 4 10004 2021-03-10 10:25:37.286
!MESSAGE Interrupt failed.


b) Zero free stack report for TCP/IP thread.
I investigated this further:
1. Note that I was not seeing program malfunctions, despite the zero free stack report.
2. I've got my own "report free stack" routine which was reporting something like 450 of 2000 bytes free. (It's not as accurate as the Chibi routine, because it uses binary search for speed, but pretty close).
3. I progressively increased the stack size from 2000 to 5000; zero free stack was reported until stack size 5000, when values of 3500-4500 got reported - so the extra 3000 byte assignment isn't necessary!

Any thoughts?

Is the pointer xxxxxxx a valid address when this happens? perhaps the plugin is trying to fetch data from an invalid address.

Giovanni

Giovanni wrote:Is the pointer xxxxxxx a valid address when this happens? perhaps the plugin is trying to fetch data from an invalid address.

Giovanni

Yes, valid address. It's the address of the function name which was active when my breakpoint was hit - usually an ISR.

[Side note: The code listing doesn't list all the string constants and such like - looked them up in the binary. Didn't find a gcc option to add the constants to the listing on a quick look]

Just my observation to add into discussion. I too see stkunused = 0 for my lwip(1k stack) and shell(1k stack) thread in Debug 6.x.x plugin.
I did some testing:
1. When I increase lwip stack from 1k to 20k, I see lwip stkunused 16k. Shell stkunused ~800. Then I count by function other then 0x55 bytes from "stklimit" to "stack" address for lwip, I get only ~540 used, rest is 0x55. I did verify roughly by examining memory browser.

2. When I increase lwip stack from 1k to 8k, I see stkunused ~7300. Shell thread stkunused ~730. I again count by function other then 0x55 bytes from "stklimit" to "stack" address for lwip, I get only ~600 used, rest is 0x55.

3. When I increase lwip stack from 1k to 4k, I see stkunused = 0. Shell thread stkunused ~730. I again count by function other then 0x55 bytes from "stklimit" to "stack" address for lwip, I get only ~600 used, rest is 0x55.

4. Back to original lwip stack = 1k, I see stkunused = 0. Shell thread stkunused ~0. I again count by function other then 0x55 bytes from "stklimit" to "stack" address for lwip, I get only ~400 used, rest is 0x55. And for shell I count ~100 used, rest is 0x55.

Here is list of my threads function at 1k stack for lwip:

Just to say, all works fine even when I keep my lwip stack at 1k. But I keep wonder whether I do something wrong.

Moving this in "bug reports".

Giovanni

To correct my self, I spoke about tcpip thread not lwip thread. But the idea is the same.

bumping as self-reminder