• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 349 subscribers
  • Views 5740 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-M33 - SVC call from non-secure code does not trigger non-secure SVC exception

Michael Jung

Hello,

I am trying to do a proof-of-concept running the Apache NuttX RTOS on STMicroelectronic's ST32L562E-DK board as the non-secure application with TrustedFirmware-M (ST's port of TF-M provided with STM32CubeL5).  The ARM core on STM32L5xx MCUs is a Cortex-M33.

I can build, sign and flash NuttX as the non-secure application and TF-M boots into the RTOS initialization code. However, once the RTOS initialization code issues the first SVC instruction (to request an initial context switch to the 'init' task) the corresponding exception handler is not called (I do see systick exception handler calls, so generally the vector table seems to be set up correctly).

What could be the reason that an SVC instruction does not trigger the corresponding exception handler (both the SVC and the handler being in non-secure code)?

Any help is highly appreciated.

Thanks!

Michael

  • +1

    I figured it out: The RTOS uses SVCs while interrupts are disabled, which causes HardFaults. It then detects this situation in the HardFault handler and actually forwards execution to the SVCall handler.

    With standard settings the HardFault handler will switch to the Secure mode, though. Setting the BFHFNMINS bit in the SCB->AIRCR from the secure boot loader before starting the RTOS resolved the situation (it causes HardFaults to be presented in NonSecure state).

    Thanks and bye,

    Michael

  • 0

    Hi Michael,

    The reason for SVC instruction does not trigger the exception might be related to the priority settings of SVC exception.  

    As I understand from your original post, the interrupts are disabled in your case. There is possibility that PRIMASK register is set to 1 masking out all configurable exceptions including SVC leading to your execution priority at 0x0. Assuming that SVC priority is 0x0 and when an SVC instruction is executed at same level of executing priority of 0x0, then it leads to Hardfault escalation. Ideally, it is recommended to fix the reason behind this Hardfault escalation.

    Now, configuring this escalated secure Hardfault handler to non-secure Hardfault via AIRCR.BFHFNMINS could lead to UNPREDICTABLE results. (Refer: Armv8-M Architecture Reference Manual – Information statement -> I-QRDM).

    Hence, instead of configuring AIRCR.BFHFNMINS bit to route escalated Hardfault to Non-secure domain, it will be good to understand the priority settings of SVC exception.

    If in case you are using PRIMASK, then you could try to program BASEPRI register to watermark the list of interrupts/exceptions that you would like to disable.

    Hope this helps

    Thanks,

    Uma