So, here's what is going on. From main(), I issue a wspiCommand. The main() thread duly goes to sleep, as it calls osalThreadSuspendS - waiting for the interrupt to occur and wake it up. Great. So, main thread goes to sleep and switches to the IDLE thread. A context switch occurs, and soon after the interrupt happens and I get a Halt with SV#8 (ch.dbg.lock_cnt != 0).
1. ch.dbg.lock_cnt is 1 when the main() thread goes to sleep by calling osalThreadSuspendS(). I created a trace event here - see USER wspicmd below.
2. A context switch occurs to the IDLE thread
3. Vector15C (STM32_QUADSPI1_HANDLER) interrupt occurs
4. Halt SV#8
I captured a trace of what's going on:
Code: Select all
0,t=21,dt=0,rt=3705723 HALT {reason = 0x801c33c "SV#8"}
1,t=21,dt=0,rt=3705616 ISR_ENTER {name = 0x801b958 <__func__.10306.lto_priv.678> "Vector15C"}
2,t=21,dt=0,rt=3705269 SWITCH in = idle, out_state = 3, wtobjp = (void *) 0x20005f38 <WSPID1+8>
3,t=21,dt=0,rt=3705051 USER wspicmd,1
I knew it would reach the halt condition soon after the osalThreadSuspendS() in wspiCommand, so I placed a breakpoint there. I also added a watchpoint on ch.dbg.lock_cnt, and a breakpoint in the idle thread.
Code: Select all
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080099aa in wspiCommand at ../../ChibiOS_20.x.x/os/hal/osal/rt-nil/osal.h:735
2 hw watchpoint keep y ch.dbg.lock_cnt
3 breakpoint keep y 0x080018c0 in _idle_thread.lto_priv.362 at ../../ChibiOS_20.x.x/os/rt/src/chsys.c:73
As you can see below, it went straight from the osalThreadSuspendS() in wspiCommand() to the Halt without hitting the watchpoint or landing in the idle thread.
Code: Select all
(gdb) where
#0 wspiCommand (wspip=0x20005f30 <WSPID1>, cmdp=cmdp@entry=0x801c460 <cmd_reset_enable_4>) at ../../ChibiOS_20.x.x/os/hal/src/hal_wspi.c:235
(gdb) c
Continuing.
Thread 1 received signal SIGINT, Interrupt.
[Switching to Thread 536900256]
0x080039a0 in chSysHalt (reason=reason@entry=0x801c33c "SV#8") at ../../ChibiOS_20.x.x/os/rt/src/chsys.c:199
All this is happening upon bootup, while I'm initializing a bunch of stuff. I'm probably missing something, but I fail to see where ch.dbg.lock_cnt is decremented back to 0? Other interrupts occur in my system (8 or so UART interrupts while printing out string), but they didn't trigger this problem - but that's probably because it was always in the main thread and never got to switch to the IDLE thread for those interrupts. That's a difference.
Help!