Keil Logo

Stack Overflow after mutex but no stack is used

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
Evaluation User
Posted
13-Apr-2011 11:38 GMT
Toolset
ARM
New! Stack Overflow after mutex but no stack is used

Took some time this week and picked up my eval system with MCB1760 with tools to continue testing de keil IDE.
I was testing a mutex when strange things happend.
Normal task16 is sending and receiving serial data and send routines are protected by a mutex.
everything works fine.
When the button is pressed in task7 it should use the serial port and send out a message.
so it has to claim the serial port and i use os_mut_wait.
If the mutex is free (program 16 not sending) it works, if program 16 has the mutex (count=1 or 2) the following is happening (used OS Tasks and system):
task16 priority is increased (OK), state = running (OK) and stackload = Overflow (NOT OK)
task7 state = wait_MUT
breakpoint at void os_error (U32 err_code) entered with 0x01 (= OS_ERR_STK_OVF)

To find the problem i created a user stack and filled it with x16

static U64 task16stack[400/8];
memset(task16stack, 0x16, sizeof(task16stack));
tskID16 = os_tsk_create_user(task16, task16priority, &task16stack, sizeof(task16stack));

before and after only about 50% of the stack has been used, the magic number 0xE25A2EA5 is still in place in this stack (and direct following user created stack).

Any idea's why and which tools from the IDE (good leason) to use to debug this problem?

Read-Only
Author
Andreas Schoepf
Posted
13-Apr-2011 14:09 GMT
Toolset
ARM
New! RE: Stack Overflow after mutex but no stack is used

test it with a higher task priority.

if your Task ID is below 127 the rtl task viewer shows not the truth

Read-Only
Author
Evaluation User
Posted
13-Apr-2011 15:10 GMT
Toolset
ARM
New! RE: Stack Overflow after mutex but no stack is used

TaskID are given by the OS don't know how and why to increase it. Priorities increased (didn't look like the problem as that was working good) and nothing changed.

The i looked at the stack of task7 and saw the magic number was missing and there was some data in the unused part of the stack.
A init routine wrote data in parts of the ram at startup, so at least some parts of the ram didn't contain their expected values (and other variables) causing the program to react strange when the button was pressed.
RTX tasks and System didn't notice this because not everything id tested i think (because of speed?).
So it looks like the problem is solved but the way to find it could have been easier.

Read-Only
Author
Per Westermark
Posted
13-Apr-2011 15:25 GMT
Toolset
ARM
New! RE: Stack Overflow after mutex but no stack is used

Memory corruption is never easy to handle unless you have a debugging interface where you can put a memory access breakpoint on the relevant memory region and see who/what did play dirty.

Next Thread | Thread List | Previous Thread Start a Thread | Settings

  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.