Examining more "p_state" variables put a different thread as the "culprit". I had a null pointer dereference in there. Ooops. Now lets see if things keep running with that fixed.
[original:]
Hi,
my board is stopping:
(
Code: Select all
gdb) where
#0 _unhandled_exception ()
at ../chibios-git/os/ports/GCC/ARMCMx/STM32F0xx/vectors.c:152
#1 <signal handler called>
#2 0x55555554 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
As far as I understand things, the backtrace indicates that a return or task switch used an unused-position of the stack as the address-to-return-to. As long as I'm not doing "__asm__ (" ...subract something from SP "), I cannot trigger that from C-code.
So that would mean that a part of chibios is using the wrong part of the stack. Right?
I can print the thread structure in the working area. but how do I figure out if this thread is sleeping or active?
Code: Select all
(gdb) print *(Thread *) waPingThread
$1 = {p_next = 0x20001500 <_idle_thread_wa>, p_prev = 0x20001a04 <rlist>,
p_prio = 64, p_ctx = {r13 = 0x20002604 <waPingThread+340>},
p_newer = 0x20002eb8 <waLoggerThread>, p_older = 0x20003bb0 <waThread1>,
p_name = 0x800c6c8 "pinger", p_stklimit = 0x200024fc <waPingThread+76>,
p_state = 6 '\006', p_flags = 0 '\000', p_refs = 1 '\001',
p_preempt = 20 '\024', p_time = 0, p_u = {rdymsg = -1, exitcode = -1,
wtobjp = 0xffffffff, ewmask = 4294967295}, p_waiting = {
p_next = 0x200024dc <waPingThread+44>}, p_msgqueue = {
p_next = 0x200024e0 <waPingThread+48>,
p_prev = 0x200024e0 <waPingThread+48>}, p_msg = -1, p_epending = 0,
p_mtxlist = 0x0, p_realprio = 64, p_mpool = 0xffffffff}
Now the "pinger" is quite simple:
Code: Select all
chRegSetThreadName("pinger");
while (TRUE) {
chThdSleepMilliseconds(15000);
chMBPost (&log_mbox, MSG_PING, 0);
}
Here is the thread structure of the thread that just reported on my serial port: "I'm going to do something".
Code: Select all
(gdb) print *(Thread *) waLoggerThread
$2 = {p_next = 0x20001500 <_idle_thread_wa>, p_prev = 0x20001a04 <rlist>,
p_prio = 64, p_ctx = {r13 = 0x20003394 <waLoggerThread+1244>},
p_newer = 0x20002258 <waMonitorThread>, p_older = 0x200024b0 <waPingThread>,
p_name = 0x800c8f8 "logger_thread",
p_stklimit = 0x20002f04 <waLoggerThread+76>, p_state = 6 '\006',
p_flags = 0 '\000', p_refs = 1 '\001', p_preempt = 20 '\024', p_time = 6872,
p_u = {rdymsg = -1, exitcode = -1, wtobjp = 0xffffffff,
ewmask = 4294967295}, p_waiting = {
p_next = 0x20002ee4 <waLoggerThread+44>}, p_msgqueue = {
p_next = 0x20002ee8 <waLoggerThread+48>,
p_prev = 0x20002ee8 <waLoggerThread+48>}, p_msg = -1, p_epending = 0,
p_mtxlist = 0x0, p_realprio = 64, p_mpool = 0xffffffff}
"research" shows that "p_state=6" means that it is sleeping.... So what happened to cause this crash????