Usando WDT para detectar código travado em sistema embarcado, especificamente STM32

Assumindo uma arquitetura de "super-loop" de primeiro/segundo plano, com manipuladores de interrupção e um único thread principal, então eu sugeriria que um método melhor seria implementar tempos limite para cada interrupção.

Por exemplo, supondo que você implementou uma interface básica de tick do sistema (usando SYSTICK no Cortex-M), com uma função tickms()retornando o tempo decorrido em milissegundos. Então, para cada interrupção sendo watch-dogged, você pode ter uma enumeração como:

typedef enum
{
    WDG_UART1,
    WDG_UART2,
    WDG_TIMER1,
    ...
    NUMBER_OF_WDG
} eWdg ;

Então uma matriz como:

volatile struct
{
    unsigned period ;
    unsigned timestamp ;
} wdg[NUMBER_OF_WDG] =
{
    {1000, 0}, // WDG_UART1
    {1000, 0,  // WDG_UART2
    {100,  0}  // WDG_TIMER1
    ...
}

e uma API:

void wdgReset( eWdg wdg_id )
{
    wdg[wdg_id].timestamp = tickms() ;
}

void wdgCheck()
{
    for( int i = 0; i < NUMBER_OF_WDG; i++ )
    {
        while( tickms() - wdg[i].timestamp > wdg[i].period )
        {
            // spin while timeout expired until 
            // interrupt recovers or hardware watchdog
            // fires
        }
       
        resetHwWatchdog() ;
    }
}

Então, cada interrupção redefine seu tempo limite via wdgReset(), e o loop principal verifica continuamente os watchdogs de software, assim:

int main()
{
    for(;;)
    {
        // do any background processing here
        backgroundTasks() ;

        // Check interrupts
        wdgCheck()
    }
}

Então:

• se o thread principal parar, o watchdog de hardware será acionado,
• se alguma interrupção parar, o watchdog de hardware será acionado,
• se uma interrupção parar de disparar, o wdgCheck()irá girar e o watchdog de hardware irá disparar,
• se tudo estiver funcionando normalmente, os watchdogs de software serão redefinidos e o watchdog de hardware será atendido por wdgCheck(),
• cada tarefa ou interrupção tem seu próprio período específico adequado à sua taxa esperada na aplicação.

Observação: no Cortex-M, você pode emitir uma redefinição de software por meio do NVIC, portanto, você pode, opcionalmente, redefinir imediatamente quando o watchdog de software expirar, em vez de esperar pelo watchdog de hardware.

Claramente, este é apenas um esboço de pseudocódigo e puramente ilustrativo - ele poderia ser refinado e estendido de várias maneiras. Se você fosse usar um RTOS, você poderia proteger tarefas de forma semelhante, com o supervisor no loop ocioso ou em uma tarefa com prioridade menor do que qualquer outra.

Um refinamento que eu sugeriria seria ter um registro dinâmico de watchdogs de software em vez de uma matriz estática e ter uma API:

tWdgHandle wdgCreate( unsigned period ) ;

por exemplo, para que tarefas e drivers de dispositivo possam adicionar seus próprios watchdogs de forma independente, e wdgCheck()iterariam todos os manipuladores registrados. Uma tarefa poderia até mesmo modificar o período dinamicamente conforme necessário (se fosse temporariamente desabilitada, por exemplo):

void wdgSetPeriod( tWdgHandle wdg, unsigned period ) ;

Primeiramente, observe que se nenhuma tarefa puder ser travada, o método mais simples é simplesmente configurar o watchdog timer de hardware adequadamente, já que uma reinicialização brusca do MCU é uma maneira aceitável de lidar com erros.

Você só precisa de supervisão de software nos seguintes casos:

• Em caso de erro, você deseja parar e encerrar o programa graciosamente, relatando erros etc. antes de fazer uma reinicialização do MCU, ou
• Certas tarefas são consideradas menos críticas, mesmo quando estão suspensas, ou
• Você está implementando algum tipo de "limp home", ou seja, relatar erros, mas tenta executar o programa da melhor forma possível, mesmo em caso de erros (ou seja, algum tipo de produto de missão crítica).

Para simplificar, vamos supor que cada tarefa tenha permissão para consumir no máximo x ms, sem timeouts individuais. O pseudocódigo pode se parecer com isto:

typedef err_t task_t (void);  // function template for tasks


void main (void)
{
  /* init everything here */


  static task_t* const task[] = 
  {
    /* misc tasks in turn calling the drivers */
    uart_task,
    lcd_task,
    buttons_task,
  };

  state_t state = UART_STATE; // in case the list of tasks is also some manner of state machine

  for(;;)
  {
    kick_dog(); // refresh the hardware WDG here, and only here

    err_t result = OK;
    timer_start(n_milliseconds); // some fixed timeout shorter than hw WDG timeout
      do // busy-wait polling
      {
        result = task[state](); // non-blocking call polling something in turn
      } while(!timer_timeout() && result==ERR_BUSY);
    timer_stop();

    // here result is either OK, ERR_BUSY meaning timeout, or some other error code

    state = error_handler(result); // all error handling and state changes in the program here
  }
}

Em alguns sistemas, você também poderá alternar entre os modos seguro e operacional e talvez reverter para o modo seguro em caso de erros.