Debug Avançado: Bootloader, Dual-Core, SWO/ITM, Semihosting e Estratégias para Produção
Agora entramos no nível que normalmente só aparece quando o projeto cresce: bootloaders próprios, microcontroladores dual-core como STM32H7, necessidade de tracing em tempo real (SWO/ITM) e depuração de firmware já em campo (produção/IoT). Aqui o GDB deixa de ser apenas “parar e olhar variável” e passa a ser ferramenta estratégica.
5.1 Depuração de Bootloader (vetor de interrupção e salto para aplicação)
Em STM32, o boot ocorre a partir do vetor em 0x08000000 (ou outro endereço, dependendo do layout). Em sistemas com bootloader + aplicação, você normalmente tem:
- Bootloader em 0x08000000
- Aplicação em 0x08008000 (exemplo)
Problema clássico
A aplicação não inicia após o salto do bootloader.
Diagnóstico com GDB
Primeiro, verifique o vetor da aplicação:
x/2xw 0x08008000
Primeira palavra → Stack inicial
Segunda palavra → Reset_Handler da aplicação
Agora verifique se o bootloader está realmente carregando esses valores:
break jump_to_application
continue
Quando parar:
step
info registers
Verifique se:
$spfoi atualizado corretamente$pcfoi alterado para o Reset_Handler da aplicação
Se o stack pointer não for ajustado antes do salto, o firmware pode entrar em HardFault imediatamente.
Técnica avançada
Você pode forçar execução diretamente na aplicação:
set $sp = *(uint32_t*)0x08008000
set $pc = *(uint32_t*)0x08008004
continue
Isso valida se o problema está no bootloader ou na aplicação.
5.2 Debug em STM32 Dual-Core (ex: STM32H7)
Nos dispositivos dual-core (M7 + M4), cada core possui:
- Seu próprio vetor
- Sua própria stack
- Seu próprio contexto
OpenOCD permite selecionar core alvo.
No GDB:
monitor targets
Você verá algo como:
- target 0: Cortex-M7
- target 1: Cortex-M4
Para selecionar:
monitor target 1
Depois continue depuração normalmente.
Problema típico
Um core trava esperando handshake do outro.
Você pode:
- Pausar ambos cores
- Verificar registradores de IPC
- Inspecionar memória compartilhada
Isso é essencial quando trabalha com arquiteturas heterogêneas.
5.3 Semihosting
Semihosting permite que o firmware use chamadas que são tratadas pelo debugger (ex: printf via host).
Ativar no OpenOCD:
monitor arm semihosting enable
Agora chamadas como printf() podem aparecer no console do GDB.
Atenção
Semihosting pausa o core enquanto comunica com host → não é adequado para tempo real crítico.
Use apenas para debug inicial.
5.4 SWO e ITM (Tracing em tempo real)
SWO (Serial Wire Output) permite envio de dados de debug sem parar o core.
ITM (Instrumentation Trace Macrocell) é o mecanismo interno do Cortex-M.
Isso é muito superior a printf tradicional.
Com OpenOCD configurado para SWO, você pode capturar mensagens ITM enquanto o firmware roda.
Isso permite:
- Log em tempo real
- Medição de eventos
- Debug sem breakpoints
É a forma profissional de instrumentação leve.
5.5 Debug de firmware já em produção
Em sistemas IoT ou dispositivos já instalados:
Problemas comuns:
- Watchdog resetando sistema
- Corrupção intermitente
- Falha após horas de execução
Estratégia profissional
- Habilitar captura de registradores de fault em RAM persistente
- Ao reiniciar, ler valores via GDB:
x/8xw 0x2001FF00
- Analisar PC salvo
Você pode ainda usar:
bt
se sistema não reiniciou completamente.
5.6 Debug de sistema com Watchdog
Se o watchdog reinicia rápido demais:
Conecte e:
monitor reset halt
break main
continue
Desabilite watchdog manualmente via registrador:
set {uint32_t}IWDG_KR = 0x0000AAAA
Isso permite depuração antes do reset.
5.7 Estratégias para sistemas OTA
Em firmware com atualização OTA:
Problema típico: nova imagem não inicia.
Diagnóstico:
- Verificar CRC da imagem
- Verificar vetor da nova imagem
- Confirmar salto correto
Você pode validar via GDB lendo diretamente a Flash:
x/64xw 0x08020000
5.8 Debug sem parar o sistema (modo observacional)
Nem sempre você pode usar breakpoints (sistemas críticos).
Alternativas:
- ITM trace
- SWO
- Leitura periódica de registradores
- Watchpoints seletivos
Evitar continue com breakpoints frequentes em sistemas com controle de motor, por exemplo, pois pode causar comportamento instável.
5.9 Técnicas de Engenharia de Depuração
Aqui está a mentalidade correta:
Depuração embarcada não é:
“Vou colocar printf até funcionar”
É:
- Hipótese clara
- Medição objetiva
- Validação via registrador/memória
- Isolamento da causa
Sempre valide:
- Clock
- Stack
- Vetor de interrupção
- Estado de periférico
- Registradores de fault
Encerramento Técnico
Neste material nós cobrimos:
- Setup completo GDB + OpenOCD
- Todos comandos fundamentais
- Breakpoints e watchpoints
- Inspeção de memória e registradores
- Debug de HardFault
- Debug com FreeRTOS
- Debug de periféricos
- Automação via macros
- Bootloader
- Dual-core
- SWO/ITM
- Estratégias para produção
Se você dominar tudo isso, você não depende de IDE. Você controla o sistema no nível do silício.
