Как определить, какая задача мертва?

Question

У меня есть встроенная система, которая имеет несколько (> 20) задач, работающих под разными приоритетами. У меня также есть задача сторожевого таймера, которая выполняется, чтобы проверить, что все остальные задачи не застревают. Мой сторожевой таймер работает, потому что каждый раз в синей луне он перезагружает систему, потому что задача не проверяется.

Как определить, какая задача умерла?

Я не могу просто обвинить самую старую задачу, чтобы выгнать сторожевого таймера, потому что она могла быть удержана задачей более высокого приоритета, которая не уступает.

Любые предложения?

Answer 1

А на-задачи сторожевого требует, чтобы более высокие приоритетные задачи дают адекватного времени, так что все может пнуть сторожевой пес. Чтобы определить, какая задача виновата, вам придется найти того, кто голодает на других. Вам нужно будет измерить время выполнения задачи между проверками сторожевого таймера, чтобы найти фактического виновника.

Answer 2

Является ли это упреждающим? Я так понимаю, так как иначе задача сторожевого пса не будет работать, если кто-то из них застрянет.

Вы не упоминаете ОС, но если задача сторожевого таймера может проверить, не была ли проверена одна задача, должны быть отдельные каналы связи между каждой задачей и сторожевым таймером.

Возможно, вам придется изменить сторожевой таймер, чтобы каким-то образом сбросить номер задачи, который не был отмечен в , и сбрасывать блоки управления и память задач, чтобы вы могли сделать посмертное.

В зависимости от ОС это может быть легко или сложно.

Answer 3

В зависимости от вашей системы и ОС могут быть разные подходы. Один очень низкий подход, который я использовал, - это мигать светодиодом, когда выполняется каждая из задач. Вам может потребоваться установить область на светодиодах, чтобы увидеть очень быстрое переключение задач.

Answer 4

Для сторожевого таймера, управляемого прерываниями, вы просто устанавливаете переключатель задач в текущем запущенном номере задачи каждый раз, когда он изменяется, что позволяет вам определить, какой из них не уступил.

Однако вы предлагаете вам написать сторожевой таймер как задачу самостоятельно, поэтому перед перезагрузкой наверняка сторожевой таймер может идентифицировать голодную задачу? Вы можете сохранить это в памяти, которая сохраняется за пределами теплой перезагрузки или отправляет ее через интерфейс отладки. Проблема в том, что голодная задача, вероятно, не проблема: вы, вероятно, захотите узнать последние несколько переключателей задач (и раз), чтобы определить причину.

Answer 5

Упрощенная, задняя часть салфетку подход будет что-то вроде этого:

int8_t wd_tickle[NUM_TASKS] 

void taskA_main() 
{ 
    ... 
    // main loop 
    while(1) { 
    ... 
    wd_tickle[TASKA_NUM]++; 
    } 
} 

... tasks B, C, D... follow similar pattern 

void watchdog_task() 
{ 
    for(int i= 0; i < NUM_TASKS; i++) { 
    if(0 == wd_tickle[i]) { 
     // Egads! The task didn't kick us! Reset and record the task number 
    } 
    } 
} 

Answer 6

Даже я работал последние несколько недель на проблеме сброса сторожевого таймера. Но, к счастью для меня, в файлах ramdump (в среде разработки ARM), у которой есть один буфер трассировки обработчика прерываний, содержащий ПК и SLR на каждом из прерываний. Таким образом, из буфера трассировки я мог точно узнать, какая часть кода была запущена до сброса WD.

Я думаю, что если у вас есть такой же механизм хранения ПК, SLR на каждом прерывании, то вы можете точно узнать задачу преступника.

Answer 7

Как работает ваша система? Я всегда использую комбинацию программных и аппаратных сторожевых устройств. Позволь мне объяснить...

В моем примере предполагается, что вы работаете с упреждающим ядром реального времени, и у вас есть поддержка сторожевого таймера в вашем CPU/микроконтроллере. Этот сторожевой таймер выполнит сброс, если его не ударят с определенным периодом времени. Вы хотите проверить две вещи:

1) Выполняется периодический системный таймер («часы RTOS») (если нет, функции, подобные «sleep», больше не будут работать, а ваша система непригодна).

2) Все темы могут работать в течение разумного периода времени.

My RTOS (www.lieron.be/micror2k) предоставляет возможность запускать код в обработчике прерываний часов RTOS. Это единственное место, где вы обновляете аппаратный сторожевой таймер, поэтому вы уверены, что часы работают все время (если не сторожевой коммутатор не сбросит вашу систему).

В незанятом потоке (всегда работает с наименьшим приоритетом) обновляется «сторожевой таймер». Это просто устанавливает переменную в определенное значение (например, 1000). В прерывании часов RTOS (где вы запускаете сторожевой таймер) вы уменьшаете и проверяете это значение. Если он достигает 0, это означает, что простаивающий поток не запускался для 1000 тактов таймера, и вы перезагружаете систему (это можно сделать путем бесконечного цикла в обработчике прерываний, чтобы перезагрузка аппаратного сторожевого таймера).

Теперь для вашего оригинального вопроса. Я предполагаю, что системные часы продолжают работать, поэтому это программный сторожевой таймер, который сбрасывает систему. В обработчике прерываний часов RTOS вы можете выполнить некоторую «сборку статистики» в случае возникновения ситуации сторожевого таймера. Вместо сброса системы вы можете увидеть, какой поток работает на каждом такте (после возникновения проблемы) и попытаться выяснить, что происходит. Это не идеально, но это поможет.

Другой вариант - добавить несколько программных сторожевых устройств с разными приоритетами. Пусть холостой поток задает VariableA до 1000 и имеет (выделенный) поток приоритетов среднего уровня. Переменная B. В обработчике прерываний часов RTOS вы проверяете обе переменные. С помощью этой информации вы знаете, имеет ли поток цикла более высокий приоритет, чем «средний» или ниже «средний». Если вы хотите, вы можете добавить третье или четвертое или сколько программных сторожевых плееров вам нравится. В худшем случае добавьте сторожевой таймер для каждого используемого приоритета (будет стоить вам столько дополнительных потоков, хотя).