rtel wrote on Wednesday, June 15, 2016:
I think this is a port you are creating yourself, which means you need to have a deep understanding of how the architecture behaves when you execute the software trap. It might be that a software trap cannot be used in this circumstance, or if it can be used, that you need to ensure the trap entry and exit code performs any actions necessary to ensure the task restarts in exactly the same state (same register values, same stack, same stack pointer, same control register values, etc.). You could create a very simple system with just one task, then step through the asm code as it yields to itself (from an interrupt in your case I think) to see how registers are saved and then restored to see if you end up with an exact same system state after the task is restored.
Is the software trap held pending if you are in a critical section? If so, then it is probably ok, as the trap will execute when you leave the critical section and so execute normally. You can see examples of this in the Cortex-M ports. However, I expect that will not be the case, in which case you will need to save the critical section nesting count as part of the task context, and when restoring the task context use the value saved for the task to know whether to start the task again with interrupts enabled or disabled. You can use one of the many ARM7 demos for examples of how that is done.