로깅 및 크래시 분석¶
로그는 일시적인 디버깅 편의 기능이 아니라 제품의 일부입니다. 좋은 로그는 보드 브링업(초기 구동 및 검증), 현장 디버깅, 양산 단계의 원인 분석에 걸리는 시간을 줄여 줍니다.
첫 현장 테스트 전에 로깅을 설계하십시오. 디바이스가 현장에서 고장 난 뒤에는, 펌웨어가 미리 저장하거나 출력하도록 준비해 둔 데이터만 얻을 수 있습니다.
최소 로깅 구성¶
모든 펌웨어 빌드에 대해 다음을 기록하십시오.
- 펌웨어 버전.
- SDK 브랜치 또는 커밋.
- 보드 이름과 리비전.
- 부팅 원인.
- 파티션 레이아웃 버전.
- 주요 서브시스템 초기화 결과.
- 부팅에 실패한 경우 크래시/어서트 출력.
크래시 분석 흐름¶
- 검증된 정상 기준 구성이 있는 보드에서 문제를 재현합니다.
- 리셋 시점부터 전체 부트 로그를 캡처합니다.
- 정확한 바이너리와 심볼을 저장합니다.
- SiFli 도구로 어서트 또는 덤프 출력을 디코딩합니다.
- 스택 크기, 메모리 소유권, DMA 버퍼, 캐시 관리를 확인합니다.
- 가장 가깝게 일치하는 SDK 예제를 사용하여 문제 범위를 좁힙니다.
로그 레벨¶
표: 로그 레벨
| 단계 | 권장 로깅 |
|---|---|
| 보드 브링업 | 주변 장치 및 부트에 대한 상세 로그. |
| 기능 개발 | 테스트 중인 기능 주변의 모듈 단위 디버그 로그. |
| 전력 튜닝 | 로그를 최소로 유지합니다. 로깅 자체가 전력 특성에 영향을 줍니다. |
| 릴리스 후보 | 경고, 오류, 버전, 부팅 원인, 주요 상태 점검. |
| 현장 진단 빌드 | 문제가 의심되는 서브시스템을 중심으로 한 로그. |
좋은 크래시 리포트의 조건¶
- 리셋부터 크래시까지의 전체 로그가 포함되어 있습니다.
- 정확한 바이너리를 식별할 수 있습니다.
- 심볼 파일 또는 재현 가능한 빌드가 포함되어 있습니다.
- 수정하지 않은 SDK 예제에서도 크래시가 발생하는지 명시합니다.
- 연결된 주변 장치와 전원 공급원이 나열되어 있습니다.
- 플래시 전체 삭제 후 다시 기록해도 크래시가 지속되는지 명시합니다.
최종 업데이트: