Interesting issue with using Cortex-M SVC for system calls

[richardman]

For our RTOS, I have decided to use SVC for syscall (since you can pass an 8-bit argument to specify which system call), PendSV for context switching, and  the SysTick timer for the tick interrupt. These exceptions run at lowest priority urgency (15 for the -M4/-M7) so peripheral interrupts have higher priorities.

All are working great, we have 2 sets of message passing (synchronous QNX style and Mailboxes) API, Semaphores, MUTEX etc. Then I integrated it with lwIP, and after getting everything to build, the test started to crash fairly early on.

The problem is that the ethernet driver uses a callback function to signal a semaphore to alert the main TCP/IP thread that data is available. As the callback is made in an interrupt handler, the SVC call does... I have no idea what. (Since I was just swapping code out, I did not realize that the semaphore signaling is happening inside an ISR handler.)

(Solution is simple: provide some API that are safe to call from an ISR. FreeRTOS has similar set of API even though it does not use SVC for syscalls)

The question is, from the CPU/MCU point of view, what exactly happens when an ISR handler calls the SVC instruction with lower urgency? It cannot take the SVC exception immediately, but does it somehow pend the SVC execution, which kind of makes no sense either, or does it treat it as a no-op?

Anyone knows?

[ataradov]

Calling SVC inside SVC, NMI and Hard Fault results in a Usage Fault, that's for sure.

I would guess the same applies to calling it from other interrupt handlers with the same of higher priority. 

[andersm]

From the architecture manual:

When the current execution priority is less than HardFault, the processor escalates the exception priority to HardFault in the following cases:

• When the group priority of a pending synchronous fault or supervisor call is lower than or equal to the currently executing priority, inhibiting normal preemption. This applies to all synchronous exceptions, both faults and SVCalls. This includes a DebugMonitor exception caused by executing a BKPT instruction, but excludes all other DebugMonitor exceptions.
• If a disabled configurable-priority fault occurs.

Escalating the exception priority to HardFault causes the processor to take a HardFault exception.

Executing an SVC when the current exception priority is negative (ie. inside an NMI or HardFault exception handler) results in a Lockup state.

[richardman]

Ah yes, usage fault! Of course. Thanks.

I saw them too, but thought the debugger weren't able to cope with all the interrupts going on.

[brucehoult]

From the architecture manual:

When the current execution priority is less than HardFault, the processor escalates the exception priority to HardFault in the following cases:

• When the group priority of a pending synchronous fault or supervisor call is lower than or equal to the currently executing priority, inhibiting normal preemption. This applies to all synchronous exceptions, both faults and SVCalls. This includes a DebugMonitor exception caused by executing a BKPT instruction, but excludes all other DebugMonitor exceptions.
• If a disabled configurable-priority fault occurs.

Escalating the exception priority to HardFault causes the processor to take a HardFault exception.

Executing an SVC when the current exception priority is negative (ie. inside an NMI or HardFault exception handler) results in a Lockup state.

It looks like you can get to HardFault from things such as executing an FP instruction when you don't have FP hardware .. and that it's ok to detect this, emulate it, and return from the handler.

So it may be OK to examine the faulting instruction, determine it's a SVC, do what was asked if it's from some limited set of "safe" (and/or fast) functions, and return.

[andyturk]

RTX uses SVCall to make sure that some kernel calls are executed in an exception context... The RTX entry points check to see if an exception is active and then forces a SVC if it's in thread mode:

osThreadGetPriority

I.e., they use SVCall, but not for directly invoking the API. A lot of the RTX API is available to interrupt handlers.