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)
ChibiStudio 2020
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: ChibiStudio 2020
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
Re: ChibiStudio 2020
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?
- Giovanni
- Site Admin
- Posts: 14563
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1111 times
- Been thanked: 937 times
- Contact:
Re: ChibiStudio 2020
Is the pointer xxxxxxx a valid address when this happens? perhaps the plugin is trying to fetch data from an invalid address.
Giovanni
Giovanni
Re: ChibiStudio 2020
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]
Re: ChibiStudio 2020
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.
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:
Code: Select all
stklimit stack address size used % prio state name
20000600 20000B1C 20004EB8 1308 196 14% 128 WTEXIT main
200044F8 2000452C 20004618 52 0 0% 1 READY idle
200105F8 20010884 200109A8 652 124 19% 12 WTOREVT lwipthread
2002F9E0 2002FD9C 2002FEF0 956 368 38% 13 QUEUED tcpip
20012DA0 20012EEC 20012FF0 332 0 0% 128 SLEEPING zone
20013050 2001317C 200132A0 300 0 0% 129 QUEUED alarm 1
20013300 2001342C 20013550 300 0 0% 129 QUEUED alarm 2
200135B0 200136DC 20013800 300 0 0% 129 QUEUED alarm 3
20013860 200138F4 20013A30 148 0 0% 128 QUEUED logger
20013A90 20013BB4 20013CE0 292 0 0% 128 WTOREVT rs485
20013D40 20013E6C 20013F90 300 0 0% 127 QUEUED registration
20013FF0 2001414C 20014280 348 0 0% 127 QUEUED sensor
200142E0 2001443C 20014530 348 88 25% 128 SLEEPING modem
200145B0 2001471C 20014840 364 0 0% 128 QUEUED alert
200148A0 200149BC 20014AF0 284 4 1% 128 SLEEPING service
20014B50 20014C94 20014DA0 324 0 0% 128 WTSEM radio
20014E00 20014F44 20015090 324 0 0% 127 QUEUED trigger
200150F0 20015974 20015AC0 2180 28 1% 3 QUEUED tcl
20015B20 20015E34 20015FB0 788 556 70% 126 QUEUED mqtt
20016010 200160AC 200161A0 156 3 1% 2 SLEEPING heartbeat
2002F428 2002F79C 2002F978 884 96 10% 129 CURRENT shell
Just to say, all works fine even when I keep my lwip stack at 1k. But I keep wonder whether I do something wrong.
- Giovanni
- Site Admin
- Posts: 14563
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1111 times
- Been thanked: 937 times
- Contact:
Re: ChibiStudio 2020
To correct my self, I spoke about tcpip thread not lwip thread. But the idea is the same.
- Giovanni
- Site Admin
- Posts: 14563
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1111 times
- Been thanked: 937 times
- Contact:
Who is online
Users browsing this forum: No registered users and 10 guests