Hello All,

In my port - after a while; I have some debug printf's in the idle task - and they stop running; I have a task hook that prints the available heap - and that is OK (unchanged). I would have thought I would see a memory leak that caused the idle task issue; but so far I am not seeing that. I am using heap5.c.

All of the other tasks appear to be OK.

Has anyone seen this behavior? I don't see it until the port runs for more than 1 hour or so.

Thanks In Advance, John W.

So the system is still running, but the messages printed from the idle task stop...so either the Idle task has stopped or printf() is no longer outputting to the terminal.

After this has happened, are you able to put a break point in the Idle task and see the break point get hit? Or if that is not possible, have the idle task increment a global variable, and pause on the debugger a few times and see if the variable is still being incremented, indicating that the Idle task is still cycling.

If the Idle task is still cycling then it would seem that the problem was simply that printf() was no longer working. Where is printf() sending its output? (UART, terminal, UDP port, etc.)

With this debugger - I can connect to a running target - none of the breakpoints in the Idle task ever got hit - hence the Idle task appeared not to be running at all; or had gotten suspended or the equivalent of that.

Here's an example: main:ADC11 id: 0xb, data: 0x7b9 main:ADC11 id: 0xb, data: 0x7b9 main:ADC11 id: 0xb, data: 0x7b9 - task hook - :0xcb80 - task hook - :0xcb80 - task hook - :0xcb80

The printf in the idle task hook stops - that is the one that starts: main:ADC... but the task hook is a printf in a task hook - and that keeps running. The 0xcb80 is what is returned from reading what is available on the heap.

Thanks, John W.

Can you take the printf out and instead toggle a pin in the idle task, then check the pin is still toggling? Maybe the printf is the problem.