Hi,

FreeRTOS7.0.1.
Cortex-M3 (EnergyMicro)

I have added an array of pointers to the top of the stack for each task for debugging purposes (some of tasks are stick). Would you like to help me to find the last program counter (PC) value, stored in stack after task context is switched?

Thank you!

What do you mean "some of tasks are stuck"? Is it that a task that was running does not run any more?

What is it you are trying to achieve?

Which compiler are you using?

Regards.

Yes, some of tasks that was running does not run any more.
I'm trying to determine address of the last instruction that is executed in the task, before scheduler has switched to another task.
I use IAR32 compiler for ARM.

Thank you.

Probably the best place to start is to use the FreeRTOS plug in for IAR. If you are using a recent version of IAR then it will already be installed. The plug in will tell you the state of every task, the location of the top of its stack, and which queue/semaphore the task is blocked of (if it is in the Blocked state).

Regards.

This solution is a bit complicated for me, because my problem does not occur periodically (by accident) with a long interval of time (days) and not in each of device, that my software is run.
Therefore, I run a lot of devices, and if in any of device the problem is occurred, the device will send "dump" of debug info (include PC value) through UART..

I prefer to determine address of the last instruction that is executed in the task in Run-Time and add it to the "dump" of my debug info.

Thank you.

When the task that is "stuck" gets stuck, does the rest of the system continue executing? If so, then the stuck task cannot itself be in the Running state. You could then use the traceTASK_SWITCHED_OUT() macro to log some data about each task as it is switched out of the Running state - how useful that is would be debatable though. For example:

1) If the task is switched out because it yields, the last instruction it executes will always be in the yield function, and that tells you nothing about why it was yielding. You could get around that by using more trace macros to also log data about why yield was called (for example, was it a block on a queue, or because vTaskDelay() was called, etc.).

2) If a task no longer runs it might be because a completely different task is using all the CPU time, and starving it of any time itself.

Regards.

The problem begins with a specific task (I know his identity). From the outside it looks like the task does not respond to messages. System has enough CPU time (IDLE task is invoked periodically). I will I try to use trace macros to get more debugging information.

Thank you.