I have a question regarding the vApplicationTickHook function:

Context: Atmel EVK1100 with AT32UC3A0512, FreeRTOS and lwIP.

I've had the idea to use this function for toggling my watchdog timer . Further I would like to notify a task from the vApplicationTickHook function in case of certain events. Therefor I want to write to a queue. Problem: is this function a ISR and I therefore need to use xQueueSentToBackFromISR or not?

Thanks. Regards Mathias

Yes - you need to use the "FromISR" version.

Also, consider carefully how you use the tick to clear the watchdog. It is possible for your application to crash but the tick to continue. A common method is have the tick run some form of sanity check on each critical task to ensure the task is not only still running, but is also doing the right thing.

Regards.

Thanks for your answer Richard. I wasn't sure about this point.

In my application I am using a task supervision functionality additionally to the watchdog timer , too:

For task supervision I implemented an extra task. It periodically sends keep alive requests to the other tasks. Therefor every task has a queue and must send a reply to the supervision task's queue within a certain time (some of the tasks can block on their queue others need to poll it depending on their purpose). The tick hook function counts up a task local timer variable which gets reset by the supervision task upon the reception of every valid keep alive reply. If one reply is missing and the counter exceeds a limit the hook function sends a reset request to the supervision task's queue.

As far as I see this works quite fine although I have the problem that I can't supervise all tasks with this system. E.g. I have a network communication task which uses a blocking select on data reception. I am unable to let it listen to an additional keep alive queue...

Do you see an alternative/better solution where I could supervise all my tasks? What kind of sanity check are you thinking of?

Always appreciate your valuable inputs!

One way to use this system to monitor a task that blocks too long waiting on another queue, is to define a message for the queue it is blocking on that it will detect as this keep-alive request.

A second way is to put an timeout limit on the queue request that it is blocking on (less than the maximum time it has to respond to the keep-alive), and check if the request timed out, and if so it only needs to check for the keep-alive request, and not processes the data packed that didn't arrive