I am using the version 5.0.0 port of FreeRTOS for the Cortex M3 with the Rowley toolchain (or at least, the comment block at the top of the files claims to be version 5.0.0). It was going fine for quite a while, but just recently I am having stack corruption problems (that may very well be my own fault), and I'm trying to determine if one of the Cortex M3's stack pointers is used, or both stack pointers. In my repository where I keep a copy of the FreeRTOS source code, I have a directory under demo named "CORTEX_STM32F103_Primer_Rowley". I downloaded a zip file of V5.4.0, and it doesn't have a directory by that name. I then re-downloaded V5.0.0, and it *also* doesn't have a directory by that name!

The thing in particular I am looking for is if there have been any updates to the linker script I am using. It was called FRTOS_1.ld in the copy of the code I have, and I do not see a file by that name anywhere in the fresh zipfile of V5.0.0, or V5.4.0. In fact, I don't find any linker scripts at all, for any of the STM32 demos.

If anyone could enlighten me, I would much appreciate it.

I tried building Demo/CORTEX_STM32F107_GCC_Rowley from FreeRTOS V5.4.0 with the Rowley Crossworks IDE, and it said "no linker script or memory map file specified". That's without doing anything but double-clicking the .hzp file to launch crossworks, and then clicking build. So it looks like Crossworks is confused about the same thing I am: where's the linker script (.ld file)?

I dont know where you got the demo from? Maybe the STM32 circle site?

Have you installed the STM32 package in Rowley? This is a separate step to installing the IDE.

It appears that the old startup code that I had wasn't initializing the 2nd stack, and it was somehow getting set to an area of RAM that overlapped where BSS would go, if BSS was big enough. I modified the linker script (still don't know where that came from, probably auto-generated by some IDE I used in the past, perhaps Rowley CrossWorks) and startup code (Rowley's thumb_crt0.s) so that the 2nd stack would go in it's own block of RAM reserved for that purpose, and the problem has gone away.

Not quite sure on the terminology, but as I understand it the Cortex M3 has a main stack and a process stack. The normal stack pointer ("sp") is like a window that looks at the psp (process stack pointer) or the msp (main stack pointer), depending on a separate control bit. So you can flip the bit and modify sp to set each, or you can use a special msr instruction to modify msp or psp directly ("msr psp, r0" loads the psp from register r0).