CCS/TMS570LC4357: FreeRTOS + Custom Code = Stack Overflow, even though the stack is inmense. What can tell me the origin of the overflow and am I increasing the correct stack?

Julian Spahr

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

Hi,

Mi name is Julian and I've been working with a TMS570LC4357 for quite a while now. Long story short, I have a setup where I'm using a TMS570LC4357 with a FreeRTOS and a custom code that processes whatever the serial port gives as input, and then sends its output via EMAC to another board. I'm feeding data to the first board via serial port with my terminal.

All in all, I have tried this setup WITHOUT any custom code that processes the input. I have connected both boards (incidentaly, both of the same model) and they communicate well with a periodically generated frame that is sent via EMAC. Now, once I introduce my processing code, I get up to a few (totally random) executions without problems. But after a certain number of executions, the board stops operating, as a Stack Overflow has ocurred. I'm managing the overflow by using the Stack Overflow Hook task from FreeRTOS.

Now, up until here it seems pretty normal. I introduce a new function in a system that works, and now it has an overflow problem, ergo the function is at fault. But the code should have more than enough space in the RAM in order to not cause a Stack Overflow. Even then, I have increased the User Stack Length to 0x1A000 (106496), which is already a fifth of my RAM (it is a lot!). Even then, the same error occurs.

This brings me to my question: how can I determine WHO caused the overflow? It seems obvious that the fault is of my processing function,yet... how can I trace it? Simply, the Stack Overflow occurs, and I'm sent to the Data Entry interrupt (basically an error!) and I'm left to find out via the LR. And the LR sends me to "portSAVE_CONTEXT" (saves the context of the current task in the OS) which to me does not mean too much (why would an overflow ocurr when saving a task?).

And lastly: there are several different types of stacks, as evidenced by Halcogen (total stack, user stack, supervisor stack, fiq stack, irq stack, abort stack, undefined stack). Am I increasing the size of the wrong stack?

I very much apologize for being vague, as the system has a lot of different elements. But I think that narrowing it down to a working OS + custom code, it can be solved. Yet, I'm unsure about the types of stacks and who has caused the overflow (inside of my function, of course), which obviously has brought me here.

Best regards and thank you for reading,

Julian

edit: phrasing.

over 7 years ago

0 QJ Wang over 7 years ago

TI__Guru**** 196776 points

Hello Julian,

I am sorry I am not very familiar to this question. I will forward to our SW engineer. BTW, this link may be helpful:
www.freertos.org/a00111.html

0 Sunil Oak over 7 years ago in reply to QJ Wang

TI__Mastermind 49120 points

You can consider the tools mentioned in this post from our development tools' e2e support forum:
e2e.ti.com/.../417534

0 Julian Spahr over 7 years ago

Prodigy 70 points

Hi community,

I have found the issue. After a bit of wrangling with the memory and stacksizes, we've come to the conclusion that increasing the User Stack size was not correct. The problem was that the Function Stack Size was very low!

In order to correct these matters, we decreased the User Stack size to a 'normal' value, increased the FreeRTOS heap and then increased the Function Stack size. Since our software is data heavy, we increased the heap and stack sizes by a factor of 4 to accommodate the function.

This was basically the reason why the LR register linked me back to a seemingly arbitrary point of the OS' operation, as our task would fail at the same point of our testbench (all the time) but meanwhile the OS would not be at the same point with reference to any other execution of the testbench. Basically the OS might have been doing something else in every testbench during the stack overflow caused by the task.

Once again, thanks to whoever read this! It was way more simple than expected.

Regards,
Julian

0 Alex Chapman over 7 years ago in reply to Julian Spahr

Prodigy 10 points

Hi Julian,

I am facing similar trouble with overflow on the same board. I have a newbie question about how you implemented your solution. Where does one set Function Stack size? I ask because I have not found reference to that exact name.

Thanks!
Alex

0 Julian Spahr over 7 years ago in reply to Alex Chapman

Prodigy 70 points

Hi Alex,

The function stack size is specified during the task creation. FreeRTOS examples normally create tasks with a stack size equals to the minimum value. As far as I remember, my Halcogen project had a minimal stack size of 128 words. This is 128 * 4 bytes = 512 bytes. You can set any other minimum, but I recommend creating a task with your desired value.

From a FreeRTOS example:

xReturned = xTaskCreate(

vTaskCode, /* Function that implements the task. */

"NAME", /* Text name for the task. */

STACK_SIZE, /* Stack size in words, not bytes. */

( void * ) 1, /* Parameter passed into the task. */

tskIDLE_PRIORITY,/* Priority at which the task is created. */

&xHandle ); /* Used to pass out the created task's handle. */

Cheers,

Julian

0 QJ Wang over 7 years ago in reply to Julian Spahr

TI__Guru**** 196776 points

Thanks Julian.

Arm-based microcontrollers

Arm-based microcontrollers forum

CCS/TMS570LC4357: FreeRTOS + Custom Code = Stack Overflow, even though the stack is inmense. What can tell me the origin of the overflow and am I increasing the correct stack?