Are cortex-M thread/handler mode, unprivileged level and process stack in use?

Kernel
1

The ARM cortex-M uC provide:

  • thread mode and handler mode

  • privileged and unprivileged levels

  • main stack and process stack

Does OpenRTOS/FreeRTOS ports for cortex-m make use of these hardware features?

This question is not about MMU or MPU. Just about the uC core features.

Thanks

2

Yes. See e.g. the Cortex-M3 portable layer source in case you’re interested in details :slight_smile:

3
  • thread mode and handler mode
  • privileged and unprivileged levels

These are used by ports with MPU support, like ARM_CM3_MPU and ARM_CM4_MPU.

  • main stack and process stack

This is used by all the Cortex-M ports.

4

While debugging my last problem I noticed that process stack limit (psplim) is also used on the supporting architectures(CM23 and CM33 with trustzone), but connected ISRs went to default handlers instead of going to vApplicationStackOverflowHook.
Are there any plans to directly handle those ISRs in the future?

5

Although maybe it is best to let the application developer handle those exceptions directly. So the ARMv8-M port would continue not to call vApplicationStackOverflowHook() at all. FreeRTOS isn’t really involved in detecting stack overflow on this platform, so that’s one way to look at it.

6

That is because Usage Fault Handler is installed by the application and the hardware detects the overflow and executes the Usage Fault Handler.

7

Well it is involved already because it DOES set psplim (what I do appreciate since there is no way this could be sensibly added from outside the kernel). So starting from there I think it would only be a logical completion to also offer a default Usage Fault Handler implementation which maps back to the standard interface.
I think in the moment configCHECK_FOR_STACK_OVERFLOW
is only overhead on the CM33 port since there is no way to reach this without faulting before.

8

Thank you for the suggestion - we will look into it.

1 Like