RTOS-Aware Plug-In: Call stack for selected task?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • RTOS-Aware Plug-In: Call stack for selected task?

      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

      The post was edited 1 time, last by dnfuss ().

    • Hello David,

      Yes that is possible. if the Plugin is fully implemented callstack, registers, etc. will always show the context of the currently selected task in the plugin window.
      It was essentially discussed here:
      [SOLVED] RTOS plugins

      For reference we recommend to use the embOS plugin source where this feature is available as well.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • 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
    • New

      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
    • New

      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
    • New

      Hello,

      dnfuss wrote:

      or does a full implementation of getregs give enough for display of callstack?
      Yes that is all information that is needed.

      Regarding the callstack. This can only be reconstructed if the stack frame information is available. For interrupts it is possible that the stack frame is not available.
      Please see the getregs() implementation of the embOSPLugin.js for reference.
      There everything is implemented correctly.

      Please understand that we can't put more time into this inquiry as it exceeds the free support that we can offer via the community forum.

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.