ChibiStudio 2020

Report here problems in any of ChibiOS components. This forum is NOT for support.
steved
Posts: 823
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 12 times
Been thanked: 135 times

Re: ChibiStudio 2020

Postby steved » Fri Jul 17, 2020 1:29 pm

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)

mikeprotts
Posts: 166
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 19 times
Been thanked: 31 times

Re: ChibiStudio 2020

Postby mikeprotts » Fri Jul 17, 2020 2:30 pm

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

steved
Posts: 823
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 12 times
Been thanked: 135 times

Re: ChibiStudio 2020

Postby steved » Thu Mar 11, 2021 11:51 am

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?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: ChibiStudio 2020

Postby Giovanni » Thu Mar 11, 2021 1:44 pm

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

Giovanni

steved
Posts: 823
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 12 times
Been thanked: 135 times

Re: ChibiStudio 2020

Postby steved » Thu Mar 11, 2021 2:39 pm

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]

vysocan
Posts: 3
Joined: Tue Feb 18, 2014 7:22 pm
Has thanked: 3 times

Re: ChibiStudio 2020

Postby vysocan » Wed Mar 31, 2021 9:33 am

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:

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.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: ChibiStudio 2020

Postby Giovanni » Wed Mar 31, 2021 9:39 am

Moving this in "bug reports".

Giovanni

vysocan
Posts: 3
Joined: Tue Feb 18, 2014 7:22 pm
Has thanked: 3 times

Re: ChibiStudio 2020

Postby vysocan » Wed Mar 31, 2021 12:33 pm

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

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: ChibiStudio 2020

Postby Giovanni » Sun Dec 05, 2021 10:47 am

bumping as self-reminder


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 16 guests