Arm Community
Site
Search
User
Site
Search
User
Support forums
Arm Development Studio forum
PendSV pending inside PendSV handler? (Cortex-M4)
Locked
Locked
Replies
1 reply
Subscribers
119 subscribers
Views
4634 views
Users
0 members are here
Options
Share
More actions
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion
PendSV pending inside PendSV handler? (Cortex-M4)
Konrad Anton
over 12 years ago
Note: This was originally posted on 6th September 2011 at
http://forums.arm.com
Hello all,
I'm debugging a driver which runs on a Freescale Kinetis K60 (Cortex-M4) with the Freescale MQX operating system.
The bug I'm trying to track down: by bombarding my system with thousands of network frames, I can get it randomly into a state where (only) the timer task is running, the PendSV-pending flag in ICSR is set, but the PendSV priority in SHPR3 is lower (0xB0) than the priority of the task (BASEPRI=0x60).
This makes a bit more sense if one considers that MQX runs everything in supervisor mode, with BASEPRI=0xC0 for low-priority tasks (at least in my version of the TWR-board BSP), and BASEPRI<0xC0 for highpriority tasks (e.g. task priority 1 runs at BASEPRI=0x60). Furthermore, when MQX wishes to run the dispatcher (e.g. when unblocking, or in the ISR epilogue if the active task pointer has changed), it sets PendSV pending with priority (BASEPRI-0x10, yes, higher priority), unless PendSV is already pending (in which case the SHPR3 is not considered). Finally, user ISRs are run with whatever value BASEPRI had when the interrupt fired.
One way this setup could lead to the bad state would be if the PendSV-pending flag were set again, with SHPR3=0xB0, during the PendSV handler. Then the PendSV handler could switch to the high-priority task, set BASEPRI=0x60, and when the high-priority task wanted to block itself, it would find PendSV pending, and do nothing.
So I wrote a check into the beginning of the PendSV handler which detects that PendSV is pending in ICSR, and jumps to a nop on which I put a breakpoint and activated the ETM tracer. After a few minutes of forced network traffic, the breakpoint was reached. Inside the PendSV handler, ICSR showed PendSV pending and SHPR3 priority=0xB0. The trace showed an immediate past in which my driver's ISR returned into the MQX ISR epilogue, which set PendSV pending and returned. Immediately afterwards, the PendSV handler was executed and my check found PendSV still pending.
Is it plausible that the PendSV-pending flag could be active immediately after entry into the PendSV handler, without an interrupt interrupting the PendSV handler?
0
Quote