2
\$\begingroup\$

I was reading the STM32 Programming manual and somewhere on "page 18 " i see these two kind of stack pointers. I always think that there is only ONE stack and therefore only ONE stack pointer to that exists in MCUs and now i'm confused of what these pointers are and what's the difference between theme and each of these is used for what?

\$\endgroup\$
  • \$\begingroup\$ I can't speak to the STM32 family, as I've only barely used it and then only to prove that a demo board I received (for free) actually worked okay for as few simple things, written in C. However, if I had to guess, they may support two operating modes; one used by a supervisor or operating system and one used by the currently running process. Having two separate stack pointers for those two purposes could offer a few small advantages in some circumstances. Another use might be for a stack pointer and a stack frame pointer. Anyway, I'd need to read up to find out why. Maybe I will. \$\endgroup\$ – jonk Oct 29 '18 at 18:45
  • 2
    \$\begingroup\$ @jonk A friend of mine held a talk on these pointers, and their use in (RT)OSes for Cortex-M microprocessors :archive.fosdem.org/2018/schedule/event/multitasking_on_cortexm \$\endgroup\$ – Marcus Müller Oct 29 '18 at 18:57
  • \$\begingroup\$ @MarcusMüller I'll bookmark it. I just did a quick skim through it and it's got both very general and therefore useful to me information (someday, perhaps) as well as too-specific information that I'll not use because I (almost) always write my own operating system for embedded work I perform. But looks nice for the general info available and I'll enjoy spending the 3/4 hour, at some point. \$\endgroup\$ – jonk Oct 29 '18 at 19:07
  • \$\begingroup\$ he, nice :) Yeah, the audio was really better there; if you're just into the idea of MSP / PSP, jump to minutes 9 – 12 or so. Always writing your own OS sounds challenging! I do have a very few OSes I like, and for the "most minimal yet deserving the name multi-tasking RTOS", I'd point to ChibiOS. He went to Chromium EC, because he needed something to control power, fan, and stuff in an embedded board with an ARM SoC as main processor. Which was exactly what that OS was designed for (just not for usage in his USRP E-series SDR device, but in a "chromebook" laptop. Details.). \$\endgroup\$ – Marcus Müller Oct 29 '18 at 19:11
6
\$\begingroup\$

You are correct in a way, in the cortex m (which your stm32 is, though I can't say which variant unless you specify a part) there is one active stack pointer r13, this can however be either the MSP or PSP.

The reason for two is to enable the user to easily implement a multi tasking 'operating system'.

The idea is that the PSP or process stack pointer is used by the individual tasks, and the kernel uses the MSP.

When an exception happens, a stack frame gets pushed to the currently active stack pointer, and then switches to use the MSP for the exception handler. In a multi tasking system, if the scheduler caused the exception, it is at this point that you change where the PSP is pointing to be the stack pointer for the next task, and return from the exception. The destacking of the new stack pointer then returns execution to the next task.

If you wish to see an example of code using both, a scheduler I wrote for the Cortex M4f is available on BitBucket, it's not documented, but it is fairly straight forward. A svc instruction is used to start the scheduler, and then pendsv exceptions handle the task switching, the Tick function should be called from a timer to ensure task switching.

\$\endgroup\$
  • \$\begingroup\$ Seemed to me that was the likely explanation, just on principle. Thanks for clarifying the issue. \$\endgroup\$ – jonk Oct 29 '18 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.