- Reason:
A task and B interrupt indirectly access the shared resource pxDelayedTaskList without proper security protection, leading to further crash.
A task uses xEventGroupSetBits() to access the pxDelayedTaskList resource:
xEventGroupSetBits() -> vTaskRemoveFromUnorderedEventList() -> uxListRemove() -> pxList, where pxList is the pxDelayedTaskList.
At this point, another B interrupt is triggered (xEventGroupSetBits only suspends task scheduling and does not disable interrupts) and also accesses the pxDelayedTaskList resource:
MacIsrSigPostDefHdl() -> __wifi_queue_send_from_isr() -> xQueueGenericSendFromISR() -> xTaskRemoveFromEventList() -> prvResetNextTaskUnblockTime() -> pxDelayedTaskList.
This leads to an unsafe access to the pxDelayedTaskList resource by two entities, causing subsequent crash exceptions.
- Fix:
Modify the timing of the call to prvResetNextTaskUnblockTime() within xTaskRemoveFromEventList from unconditional execution to only execute when task scheduling is enabled.
This way, when the B interrupt reaches xTaskRemoveFromEventList, it will not call prvResetNextTaskUnblockTime to access the pxDelayedTaskList resource (due to task scheduling being disabled).
After the B interrupt execution is complete and control returns to A task, xTaskResumeAll() will be called, and then prvResetNextTaskUnblockTime() will update the pxDelayedTaskList resource again.
old: CCOMPARE timer triggers when CCOUNT increase to equal to CCOMPARE, then ISR will increase integer of "_xt_tick_divisor"
to CCOMPARE and wait for next interrupt triggering
now: CCOMPARE timer triggers when CCOUNT increase to equal to CCOMPARE, then ISR will reset CCOUNT to be 0 and reset CCOMPARE
to be integer of "_xt_tick_divisor", then wait for next interrupt triggering
Using the new method, we may get the CCOUNT value without considing if it has overflowed.
System running microseconds = g_os_ticks * microseconds per tick + CCOUNT.
