Hi!

I'm using an RTOS aware plug-in that I've developed for MQX, and I'm wondering if there's any way of having the call stack window reflect the context of the task selected in the displayed table (as in image below)? At present, it appears only to display the context of the active task...




I'm hoping I've just missed something in the documentation, as this would be an extremely useful feature!

Many thanks


David

Thanks Nino

That's good to know- My plugin was derived from the embOS plugin but the MQX kernel structure is very different, so I'll need to find where R0 - R15 and PSR are stored within an MQX task.

You mentioned callstack- is that separate operation to save & restore, or does a full implementation of getregs give enough for display of callstack?

Thanks again

David

Hi
I've got as far as restoring the saved registers (r3-r11 and lr) and setting the aRegs SP and PC indexes to that of the stack frame at the top of the stack when the thread was suspended. Although this does result in the stack changing to that of the selected thread in the plug-in table list, it's only one stack frame deep- How do I include the depth of the stack through the getregs array return mechanism to give me the complete call stack for each selected thread?

(I don't know if it's relevant but the MQX OS restores the stack via the Cortex M4's lr=0x1FFFFFFD exception return mechanism, which may somehow incorporate stack depth but I can't quite see how)

I'd be very grateful for any help getting this asking-it's going to be a very useful feature.

Many thanks

Hi guys- I appreciate you're likely busy with other things, but would like to check that I'm not missing anything obvious with this-

I assume the embOS and ThreadX examples allow a complete backtrace of the call stack when the SP register is set to the stack pointer of a paused thread, which is what I'm doing but I only get one frame in the call stack window, so I'm wondering if I need to be able to set the PSP register on the K60 (as distinct from the SP) before this will work correctly, as this is what the scheduler does when restoring thread context- Is this possible?

Sorry to persist, but we're really needing this feature...

Many thanks