RTOS viewer error name = "ÿÿÿ"

ucelia wrote on Friday, February 15, 2013:

I’m new in forum.
I’m a software developer for microchip microcontroller and some times ago I choose to try freeRTOS.
In my actual project an error occur: the program run for some hour than a task seems every Blocked and IDLE task running.
In particular the task that is in Blocked State should wait for message send in a Queue, but Queue become full after some hours and any Send return Error.
I try use debugger to undestand this strange behaviour  so I take RTOS viewer plugin for MPLABX 1.60 and the result is unbeliveble!
I add the Queue and the Semaphore to register for debug every possible blocker situation, but the IDE show wrong info about pointer to queue and his names. In particular in the name of queue there are ÿÿÿ character and the dimension seems some kilo or mega messages despite of 5.
If I watch task register I saw that a TASK disappear and there are multiple instances (two) of a task.
I work with XC16 compiler in MPLABX. The PIC family is PIC24F.
Can someone help me?

rtel wrote on Friday, February 15, 2013:

A similar problem was highlighted recently here:



ucelia wrote on Friday, February 15, 2013:

I’m sorry, I’ve seen that topics, but my problem is difference. I found and follow in link you suggested and similar topics.
In that topics the problems regard the impossibility to see the task, but I see all my task, only after some hours task disappear and entire system lock in Idle state.
The Top description is for the first problem: I don’t understand why that task stop and disappear.
The second is the wrong information about QUEUE state. It seems take not initialized RAM data: all information about QUEUE name, pending messages, dimension of Queue are false.

davedoors wrote on Friday, February 15, 2013:

If the plugin works for a while then stops at the same time your program does it is likely that your program is stopping due to some serious data corruption. If the plug in works the same as the Eclipse plug in then it gets its data by querying the PIC RAM. If the PIC RAM is corrupt the plugin is going to read and then display corrupt data. Just a guess.

ucelia wrote on Monday, February 18, 2013:

Thank You davedoors.
It’s possible that the RAM data is corrupted, this can explain the wrong data information.
My doubt was if the problem is in PIC or in the plugin or in IDE.
Also the tasks problem can be explain by RAM problems, but is there a solution?

davedoors wrote on Monday, February 18, 2013:

Do you have stack checking turned on? http://www.freertos.org/Stacks-and-stack-overflow-checking.html

ucelia wrote on Monday, February 18, 2013:

Ops, I’ve got the vApplicationStackOverflowHook(), but I forget to active it in “FreeRTOSConfig.h”.
Now I’m trying first method…

ucelia wrote on Tuesday, February 19, 2013:

I try to cacth stack overflow, but there are never stack problems. Simply in my system after some times (from some minute to some hours) a task is left and need a restart.
Now I think this is not a RAM problem because from system start I can’t see the Queue information despite Task correctly displayed by RTOS viewer.

rtel wrote on Tuesday, February 19, 2013:

There are certain things that you have to take care of, most of which are documented here:

In particular on the PIC32 you have to ensure that all the interrupt service routines that make use of the interrupt safe FreeRTOS API (functions that end in “FromISR” are interrupt safe) have a priority that is not greater than the configMAX_SYSCALL_PRIORITY setting in FreeRTOSConfig.h.

Other than those generic items, I would need a lot more information about your system to be able to assist further.  You could start by providing information on the structure of your tasks.


ucelia wrote on Thursday, February 21, 2013:

I use a PIC24F not a PIC32, and I don’t find “configMAX_SYSCALL_PRIORITY”, but I’m reading the “FAQHelp.html”.
I think the problem can be my “configTICK_RATE_HZ”, I change it from sub-kHz to 3kHz. I have to change interrupt configuration to set that RATE and set

#define configUSE_16_BIT_TICKS 0

Another problem can be due to interrupt priority, it can be too high.

I try to solve theese problems.

Thank You