FreeRTOS 6.0.3 & ST 2.0.3 Periph. Li...

Kernel
1

sniper39 wrote on Friday, June 08, 2012:

Hi all,
I’m a beginner in FreeRTOS.
We have a machine based on 3 electronic boards:
1/ Button and Display board 8051
2/ Command board (runs FreeRTOS 6.0.2 + ST peripheral Lib 2.0.3)
3/ Valves board (runs FreeRTOS 6.0.2 + ST peripheral Lib 2.0.3)
In normal cycle the system is activated by buttons for a 30 min cycle.
During this cycle the command board sends a data stream to the valves boards with desired pressure and a duration to achieve that task. The valve board is supposed  to control a pump and to switch on and off different valves to obtain the right pressure.  When the task is completed the valve board sends back an acknowledge data stream to confirm that the task has been well executed. So the command board, sends the next data and it keep working like that.
The machines can get to work well for several days and sometimes they bugs 2 or 3 times a day.
The unknown bug stops the machine before the end of the 30 min cycle:
In fact, as we checked with a scope, the valve board sends back the last acknowledge but the command board seems like it didn’t received it and keep on waiting.
So my question is…
Is there a way to check each task or interrupt routine running on the command board when the acknoledge is suppose to arrive.
Is there some update or correction to be done on the 6.0.2 FreeRTOS. (6.0.2 is it a stable version ?)
Is there some update or correction to be done on the 2.0.3 ST Peripheral Lib ?
Do you recommend the use of those versions ?
Thanks in advance

2

rtel wrote on Friday, June 08, 2012:

Version 6.0.2 is very old, but all official releases are stable, so it should be fine other than it won’t include the latest features.

If you are using the IAR or Eclipse IDEs then you can get basic information from their respective FreeRTOS state viewer plug-ins. 

If you can determine the time the error occurs, then the most powerful debug method will be to use FreeRTOS+Trace.  Leave the trace recording running using a circular buffer, and have it stop when the error occurs (if that can be determined) so the trace buffer will show the behaviour of the tasks in the system at the time something was supposed to happen but didn’t.

Do you have stack overflow checking switched on?  If not, that could help too.

Regards.