For several years I have been using the well known PenSV/SVC interrupt trick to provide a new stack frame for tasks that are scheduled with a higher priority than the task currently running. The higher priority task with its new stack frame pre-empts the lower priority task, runs to completion, and when it exits the SVC interrupt return manages the stack unpacking and the previous task continues as though nothing had happened. This works well but LPCXpresso has a problem with debugging in processors like the ‘1347 in that when trying to debug a running high priority task, the SWD debugger using the Windows LinkServer apparently cannot handle the stack change and cannot provide any debugging assistance. The breakpoints work and the program stops, but that’s it.
My question is: Are there specific addresses, pointers, etc involved with maintaining the SWD debugger’s grip on what is happening? What I am hoping is in that case I can add the necessary code to include carrying these parameters over into the new stack frame as part of the PendSV/SVC handler.