Resposta direta
Uma atualização robusta precisa de um caminho definido para recuperar um equipamento capaz de inicializar. Antes de implementar a transferência, decida o que deve acontecer se faltar energia durante apagamento, gravação, verificação ou ativação da nova imagem.
Diferencie o bootloader de sistema do processo do produto
O bootloader de sistema integrado ao STM32 e um bootloader de produto não necessariamente cumprem a mesma tarefa. Interfaces e condições de entrada dependem do componente; a ST as descreve na AN2606. Confira o código exato, não apenas a família. STMicroelectronics — AN2606
Um programador pode resolver a manutenção na bancada e ficar inacessível depois da instalação. Descreva quem poderá acessar o equipamento com falha e qual conexão continuará disponível. Essa situação define as necessidades reais de recuperação e manutenção.
Calcule a memória antes de escolher a arquitetura
Considere bootloader, aplicação, configuração e espaço de trabalho. Reserve uma margem justificada para a evolução do programa. A possibilidade de manter duas imagens internas ou a necessidade de memória externa precisa ser calculada para o microcontrolador escolhido.
O MCUboot descreve, entre outras opções, inicialização de teste com confirmação e retorno à imagem anterior. É uma arquitetura possível, não uma propriedade automática de qualquer projeto STM32. É necessário conferir implementação e requisitos de memória. MCUboot — Bootloader design
Ative a imagem somente após verificá-la
Separe os estados: recebida, verificada, iniciada para teste e confirmada. O fim do download não deve, sozinho, autorizar a execução. Verifique compatibilidade com o hardware, tamanho permitido, versão e integridade da imagem.
Uma soma de verificação detecta determinados erros de transmissão, mas não comprova uma origem confiável. Se a análise de ameaças exigir, planeje verificação criptográfica de assinatura com uma raiz de confiança protegida. Gestão de chaves e autorização de versões passam a fazer parte do processo do produto.
Reproduza falhas em diferentes etapas
Interrompa a alimentação em vários pontos e registre o estado após religar. Teste também uma imagem incompleta, identificação de hardware incorreta e uma aplicação que inicializa, mas não passa em sua verificação de funcionamento.
Um critério de aceitação pode ser: após cada interrupção definida, a versão anterior aprovada inicializa ou fica disponível um procedimento documentado de recuperação. A possibilidade de reiniciar automaticamente depende da função do equipamento; não é apropriada por padrão para todas as aplicações.
Conteúdo do plano de atualização
- Modelo do MCU, revisão de hardware e cálculo de memória.
- Caminho de recuperação acessível e condições de uso.
- Estados da imagem e regras de confirmação da inicialização.
- Migração dos dados de configuração entre versões.
- Resultados dos testes de falta de energia com identificação do firmware.
Perguntas frequentes
Dois bancos de Flash são suficientes?
Não. Também são necessários sequência correta, dados de estado consistentes e uma decisão de inicialização verificada. As características da Flash dependem do componente.
Todo produto precisa de atualização OTA?
Não. Uma interface local de manutenção pode ser adequada. A escolha depende de acesso, custo de parada, procedimento de serviço e requisitos de autenticidade do firmware.
Fontes técnicas
Serviço relacionado