topic Re: LPCXpresso debugging with Stack Frame changes in LPCXpresso IDE

LPCXpresso debugging with Stack Frame changes

ronkreymborg — Mon, 03 Apr 2017 04:46:59 GMT

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.

Regards, Ron

Re: LPCXpresso debugging with Stack Frame changes

lpcxpresso_supp — Tue, 04 Apr 2017 07:15:30 GMT

I'm not 100% sure I follow the exact problem you are reporting - maybe you could post a couple of screenshots illustrating your problem?

My best guess though would be, assuming the use of assembler code here, is that you have not decorated your sources with the appropriate directives to place the debug symbols in the image that gdb needs (or potentially not built your assembler sources with debug enabled).

Regards,

LPCXpresso Support

Re: LPCXpresso debugging with Stack Frame changes

ronkreymborg — Wed, 05 Apr 2017 00:55:29 GMT

While the switch code is assembler (see below), the code to be debugged is either C or C++. Are you suggesting I can add some additional directives in this code that will take the debugger with it to the new stack?

Regards, Ron

/******************************************************************************

PROGRAM: JenOSHandler.s

FUNCTION: Assembler code to handle the single stack for PendSV/SVC events.

AUTHOR: Ron Kreymborg

REVISION:

******************************************************************************/

.syntax unified

.thumb

.section .text.JenOSHandlers

.global PendSV_Handler

.type PendSV_Handler, %function

.global SVC_Handler

.type SVC_Handler, %function

.type pendSV_ret, %function

.extern ExecutePendSV, %function

Re: LPCXpresso debugging with Stack Frame changes

lpcxpresso_supp — Wed, 05 Apr 2017 10:12:12 GMT

Might be worth seeing if wrapping each function in .func / .endfunc helps. You would be advised to use .thumb_func AS WELL.

Beyond that, without more details, a buildable/debuggable example, or at least a few screenshots, I'm afraid that I'm not sure what else to suggest.

Regards,

LPCXpresso Support

Re: LPCXpresso debugging with Stack Frame changes

ronkreymborg — Fri, 07 Apr 2017 06:05:11 GMT

Thanks for those suggestions. I will try and setup test case that demonstrates the situation.

I guess my original question was what has just happened when a program halts at a breakpoint? As I understand it, this was all setup in the System Debug registers and it is this hardware that halts the processor, at that point nothing to do with Xpresso. However, once the processor has halted it is up to Xpresso to manage this register set as to variable probes, restart, etc.

Other OSs such as FreeRTOS must have this problem. How do they debug after stack changes?

Regards, Ron