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?
test it with a higher task priority.
if your Task ID is below 127 the rtl task viewer shows not the truth
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.
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.