Hi, I have one application with many thread that execute same code. In some cases one task remain in “BLOCKED” state but I can not figure out where. How go to task in blocked state ? Or how find where task is blocked ? Thanks very much. debugasm

Which chip and IDE are you using?

Hi, I use Xilinx Microblaze and Xilinx SDK Ide (Eclipse). debugasm

I think there are two ways of debugging in the SDK (at least, there are on the Zynq). Using the system debugger interface, or using the GDB interface. This is an option when you create the launch configuration. If you are using the GDB interface then the FreeRTOS Eclipse Plug-in may work in the SDK. That will show you the handle (or name, if it is registered in the queue registry) of the object on which the task is blocked. Actually, I just looked at the documentation page for the Microblaze port, and it shows the Eclipse plug-in being used. Search for “kernel aware” on that linked page. Regards.

I normally use the GDB interface on Microblaze. I’ve already integrated in the SDK “FreeRTOS Eclipse Plug-in” and it work very well. This plugin it is very useful to get an overview of all tasks, their status, the level of the stack and monitor of registered queue. Unfortunately there is no way of knowing at what point of the program is each “Task”. It would be very useful if you double click on information of the Task, Eclipse jump to the point where the “Task Switch” occurred, to understand where the task is and maybe insert a new breakpoint. There is no way to know at what address the “Task” has been switched or interrupted by “Task Context Switch” ? Thanks very much. debugasm

The plug-in should show you the queue or semaphore on which the task is blocked. If no queue or semaphore is shown then it is probably blocked on a vTaskDelay() or vTaskDelayUntil(). There are some tools that do what you want (click on a task to see the stack frame for that task) but they are not supported for MicroBlaze (not yet, anyway). You could do it by hand by obtaining the tasks stack pointer and working it out from the stack frame you can see in the portSAVE_CONTEXT macro which you will find defined in FreeRTOS/Source/Portable/GCC/MicroBlaze/portasm.s. The stack pointer can be obtained from the tasks handle, which is a pointer to the tasks TCB – and the first item in the TCB is the task’s ‘top of stack’. So the handle is in effect a pointer to the task’s top of stack. Regards.

Hi,

The plug-in should show you the queue or semaphore on which the task is blocked. If no queue or semaphore is shown then it is probably blocked on a vTaskDelay() or vTaskDelayUntil().

Or in a code loop type: “while” or “for” …

There are some tools that do what you want (click on a task to see the stack frame for that task) but they are not supported for MicroBlaze (not yet, anyway).

Many things are complicated with MicroBlaze, I regret having chosen as a management processor.

You could do it by hand by obtaining the tasks stack pointer and working it out from the stack frame you can see in the portSAVE_CONTEXT macro which you will find defined in FreeRTOS/Source/Portable/GCC/MicroBlaze/portasm.s.

You have the eyes around the kernel. For me it is a little trickier. I have finded the macro “portSAVE_CONTEXT” at the end I can see:

/* Save the top of stack value to the TCB. */
lwi r3, r0, pxCurrentTCB
sw  r1, r0, r3

The state of the CPU on one task is saved on pxCurrentTCB pointer before switch to another task. Is a true ?

The stack pointer can be obtained from the tasks handle, which is a pointer to the tasks TCB – and the first item in the TCB is the task’s ‘top of stack’. So the handle is in effect a pointer to the task’s top of stack.

For obtain a “tasks handle” I have to save the “handle” that vTaskCreate return ? Regards, debugasm

For obtain a “tasks handle” I have to save the “handle” that vTaskCreate return ?

Yes – the last parameter of xTaskCreate() is used to pass back a handle to the task being created, if it is required. Regards.

Yes – the last parameter of xTaskCreate() is used to pass back a handle to the task being created, if it is required.

I’ll try as you described. Trusting that sooner or later the plugin “Stateviewer” can jump to the instruction of the task in which the context switch occurred. Thanks very much. debugasm