Open ioannisg opened 5 years ago
There is a work-around for this already merged, hence this should remain a low priority issue.
Removing 2.1 milestone. @ioannisg, can you add a reference to the PR of the workaround you referenced?
Removing 2.1 milestone. @ioannisg, can you add a reference to the PR of the workaround you referenced?
https://github.com/zephyrproject-rtos/zephyr/pull/18713
This PR fixed this by doing some inspection of the escalated hard fault.
Thinking about this, maybe we cab turn this to an enhancement, because the workaround has been stable for quite some time now. Z_ARCH_EXCEPT does work for Baseline cortex-m via the hard-fault inspection. Need to think if this should actually be made to work as it does for Mainline: it would probably eat an IRQ level for SVC and we don't have many levels available in Baseline.
Describe the bug Z_ARCH_EXCEPT() is called, to signal errors directly from Software. In ARM Cortex-M, this is implemented with a synchronous SVC instruction, with code 2.
In Mainline SOCs this works well, because the kernel reserves the highest interrupt priority for the SVC Handler.
In Baseline cores, however, we do not reserve an interrupt priority for the SVC. So if Z_ARCH_EXCEPT() is invoked from an interrupt with the highest priority, the SVC Call won't be able to execute and will trigger a synchronous (Escalated) hard fault.
To Reproduce We have a bug report already for this: #18590
Impact We are not able to infer stack-fail checks in Baseline ARM CPUs with the STACK Sentinel feature.
We do get a system exception, however, so the user is still getting some information that something went wrong.