The issue was observed in SafeQP with MPU enabled. The incorrect context switch caused improper MPU configuration, which resulted in a memory-fault. Here is the software trace from the incident:
3570282348 Sch-Unlk Ceil=7->0
3570282801 QF-gcA Evt<Sig=EAT_SIG,Pool=1,Ref=7>
3570283253 PHILO_STAT 0 eating
3570283815 =>Intern Obj=Table_inst,Sig=DONE_SIG,State=Table_serving
3570284440 QF-gcA Evt<Sig=DONE_SIG,Pool=1,Ref=2>
3570284929 Sch-Next Pri=12->7
3570285394 QF-gc Evt<Sig=DONE_SIG,Pool=1,Ref=1>
3570285846 MP-Put Obj=EvtPool1,Free=9
===RTC===> St-Exit Obj=Philo_inst4,State=Philo_eating
3570286877 Sch-Lock Ceil=0->5
3570287264 Sch-Unlk Ceil=5->0
3570287789 TE0-Arm Obj=Philo_inst->timeEvt4,AO=Philo_inst4,Tim=119,Int=0
===RTC===> St-Entry Obj=Philo_inst4,State=Philo_thinking
3570288957 ===>Tran Obj=Philo_inst4,Sig=TIMEOUT_SIG,State=Philo_eating->Philo_thinking
3570289814 AO-GetL Obj=Philo_inst4,Evt<Sig=EAT_SIG,Pool=1,Ref=6>
3570290412 Disp===> Obj=Philo_inst4,Sig=EAT_SIG,State=Philo_thinking
3570291073 =>Intern Obj=Philo_inst4,Sig=EAT_SIG,State=Philo_thinking
3570291716 QF-gcA Evt<Sig=EAT_SIG,Pool=1,Ref=6>
3570292191 Sch-Next Pri=7->6
3570292634 AO-GetL Obj=Philo_inst3,Evt<Sig=EAT_SIG,Pool=1,Ref=5>
3570293231 Disp===> Obj=Philo_inst3,Sig=EAT_SIG,State=Philo_hungry
===RTC===> St-Unhnd Obj=Philo_inst3,Sig=EAT_SIG,State=Philo_hungry
3570294371 =>Ignore Obj=Philo_inst3,Sig=EAT_SIG,State=Philo_hungry
3570294994 QF-gcA Evt<Sig=EAT_SIG,Pool=1,Ref=5>
3570295469 Sch-Next Pri=6->5
3570295909 AO-GetL Obj=Philo_inst2,Evt<Sig=EAT_SIG,Pool=1,Ref=4>
3570296506 Disp===> Obj=Philo_inst2,Sig=EAT_SIG,State=Philo_eating
3570297170 =>Intern Obj=Philo_inst2,Sig=EAT_SIG,State=Philo_eating
3570297794 QF-gcA Evt<Sig=EAT_SIG,Pool=1,Ref=4>
3570298267 Sch-Next Pri=5->4
3570298707 AO-GetL Obj=Philo_inst1,Evt<Sig=EAT_SIG,Pool=1,Ref=3>
3570299304 Disp===> Obj=Philo_inst1,Sig=EAT_SIG,State=Philo_hungry
===RTC===> St-Unhnd Obj=Philo_inst1,Sig=EAT_SIG,State=Philo_hungry
3570300438 =>Ignore Obj=Philo_inst1,Sig=EAT_SIG,State=Philo_hungry
3570301058 QF-gcA Evt<Sig=EAT_SIG,Pool=1,Ref=3>
3570301533 Sch-Next Pri=4->3
3570301975 AO-GetL Obj=Philo_inst0,Evt<Sig=EAT_SIG,Pool=1,Ref=2>
3570302572 Disp===> Obj=Philo_inst0,Sig=EAT_SIG,State=Philo_hungry
3570303464 Sch-Lock Ceil=0->5
TE0-ADis Obj=TH_XThread1->timeEvt,AO=TH_XThread1
3570304422 TE0-Post Obj=TH_XThread1->timeEvt,Sig=QXK_DELAY_SIG,AO=TH_XThread1
3570305584 Sch-Next Pri=3->11
3570306155 Mtx-UlkA TH_mutex,Hldr=1,Nest=1
3570306709 Mtx-Unlk TH_mutex,Hldr=1,Nest=0
3570307397 Sch-Idle Pri=1->0
3570307888 =ASSERT= Mod=HardFault,Loc=1
Anonymous
The problem was traced to the interaction between scheduler locking and unlocking a priority-ceiling mutex in an extended thread. Specifically, unlocking the mutex causes dropping the priority of the mutex-holding thread. The problem happens while the thread is preempting a basic thread of higher priority than the extended thread, but lower than the priority-ceiling.
The problem was fixed in the QXK scheduler and has been released in QP/C/C++ 8.0.2
--MMS
Fixed in QP/C/C++ 8.0.2.
--MMS