ISR + RTOS na Prática com FreeRTOS

Erros comuns, sintomas e estratégias de debug em ISR + FreeRTOS

Mesmo seguindo a documentação, muitos problemas envolvendo ISR + FreeRTOS só aparecem em tempo de execução, sob carga real, com múltiplas interrupções concorrentes. Esta seção conecta os conceitos anteriores aos sintomas reais observados em campo e apresenta estratégias práticas de depuração.

7.1 Sintoma: sistema “congela” aleatoriamente

Causa típica

• ISR chamando API do FreeRTOS com prioridade inválida
• Uso de API normal (xQueueSend) dentro de ISR
• Corrupção silenciosa do kernel

Diagnóstico

• Travamento sem HardFault
• Watchdog dispara
• Sistema “para” após alguns minutos ou horas

Ação corretiva

• Verificar prioridades NVIC
• Confirmar uso exclusivo de APIs FromISR
• Conferir configMAX_SYSCALL_INTERRUPT_PRIORITY

7.2 Sintoma: eventos perdidos ou atrasados

Causa típica

• Uso de semáforo binário para eventos frequentes
• Task associada com prioridade baixa
• ISR correta, mas task nunca executa a tempo

Diagnóstico

• Interrupção ocorre (confirmada no osciloscópio)
• Task demora ou não responde
• Logs mostram eventos “pulando”

Ação corretiva

• Migrar para Task Notifications ou Queue
• Ajustar prioridade da task
• Reduzir carga da task receptora

7.3 Sintoma: jitter elevado em tarefas de controle

Causa típica

• ISR longa
• Processamento dentro da interrupção
• Uso excessivo de HAL em ISR

Diagnóstico

• Oscilação no período de execução
• Controle instável
• Análise temporal mostra variação de latência

Ação corretiva

• Aplicar Deferred Interrupt Processing
• Mover lógica para task dedicada
• Medir tempo de ISR com GPIO de debug

7.4 Uso de GPIO para análise temporal (técnica profissional)

Uma técnica simples e extremamente eficaz é marcar entradas e saídas de ISR e tasks com GPIO.

Exemplo:

void TIM_IRQHandler(void)
{
    DEBUG_GPIO_SET();

    vTaskNotifyGiveFromISR(taskHandle, &xHigherPriorityTaskWoken);

    DEBUG_GPIO_CLEAR();
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void TIM_IRQHandler(void)
{
    DEBUG_GPIO_SET();

    vTaskNotifyGiveFromISR(taskHandle, &xHigherPriorityTaskWoken);

    DEBUG_GPIO_CLEAR();
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Com um osciloscópio ou analisador lógico, é possível medir:

• Tempo de ISR
• Latência ISR → Task
• Jitter
• Prioridades efetivas

Essa técnica é amplamente usada em sistemas industriais e automotivos.

7.5 Assertivas do FreeRTOS: aliadas, não inimigas

Habilite sempre:

#define configASSERT(x) if ((x) == 0) taskDISABLE_INTERRUPTS(), for(;;);

#define configASSERT(x) if ((x) == 0) taskDISABLE_INTERRUPTS(), for(;;);

E mantenha:

• configCHECK_FOR_STACK_OVERFLOW
• configUSE_TRACE_FACILITY

Esses recursos:

• Detectam uso incorreto de API
• Apontam erros de prioridade
• Facilitam debug precoce

7.6 Anti-padrões clássicos (resumo rápido)

Evite sempre:

• ISR com printf
• ISR com malloc
• ISR com HAL bloqueante
• ISR chamando funções de aplicação
• ISR “inteligente”

ISR não é thread, não é task, não é loop de controle.

7.7 Mentalidade correta: ISR como fronteira de tempo real

Em projetos profissionais, a ISR é tratada como:

• Fronteira temporal
• Interface entre hardware e software
• Elemento crítico de previsibilidade

Quando essa mentalidade é adotada, o FreeRTOS deixa de ser “difícil” e passa a ser extremamente previsível e confiável.