The secure ISR cannot call FreeRTOS APIs or portEND_SWITCHING_ISR directly as FreeRTOS runs in the non-secure world. The OP called a non-secure function from the secure ISR which called FreeRTOS APIs:
Secure ISR | Non-Secure Function
| called from secure ISR
|
+------------+ | +------------+
| | | | |
| 1. Call Non-secure | | 2. xSemaphoreGiveFromISR
| function | | | |
| | | | 3. portEND_SWITCHING_ISR
| | | | |
| | | | |
+------------+ | +------------+
|
|
If we want to implement secureportEND_SWITCHING_ISR, the non-secure function should still do the same -
Secure ISR | Non-Secure Function
| called from secure ISR
|
+------------+ | +------------+
| | | | |
| 1. Call Non-secure | | 2. xSemaphoreGiveFromISR
| function | | | |
| | | | 3. portEND_SWITCHING_ISR
| | | | |
| 4. secureportEND_SWITCHING_ISR | | |
| | | | |
+------------+ | +------------+
|
|
If secureportEND_SWITCHING_ISR only validates interrupt priorities, then all is good. If we also pend the non-secure PendSV from the secureportEND_SWITCHING_ISR, we do not need to worry whether the non-secure function called portEND_SWITCHING_ISR or not (Need to verify that pending PendSV twice does not make the PendSV handler run twice).