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

[Freark van der Berg]

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.

[Kenneth]

Hi,

I can create a jira for this so someone may look at in in future, but task manager was experimentally created to enable shell over bluetooth, it is not to be considered a stable generic solution. For your information, for new development we strongly encourage using nRF Connect SDK, all new features and development is done on this platform:
nRF Connect SDK and nRF5 SDK statement 

To get started with nRF Connect SDK: https://academy.nordicsemi.com/ 

Best regards,
Kenneth

[Freark van der Berg]

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

[Freark van der Berg]

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.