Interesting issue with using Cortex-M SVC for system calls  - Page 1
Forum section: electronics / general

author: richardman
author_rank: Frequent Contributor
timestamp: July 26, 2018, 02:50:36 am
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: July 26, 2018, 04:19:39 am
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: July 26, 2018, 05:29:04 am
content: From the architecture manual:QuoteExecuting an SVC when the current exception priority is negative (ie. inside an NMI or HardFault exception handler) results in a Lockup state.

author: richardman
author_rank: Frequent Contributor
timestamp: July 26, 2018, 05:29:21 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: July 26, 2018, 08:01:37 am
content: Quote from: andersm on July 26, 2018, 05:29:04 amIt 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: July 26, 2018, 12:06:10 pm
content: 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:osThreadGetPriorityI.e., they use SVCall, but not for directly invoking the API. A lot of the RTX API is available to interrupt handlers.