PendSV Pending Bit

[mileca]

Posted on December 08, 2010 at 02:17

PendSV Pending Bit

[Tesla DeLorean]

Posted on May 17, 2011 at 14:17

Chances are the number of places you are setting the PendSV bit are fairly finite. You could probably removed them or instrument them. It's hard to do things atomically, but you should be able to identify the cause/sequence with a bit of thought/effort.

If you are using a standard RTOS (I suspect you are, but you don't name it), the interrupt(s) servicing the USART or other hardware interrupts do have priority, and are setting the PendSV. You could instrument the entry/exit of these handlers by queuing a character in a FIFO, and either output that memory to a spare USART, or sit the JTAG memory view window over it. And then identify the condition you are looking for. Personally, I would *not* have high frequency interrupts causing task switches all the time, as it chews up resources doing no useful work, unless there was some compelling reason to. Rather than have every single character coming in the USART trigger a switch, consider doing it on a ticker, or when things actually block.

[mileca]

Posted on May 17, 2011 at 14:17

Thank you for you answer.

The RTOS is one made by me. This is my code, by the way. __asm void PendSVHandler(void) {     PRESERVE8     CPSID   i     .... code here (context save/restore) ...     .... Here is when I check for pending bit and          sometimes I find it SET ...     CPSIE   i     BX      LR     ALIGN    4 } This is the most ''atomic'' method I have found. If anyone has another, please comment it. So this is why I don't get where this bit is set. I the case of a ''late arrival'', what happens with the PendSV Pending Bit? Suppose that when stacking for PendSV an interrupt for USART1 arrives. PS: Regarding USART interrupts generating context switches, I have a priority scheme around threads so (and in this particular case) the arrival of chars through USART1 does not generates context switches. Actually I am testing with only two threads. Today I will check with only one to see what happens. Thank you again.

[mileca]

Posted on May 17, 2011 at 14:17

Hi All,

I did some test, and the result is that the handler code above does not ensure atomicity. In fact the USART ISR was setting the pending bit... just because the USART ISR was being executed right after entering PendSV handler and before ''CPSID i''. The result comes from the fact I checked the Active IRQ bit for PendSV at the USART ISR, set a breakpoint (when active = 1) and followed it to see where it lands right after exiting the USART ISR: the next instruction was ''CPSID i'' inside PendSV. So I will be toggling off the pending bit inside the PendSV handler. Has anyone a better idea? Thanks.