Hi.
I've been working on making an example on how an application can use the secure interrupts in a secure partition in TF-M. During this I've encountered an issue where the secure partition will not be scheduled to process the secure interrupt signal in certain conditions. I've compared it to the current SLIH and FLIH test cases to my observed behaviour and I could see that they did not have this problem. I've created a test-case that triggers the problem [0].
In the mailing list I can see that this was actually discussed recently [1]
The summary is that secure partitions will not be scheduled to process a secure interrupt signal when the interrupt is interrupting the NSPE. I could not find that this was documented anyway, but maybe I have overlooked. In any case I find this behaviour very unexpected and I would like to know if this is indeed a design decision and the behaviour has to be this way? If I wanted to do some processing in the secure partition context it would now mean that I have to get the NSPE to trigger this through a secure partition call. This seems like a limitation to me .
I'd like to know what would be the issue with scheduling the partition once it now has the signal asserted. I've done a quick test with scheduling the partition at this point with [2] and this now works as I expect it to.
I'd be happy to follow up with submitting a change to schedule the partition as done in [2] if that is an acceptable solution.
[0] https://github.com/joerchan/tf-m-tests/commit/d9f0a3a7653b594d0fa797d9e0bca1... [1] https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.o... [2] https://github.com/joerchan/sdk-trusted-firmware-m/commit/e5512c6e8b2bad95c2...