FreeRTOS on MSP430FF528 understanding stack management

Kernel
#1

nelsonpina wrote on Friday, January 24, 2014:

Hello,

I’m trying to implement my application using FreeRTOS on the MSP430F5528, using IAR, and it has been difficult for me to understand how does the FreeRTOS deals with the task stack…

For what I read in the documentation I bought, each task should have it’s how stack, and every variables I declare in a task should be stored on that task stack… Well when I analyze the memory, that is not what’s happening. The variables, non-static, I declare on tasks are placed near the end of that tasks memory region yes, but randomly ones are inside and others are outside of that task memory region…

My code will run well for some random time, sometimes days other times only a few minutes, when eventually I get the FreeRTOS stack overflow error… I check the RAM memory when this happens and I notice that must of the stack space that I’m given to each task it’s never being used, always showing 0xA5…

Can anyone please give some hints on this?

Thanks a lot.
Best regards,
Nelson

#2

edwards3 wrote on Friday, January 24, 2014:

You have some C source files and use IAR to compile them, so IAR decides where the variables end up, not FreeRTOS. If they are local and not static then they have to be on the stack or in a register, because it is C code. Where you may get confused is that the stack used by a task is not going to be in the stack region declared by the IAR linker. When you create a task FreeRTOS grabs some RAM from the FreeRTOS heap to use as the task’s stack because as you said each task has its own stack. The IAR debugger does not expect to find the stack pointer outside of the stack region it knows, and will output a warning when it finds it pointing somewhere else.

FreeRTOS will move the stack pointer from stack to stack as tasks are start and stop running, but has no control over what is on each stack.

#3

nelsonpina wrote on Monday, January 27, 2014:

Hi MEdwards,

thanks for your feedback.

I’m not getting confused to see that the Stack Pointer is not pointing to the stack region defined in the IAR linker… That´s obviously what should happen, since the FreeRTOS manipulates the Stack Pointer to be on the memory region of the task that is being executed…

The problem starts when the FreeRTOS is running one task, and the Stack Pointer is not pointing to the memory region allocated to that task… Normally it’s pointing to memory regions somewhere between tasks, or even worse, it’s pointing to memory regions that belong to other task…

I believe that something should be wrong on my FreeRTOS configuration for the MSP430F5528…

I appreciate if someone can give me some hints on this.

Thanks,
Nelson

#4

rtel wrote on Monday, January 27, 2014:

As that part has 128K of Flash I’m guessing it is an MSP430X part. So the first question (sorry if it is obvious) is are you using the MSP430X port rather than the standard MSP430 port? Assuming you are, which memory model are you using?

Regards.

#5

nelsonpina wrote on Monday, January 27, 2014:

Hi,

thanks for your feedback…

Yes, I’m using the MSP430X port and the Small Data Model…

Best regards,
Nelson

#6

rtel wrote on Monday, January 27, 2014:

Hmm, the small data/small code model is the simplest case so it is curious you would have an issue. I presume you are using the official port rather than a contributed port?

Are there any architectural differences in the core used in the MSP430F5528 compared to the core used in the MSP430F5438 on which the port was developed?

What is the smallest application you are able to create that exhibits this behaviour - and can it be replicated in the simulator (so I could try using the project)?

Regards.

#7

nelsonpina wrote on Monday, January 27, 2014:

Yes, I’m using the official FreeRTOS port for the MSP430. I started by developing with the 7.3 version and now I’m trying the newest FreeRTOS 7.6…

I don’t believe that there are any differences between the core (instruction set) of the MSP430F5438 and the MSP430F5528… The MSP430F5438 has more RAM, 16KB compared with the 8KB on the MSP430F5528 I’m using but that should not be a problem.

Another thing I already tried was to use the default linker configuration file “lnk430F5528.xcl” instead of using the one I replicated, adjusting the memory regions, from the demo project provided but I didn’t notice any difference…

I will try to develop a simple application, that we can run from the simulator, that shows this behavior and then I will send it to you…

Thanks a lot…

Best Regards,
Nelson

#8

rtel wrote on Monday, January 27, 2014:

You can send it to the “business contact” emaili address found on http://www.freertos.org/contact

Regards.

#9

nelsonpina wrote on Monday, January 27, 2014:

I don’t think I can simulate the MSP430 peripherals using the IAR simulator so it will be difficult to generate the Tick interrupt for the FreeRTOS… Do you have any suggestions?

Otherwise I can just send you the code I just did with 3 task, each one declaring an array with 100 integers, and you can see that those variables are being stored on RAM outside of the memory region of each task… Without tick you can only run the tasks when they are being declared…

Thanks.
Best Regards,
Nelson

#10

rtel wrote on Monday, January 27, 2014:

Although the peripherals are not simulated as such, there is some way of using IAR’s C spy to trigger interrupts, you would have to refer to their documentation as I can’t recall exactly how it is done.

However, if I am able to see the problem by simply stepping through the code that starts the first task, and in so doing ending up in the context of the first task, then that is probably good enough. Please ensure the project can be built ‘out of the box’ - with no absolute paths or anything similar.

[I presume your stack is large enough to hold 100 integers?]

Regards.

#11

nelsonpina wrote on Monday, January 27, 2014:

Yes I gave 512 bytes of RAM to each task…

I will prepare the code and I will send it to you shortly…

Thanks a lot.
Best regards,
Nelson

#12

rtel wrote on Wednesday, January 29, 2014:

I have the project building in the simulator now, but am not sure that I can see an issue.

Some screen shots are attached.

In the first images you can see the situation exactly as task 1 is entered. In the image you can see the stack pointer is set to 0x2714, and the assembly instruction at address 0x53d6 allocates 20 bytes of stack space to hold the 20 byte array (the “sub.w #14, sp” instruction).

In image 2 you can see the memory at 0x2714 (the highlighted 1a in the middle of the Memory window). The stack grows down in memory from there, which is up the screen as the memory is shown in the window.

Next I step through the loop that fills the array with ‘a’ (by the way, your loop writes outside of the array when it writes to the arraya_l[ 20 ] as 19 is the maximum index). Image 3 shows the memory after the loop has completed. You can see the 20 bytes that have been set to 0 all fall within the stack space. You can also see the stack pointer (after the 20 byte adjustment as per the first image) is pointing to the stack after the space that was allocated for the array.

Is this what you see also? Am I looking at the wrong thing? If so, please provide instructions on how to get the erroneous condition.

Regards.