Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

task_manager_start() resets stack pointer, ignoring previously stack-allocated memory

I am trying to use the experimental task manager of the nrf52sdk, version 17.1.0. I've come across what I would call a bug, but there might be a reasoning behind it, so that's what's bringing me here. I estimate I can convey the issue without a minimal working example and instead describe the issue.

Consider the following scenario, where there are stack allocations followed by a call to task_manager_start():

int main(int argc, char** argv) {
    
    // stack allocations
    
    task_manager_start(someIdleTask, nullptr);

}

In task_manager_start, at line 249 of task_manager.c there is the following code:

__set_MSP((uint32_t)(STACK_TOP));

This resets the stack pointer to the top of the stack, causing all memory allocated in the stack frame of main() to be overwritten when an interrupt is invoked. Removing the line avoids that.

In the documentation of the experimental task manager it does say "Main stack used for interrupts", but it does not say that any memory allocated in main() will be overwritten. Is this by design? I would argue that it would be better to leave the main stack as-is and simply have interrupts push a frame on the existing stack.

Parents Reply
  • Thanks, we are indeed considering moving to nRF Connect SDK. This transition is not without hassle, so might be postponed. But either that or FreeRTOS sounds like a better alternative, given that the task manager is not to be considered stable. I had hoped it to be considered somewhat mature, given it's been around for some time now, but moving to FreeRTOS or nRF Connect SDK is the better option.

    Cheers,
    Freark

Children
  • In the mean time we moved to FreeRTOS. However, the FreeRTOS port suffers the same issue: vPortStartFirstTask() has the following code in port.c line 60:

                        " msr msp, r0           \n" /* Set the msp back to the start of the stack. */

    Researching it more, it seems that the general consensus (not only w.r.t. this FreeRTOS port or the experimental task manager) is that this saves so much RAM that it is worth unexpectedly shortening the storage duration of these stack-allocated variables (automatic storage duration). I'm surprised by this view, because it does not save that much RAM if the stack was not used in the first place. At the very least this could have been a configuration option within FreeRTOS.

    This is just FYI; I don't expect this to be fixed. It might help someone who comes across this post with the same issue.

Related