Hello,
We are currently integrating a protocol stack with a Radio IRQ in a TrustZone environment with the TF-M as the SPE.
The Radio IRQ requires fast treatment from our protocol stack, the need is to have the Radio IRQ handled with the lowest latency possible.
The fact that all the IRQs in the NonSecure side can’t preempt IRQ on the Secure side in the TF-M design leads us to the following possibilities with several limitations:
- Having the Radio IRQ as the lowest priority on the NonSecure side: if a user creates its own partition with an IRQ (which by design will have a lower priority of
our IRQ because it’s in the Secure side), it could potentially delay for too long the Radio IRQ processing, thus leading to Radio protocol related issues.
- Having the protocol stack related to the Radio IRQ in a partition directly in Secure side : this configuration is highly disputable from a Security point of view,
the possibility to introduce a Security flaw with the protocol stack in Secure being too high.
- Having the Radio IRQ in a Secure partition (FLIH for faster handling) and forward the IRQ handling to the protocol stack in the NonSecure side, all modifications
to the NVIC registers of this Radio IRQ (enable, disable, priority level) requested by the protocol stack in NonSecure side will have to be done through this partition with TF-M API calls (SFN backend for execution performances) : This configuration will probably
led to issues such as reentrancy on the TF-M (for example if the TF-M forward an IRQ to the NonSecure which then calls TF-M API for Radio NVIC register manipulations) or having to call TF-M from NonSecure in handler mode.
Do you already have experienced with this type of problematics, or do you see TF-M configurations which will be more suitable for such a use-case ?
Thank you,
Regards,
Romain