Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Blocked Task ...

Posted by debugasm on September 19, 2014

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


Blocked Task ...

Posted by rtel on September 19, 2014

Which chip and IDE are you using?


Blocked Task ...

Posted by debugasm on September 19, 2014

Hi,

I use Xilinx Microblaze and Xilinx SDK Ide (Eclipse).

debugasm


Blocked Task ...

Posted by rtel on September 19, 2014

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.


Blocked Task ...

Posted by debugasm on September 21, 2014

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


Blocked Task ...

Posted by rtel on September 22, 2014

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.


Blocked Task ...

Posted by debugasm on September 22, 2014

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


Blocked Task ...

Posted by rtel on September 22, 2014

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.


Blocked Task ...

Posted by debugasm on September 23, 2014

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


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS