임베디드 HMI가 정상적으로 시작되고, 인터페이스를 표시하며, 터치에 응답합니다. 유휴 타임아웃 후 화면이 어두워집니다. 다음 웨이크 이벤트로 시스템은 돌아오지만, LCD는 검은 상태로 유지됩니다. 장치를 재시작하면 화면이 복원됩니다.
이 고장은 오해하기 쉽습니다. 성공적인 콜드 부팅은 시스템이 하나의 시작 조건에서 화면을 생성할 수 있음을 보여줍니다. 그러나 패널, 디스플레이 컨트롤러, 백라이트, 소프트웨어가 모든 저전력 상태에서 복구될 수 있음을 보여주지는 않습니다.
유용한 질문은 다음과 같습니다: 디스플레이 시스템의 어느 부분이 작동 상태로 복귀하지 못했는가? LCD를 교체하거나 드라이버에 지연을 추가하기 전에 이 질문에 답하십시오. 이 가이드는 TFT LCD 모듈을 Linux 또는 Android 기반 HMI 시스템에 통합하는 OEM 팀을 위한 실용적인 조사 경로를 제공합니다.
1. 디스플레이가 정상적으로 부팅되지만 재개 후 실패할 수 있는 이유
콜드 부팅과 재개는 서로 다른 조건에서 시작됩니다. 시작 시 부트로더와 운영체제는 하드웨어를 단계적으로 초기화할 수 있습니다. 재개 중에는 일부 구성 요소가 상태를 유지하는 반면, 다른 구성 요소는 복원이 필요할 수 있습니다. 재개 경로는 이러한 차이를 고려해야 합니다.
예를 들어, 부트로더가 커널이 제어를 넘겨받기 전에 패널을 초기화할 수 있습니다. 커널이 해당 초기 구성에 의존하지만 전원 손실 후 이를 복원할 수 없다면, 첫 부팅은 정상으로 보이지만 이후 웨이크는 실패할 수 있습니다. 이를 실제 부트로더, 패널 드라이버, 보드 지원 패키지(BSP)와 대조하여 확인해야 할 가설로 취급하십시오.
Linux는 시스템 슬립과 런타임 전원 관리를 구분합니다. 시스템 슬립은 더 넓은 시스템의 상태를 변경합니다. 런타임 전원 관리는 시스템이 활성 상태를 유지하면서 개별 장치가 저전력 상태에 진입할 수 있게 합니다. 디스플레이 장치가 시스템 슬립 시작 전에 이미 서스펜드된 경우, 이들의 상호 작용이 중요합니다.[1]
성공적인 시작과 실패한 웨이크, 두 가지 캡처로 조사를 시작하십시오. 동작이 분기되는 지점을 비교하십시오. 누락된 레귤레이터 전환, 실패한 패널 명령, 또는 디스플레이 업데이트 부재는 “재개가 작동하지 않는다”는 진술보다 더 유용한 증거입니다.”
2. 실제로 무엇이 슬립에 진입했는지 식별
“슬립”은 제품 사양에서 종종 여러 가지 다른 동작을 설명합니다. 사용자는 동일한 검은 화면을 보지만, 엔지니어링 요구 사항은 상당히 다를 수 있습니다.
| 상태 또는 동작 | 확립해야 할 사항 | 중요한 이유 |
|---|---|---|
| 애플리케이션 블랭킹 | 애플리케이션이 검은 콘텐츠를 그렸는가, 아니면 인터페이스를 숨겼는가? | 디스플레이 하드웨어는 여전히 정상적으로 작동 중일 수 있습니다. |
| 백라이트 끔 | LED 조명만 중단되었는가? | 이미지 생성은 가시 조명 없이 계속될 수 있습니다. |
| 패널 저전력 상태 | 어떤 패널 명령, 전원 변경, 리셋 동작이 발생했는가? | 패널은 정의된 종료 시퀀스가 필요할 수 있습니다. |
| 디스플레이 서브시스템 런타임 서스펜드 | 어떤 컨트롤러, 브리지, 클록, 전원 리소스가 변경되었는가? | CPU가 활성 상태를 유지하는 동안 이미지 경로에 복원이 필요할 수 있습니다. |
| 시스템 서스펜드 | 어떤 플랫폼 슬립 상태에 진입했으며, 무엇이 이를 깨웠는가? | 고장이 디스플레이를 넘어선 시스템 복구와 관련될 수 있습니다. |
Linux는 suspend-to-idle 및 suspend-to-RAM을 포함한 여러 시스템 슬립 상태를 문서화합니다. 사용 가능한 상태와 그 동작은 플랫폼 지원에 따라 달라집니다. 제품의 화면 타임아웃만으로는 머신이 어느 상태에 진입했는지 입증되지 않습니다.[2]
실제 트리거를 기록하십시오: 애플리케이션 타임아웃, 운영체제 전원 정책, 물리 버튼, 예약 이벤트, 또는 수동 엔지니어링 테스트. 또한 웨이크 소스도 기록하십시오. 터치 이벤트가 시스템을 깨울 수 없지만 물리 버튼은 깨울 수 있다면, 그 결과를 이미지 복구 결함으로 취급하기 전에 웨이크 구성을 조사하십시오.
이 구분은 테스트 계획도 변경합니다. 백라이트 전용 디밍, 패널 전원 차단, 시스템 서스펜드는 별도의 테스트 케이스가 필요합니다. 이들을 하나의 “슬립/웨이크” 체크박스 아래에 결합하면 실패하는 전환을 숨길 수 있습니다.
3. 백라이트 고장과 이미지 고장 분리
펌웨어를 변경하기 전에 화면과 나머지 장치가 무엇을 하고 있는지 분류하십시오. 시리얼 콘솔이나 시스템 하트비트와 같은 적절한 독립 채널을 통해 호스트가 재개되었는지 확인하십시오. 네트워킹에도 복구가 필요한 경우 네트워크 접근만으로는 결론을 내리기 어려울 수 있습니다.
| 관찰된 증상 | 우선 확인 사항 | 보존할 증거 |
|---|---|---|
| 가시 조명 없음 | 백라이트 전원, 인에이블 신호, 밝기 명령, PWM 출력, 그리고 가능한 경우 드라이버 폴트 상태 | 슬립 전과 웨이크 후의 전원 및 제어 측정값 |
| 백라이트는 켜져 있지만 이미지가 나타나지 않음 | 패널 전원, 리셋, 초기화, 활성 디스플레이 모드, 이미지 출력 | 패널 드라이버 로그 및 관련 신호 캡처 |
| 이전 이미지가 정지 상태로 남음 | 애플리케이션 업데이트, 컴포지터 활동, 스캔아웃 상태, 지원되는 프레임 유지 모드 | 타임스탬프가 있는 콘텐츠 변경 및 디스플레이 업데이트 관찰 |
| 이미지는 돌아오지만 터치가 되지 않음 | 터치 컨트롤러 전원, 버스 통신, 인터럽트 동작, 드라이버 복구, 입력 전달 | 입력 이벤트 및 터치 드라이버 로그 |
| 호스트 복구의 독립적인 징후 없음 | 시스템 웨이크 및 디바이스 전원 관리 오류 | 실패한 전환에서의 시리얼 출력 또는 보존된 로그 |
이러한 점검은 조사 분기를 식별하며, 근본 원인을 입증하지는 않습니다. 백라이트가 켜져 있다고 해서 LCD가 초기화되었음을 입증하는 것은 아닙니다. 화면이 멈춰 있다고 해서 애플리케이션이 중단되었음을 입증하는 것은 아닙니다. 오래된 콘텐츠와 성공적인 업데이트를 구별하려면 의도적으로 변화하는 테스트 이미지를 사용하십시오.
투과형 LCD의 경우, 백라이트가 꺼진 상태에서 외부 조명 아래 세심하게 관찰하면 희미한 이미지가 드러날 수 있습니다. 긍정적인 관찰은 조명 경로를 분리하는 데 도움이 될 수 있습니다. 이미지가 보이지 않는 것은 광학 스택과 관찰 조건이 가시성에 영향을 미치므로 결정적이지 않습니다.
Linux는 백라이트 제어를 별도의 서브시스템으로 취급합니다. 해당 드라이버 인터페이스에는 밝기 업데이트와 선택적 서스펜드/리줌 처리가 포함됩니다. 따라서 소프트웨어 밝기 값은 조명의 증거로 받아들이기보다 하드웨어 출력과 비교해야 합니다.[3]
4. 전원, 리셋 및 패널 초기화 검토
다음 질문은 패널이 유효한 복구 시퀀스를 수신했는지 여부입니다. 정확한 LCD 모듈과 리비전에 대한 데이터시트 및 통합 지침을 사용하십시오. 모든 TFT LCD에 적용되는 보편적인 지연이나 명령 시퀀스는 없습니다.
측정된 동작을 요구되는 시퀀스와 비교
실패 이벤트 전후의 관련 패널 공급 레일, 리셋 신호 및 백라이트 인에이블을 캡처하십시오. 모듈 요구사항에 대해 이들의 레벨과 순서를 확인하십시오. 제조사가 명시한 최소 오프 시간 또는 방전 요구사항을 포함하십시오.
그런 다음 드라이버의 의도된 동작을 측정된 신호와 비교하십시오. “전원 활성화됨”이라는 로그는 소프트웨어 동작이 요청되었음을 확인할 뿐, 패널 커넥터의 전압을 입증하지는 않습니다. 업스트림 공급은 안정적으로 보이면서 로컬 레일은 전환 중에 다르게 동작할 수 있습니다.
어떤 상태가 유지되었는지 확인
패널 전원이 제거되었다면, 전원 복귀 후 모듈이 요구하는 초기화가 무엇인지 확인하십시오. 전원이 유지되었다면, 패널이 명령된 슬립 상태에 진입했는지 그리고 그 상태를 어떻게 벗어나야 하는지 확인하십시오. 패널 요구사항을 확인하지 않고 콜드 스타트 시퀀스를 리줌 시퀀스로 대체하지 마십시오.
Linux DRM 패널 헬퍼는 준비, 인에이블, 디스에이블 및 준비 해제를 구분합니다. 이러한 분리는 패널 전원과 가시적 출력이 관련되지만 별개의 작업으로 검토되어야 하는 이유를 보여줍니다. 벤더 BSP는 이러한 책임을 다르게 구현할 수 있으므로, 제품에 사용된 코드를 검사하십시오.[4]
지연 변경을 사용하여 가설 테스트
추가된 지연은 원인을 식별하지 않고도 실패를 줄일 수 있습니다. 지연이 도움이 되는 것으로 보이면, 이를 측정된 이벤트와 연관시키십시오: 레일 안정화, 리셋 해제, 명령 완료 또는 기타 문서화된 요구사항. 이전에 실패를 유발했던 조건에서 테스트를 반복하십시오.
엔지니어링 목표는 충분한 마진을 갖춘 정당화된 시퀀스입니다. 하나의 벤치 테스트를 통과한 지연은 양산 수정에 대한 충분한 증거가 아닙니다.
5. 디스플레이 링크 및 소프트웨어 복구 경로 확인
전원 및 리셋 동작을 이해한 후, 호스트에서 패널까지의 이미지 경로를 추적하십시오. 해당 경로의 각 부분을 복원하는 역할을 담당하는 구성 요소를 식별하십시오. 설계에서 액티브 브리지 또는 컨트롤러 보드를 사용하는 경우 이를 포함하십시오.
MIPI DSI: 초기화와 전송 비교
MIPI DSI 설계의 경우, 문서화된 패널 초기화와 복구 중 실제로 발행된 명령을 비교하십시오. BSP에 적용 가능한 대로 명령 오류와 DSI 호스트 및 PHY의 복원을 검토하십시오. 웨이크 후 예상 디스플레이 모드가 활성화되어 있는지 확인하십시오.
유용한 실험은 명령 복구와 콘텐츠 복구를 분리합니다. 패널 명령이 완료되지만 변화하는 테스트 이미지가 나타나지 않으면, 나머지 이미지 경로를 조사하십시오. 명령이 실패하면, 먼저 패널과 호스트가 통신할 준비가 되었는지 확인하십시오. 타임아웃을 결함 있는 LCD의 증거로 취급하지 마십시오.
LVDS: 리줌된 출력 구성 확인
LVDS의 경우, 복원된 타이밍, 클럭, 레인 배열 및 데이터 매핑을 알려진 작동 구성과 비교하십시오. 또한 모든 중간 컨트롤러를 검증하십시오. 콜드 부트가 작동하므로, 모든 초기 선택 결정을 재검토하기 전에 전환 중에 무엇이 변경되는지 조사하십시오.
브리지가 있는 경우, 선택된 슬립 상태에서 해당 구성이 유지되는지 확인하십시오. 호스트의 복구가 성공하더라도 다운스트림 디바이스는 구성되지 않은 상태로 남을 수 있습니다.
eDP: 연결 복구 검사
eDP의 경우, 가능한 경우 소스 드라이버의 AUX 통신 및 링크 트레이닝 결과를 보존하십시오. 실패한 복구 시도와 성공한 복구 시도를 패널 전원 및 리셋 측정과 함께 비교하십시오. 요구되는 복구 동작은 패널, 소스 및 상태 전환에 따라 달라집니다.
RJY의 eDP TFT LCD 패널 호환성 가이드 를 더 넓은 통합 검토에 활용하십시오. 이 조사는 이미 작동하는 구성이 슬립에 진입한 후 무엇이 실패하는지라는 더 좁은 질문을 다룹니다.
애플리케이션 복구 전에 드라이버 복구 확인
명령 프롬프트로 돌아온 보드가 반드시 그래픽 경로를 복원한 것은 아닙니다. 반대로, 작동하는 디스플레이 테스트 패턴이 정상 애플리케이션이 올바르게 재개되었음을 입증하지는 않습니다. 이러한 계층을 별도로 테스트하십시오.
Linux 디바이스 전원 관리는 콜백을 사용하여 디바이스 전환과 종속성을 조정합니다. 시스템이 재개되었다고 해서 모든 디바이스가 복구되었다고 가정하지 말고, 실제 드라이버 구현에서 오류와 순서를 검토하십시오.[5]
Android의 경우, 제공된 소프트웨어 이미지에서 디스플레이 서비스, 컴포지터, 애플리케이션 및 터치 입력의 동작도 비교하십시오. 필요한 변경은 보드 리비전과 BSP에 따라 달라집니다. 일반적인 인터페이스 일치는 소프트웨어 호환성을 입증할 수 없습니다.
6. 반복 가능한 서스펜드–리줌 테스트 매트릭스 구축
간헐적 실패는 조건이 반복 가능할 때 유용한 증거가 됩니다. 하나의 고정된 하드웨어 및 소프트웨어 구성으로 시작하십시오. 실패 경계가 더 명확해질 때까지 한 번에 하나의 변수를 변경하십시오.
| 테스트 변수 | 권장 범위 | 기록 |
|---|---|---|
| 전환 | 백라이트 오프/온, 패널 슬립/웨이크, 지원되는 런타임 서스펜드 및 지원되는 시스템 서스펜드 | 실제 진입한 상태 및 복구 결과 |
| 슬립 지속 시간 | 제품 사용과 관련된 짧은 및 긴 간격 | 정확한 지속 시간 및 관찰된 공급 동작 |
| 웨이크 소스 | 제품에 필요한 각 소스 | 시스템이 웨이크되었는지 그리고 이미지와 터치가 복귀했는지 여부 |
| 밝기 | 검증된 범위 내의 낮음, 중간, 높음 설정 | 요청된 밝기 및 측정된 제어 출력 |
| 애플리케이션 활동 | 정적 UI, 변화하는 그래픽, 대표 워크로드 | 첫 번째로 업데이트된 사용 가능 프레임까지의 시간 |
| 반복 사이클 | 프로젝트 검증 계획에 기반한 정의된 실행 길이 | 시도, 실패, 사이클 인덱스, 실패 유형 |
| 제품 조건 | 의도된 인클로저를 포함한 승인된 공급 및 환경 조건 | 조건 및 구성 차이 |
테스트 실행 전에 합격 기준을 정의하십시오. 의도된 이미지, 지속적인 업데이트, 필요한 경우 사용 가능한 터치, 정확한 밝기, 그리고 제품의 합의된 시간 제한 내에서의 복구를 포함해야 합니다. 해당 제한은 다른 디스플레이에서 숫자를 차용하지 말고 사용 사례에서 설정하십시오.
사이클이 실패하면 로그를 보존하십시오. 지원되는 경우, Linux 전원 관리 디버깅 기능이 시스템 서스펜드의 단계를 격리하는 데 도움이 될 수 있습니다. 해당 기능의 가용성과 적합성은 커널 구성 및 플랫폼에 따라 달라집니다.[6]
관찰된 결과를 정확하게 보고하십시오. 실패 없이 실행된 것은 해당 실행 중에 발생한 일을 입증할 뿐, 실패율이 0이라는 것을 입증하지는 않습니다. 제안된 수정 사항을 원래 재현기와 관련 제품 조건에 대해 재테스트하십시오.
7. 블랙 스크린 보고서를 유용한 엔지니어링 증거로 전환하기
“화면이 때때로 검은색으로 남아 있습니다”라는 말은 공급업체를 추측하게 만듭니다. 유용한 보고서는 증상을 알려진 구성 및 반복 가능한 전환과 연결합니다.
예시 보고서 형식이며, 제품 테스트 결과가 아닙니다: LCD는 콜드 부팅 후 정상적으로 작동합니다. 지정된 시스템 서스펜드 간격 후, 물리적 웨이크 버튼이 시리얼 콘솔을 복원합니다. 백라이트는 켜지지만, 변화하는 테스트 이미지가 돌아오지 않습니다. 실패 횟수와 사이클 인덱스를 기록하십시오. 정확한 패널 모델, 보드 리비전, BSP 버전, 전환 로그, 동기화된 전원/리셋 캡처를 첨부하십시오. 애플리케이션 재시작, 지원되는 디스플레이 리셋, 또는 전체 장치 재시작이 작동을 복원하는지 여부를 기록하십시오.
복구 실험을 별도로 기록하십시오. 애플리케이션 재시작, 디스플레이 경로 재초기화, 패널 전원 사이클링은 서로 다른 경계에 영향을 미칩니다. 성공적인 실험은 조사 범위를 좁히지만, 무엇을 변경했는지 이해하지 못한 채 영구적인 수정이 되어서는 안 됩니다.
디스플레이 및 컨트롤러 검토를 위해 LCD 데이터시트, 커넥터 정의, 터치 컨트롤러 세부 정보, 보드 구성, 소프트웨어 버전, 의도된 저전력 동작을 제공하십시오. RJY의 TFT LCD 및 Android 컨트롤 보드 매칭 가이드 는 더 넓은 선택 요구 사항을 다룹니다.
가장 강력한 핸드오프는 작동 기준선과 실패한 복구를 모두 포함합니다. 이러한 비교는 패널, 보드, 소프트웨어 팀이 “슬립”에 대한 서로 다른 해석을 테스트하는 대신 동일한 이벤트를 조사하는 데 도움이 됩니다.”
8. FAQ
성공적인 콜드 부팅이 LCD가 서스펜드 및 리줌을 지원한다는 것을 입증합니까?
아닙니다. 콜드 부팅은 하나의 시작 경로를 검증합니다. 서스펜드 및 리줌은 제품에 필요한 정확한 패널, 보드, 소프트웨어 이미지, 저전력 상태에 대해 테스트해야 합니다.
장치를 재시작하면 블랙 스크린이 해결된다면, 문제가 확실히 소프트웨어입니까?
아닙니다. 재시작은 소프트웨어 상태를 변경하고, 하드웨어를 리셋하며, 전원 또는 초기화를 복원할 수 있습니다. 유용한 진단 관찰이지만, 그 자체로 근본 원인을 식별하지는 않습니다.
LCD 이미지가 돌아오더라도 리줌 후 터치가 실패할 수 있습니까?
예. 터치에는 자체 컨트롤러와 복구 종속성이 있습니다. 이미지 경로와 별도로 전원, 통신 인터페이스, 인터럽트 동작, 드라이버 복구, 입력 이벤트를 확인하십시오.
모든 TFT LCD가 웨이크 후 동일한 리셋 지연을 사용해야 합니까?
아닙니다. 정확한 모듈 및 드라이버 IC에 대한 요구 사항과 보드 구현을 함께 사용하십시오. 보편적인 지연을 적용하는 대신 문서와 측정을 통해 시퀀스를 확인하십시오.
OEM이 디스플레이 복구 검토를 위해 어떤 정보를 제공해야 합니까?
패널 모델 및 데이터시트, 보드 리비전, 소프트웨어 버전, 실제 슬립 상태, 웨이크 소스, 재현 단계, 실패 횟수, 로그, 사용 가능한 전원, 리셋, 백라이트 측정값을 제공하십시오.
RJY와 디스플레이 복구 요구 사항 논의하기
RJY Display는 컨트롤러 보드 적응 및 프로젝트 의존적 펌웨어 지원을 포함한 TFT LCD 프로젝트를 지원합니다. 임베디드 HMI의 경우, 디스플레이 및 컨트롤러 보드 요구 사항을 제출하십시오 예상 슬립 및 웨이크 동작과 함께. 호환성 및 적응 범위는 특정 패널, 보드, 터치 구성, 소프트웨어 환경에 대해 검토해야 합니다.
참고 자료
아래의 Linux 소스는 업스트림 프레임워크를 설명합니다. 제품에 사용된 커널 버전 및 벤더 BSP에 대한 적용 가능성을 확인하십시오. 진단 표와 보고서 형식은 제안된 엔지니어링 방법이며, 보고된 RJY 테스트 결과가 아닙니다.