(포스팅 2022.08.09)
- 목차
의문의 시작
전원 인가에 의한 부팅 과정
강제 리셋에 의한 부팅 과정
강제 리셋시 발생하는 문제 대응 방법
마치며
지금은 자주 발생하는 일이 아니지만, 스마트폰을 사용하다보면 먹통이 되는 경우가 있습니다. 먹통이 된 휴대폰을 강제로 재부팅시키기 위해 작은 구멍을 핀으로 눌러주었습니다.
이 Reset Pin 은 보통 AP의 Reset 핀에 연결되어 있습니다. AP가 멈추거나 이상동작할때 reset 시그널을 주어서 강제 reset 시킵니다. 회로 또한 아래의 이미지처럼 단순하고 간단합니다.
이 이야기를 꺼내는 이유는, 이렇게 회로를 구성하여 RST 단자에 신호를 주는 것만으로 시스템이 재부팅한다고 생각하시는 분이 있어서입니다. 예를 들면 "RESET 신호만 주면 시스템이 리셋될텐데 무슨 추가작업이 필요하다는 거지?"라고 말씀하시거나 "RESET 신호를 주었는데 시스템이 리셋되지 않으니 설계가 잘못되었다"고 주장하시는 분들이 있습니다.
모든 AP는 자신의 초기화 상태가 정의되어 있습니다.
AP는 전원이 들어오면, 자신의 기본 회로를 점검하고 메모리 특정 번지에서 값을 가져와서 해석하기 시작합니다. 처음 부팅할때 읽어들이는 부트로더에는 시스템이 사용하기 위한 클럭 및 메모리 셋팅이 들어있습니다. 필요한 셋팅이 끝나고 외부로 연결되는 최소한의 통신 (디버그포트)을 확보한 후, 2차 부트로더나 OS로 제어권을 넘깁니다.
AP는 Reset Pin에서 신호를 받으면, 전원을 처음 받았을 때와 같이 초기화됩니다. 이러한 과정은 Reset이 발생하기 전에 어떤 과정을 거치는 것이 아니고, HW 회로에 의해 강제로 진행됩니다. Reset 후에 AP의 상태는 전원이 처음 인가되었을 때의 상태와 동일합니다.
AP는 Reset되어 초기 상태가 되었습니다만, AP를 제외한 외부의 회로들은 여전히 동작중인 상태입니다. 이러한 외부 회로 중에 AP가 직접 컨트롤하는 PMIC / RAM 등은 문제가 없습니다만, 그 외의 회로는 오작동을 하게 됩니다.
회로 종류 | AP Reset 시 오동작의 예 |
PMIC / RAM / EMMC | 보통은 문제가 없이 동작함 |
Display | 화면 frame이 완전히 전송되지 못한 상태에서 신호가 끊김. 완전히 먹통이 된다거나, 화면이 펄럭거리거나 함. 운이 좋으면 한두프레임 지직거리고 회복됨. |
Audio | 일정하게 공급되던 PCM data 가 멈춤. 버퍼에 있는 소리가 반복 재생되면서 '지지지지지지' 하는 소리가 계속 발생. |
센서류 | 프로토콜이 단순하여 문제가 적게 발생함. |
정리하면, AP에 Reset 신호를 주는 것만으로 시스템의 모든 디바이스가 리셋되지 않습니다. 개발자는 AP 단독으로 Reset되었을 때 발생하는 문제를 대비해야합니다.
고객은 공학적인 지식이 없으므로, 이러한 문제에 대해 심각한 고장으로 인식하거나 민감하게 반응합니다. AP리셋 후 이상동작하는 디바이스는 가능한 빨리 초기화해야 합니다. 초기화 하는 코드는 부트로더에서 AP의 초기화를 완료하자마자 바로 실행되어야 합니다.
가장 쉽게 디바이스를 초기화 하는 방법은, 해당 디바이스의 전원(VCC)를 내렸다가 올리는 것입니다. 가장 확실하고 안정적인 방법입니다.
단점이라면 전원 OFF - ON 사이의 딜레이로 인하여 부팅시간이 약간 늘어납니다. 또한 HW 회로 구성에 따라 이 방법을 사용하지 못할 수 있습니다.
어떤 식으로 Reset되었던 간에, 디바이스 초기화시 Reset Pin을 컨트롤 해주는 것은 당연합니다. 다만 외부에서 만들어진 디바이스 초기화 코드를 보면, 전원이 인가되면서 부팅되는 것이 당연하다고 생각했는지 Reset Pin 을 컨트롤하지 않는 경우가 있습니다. 이 경우엔 디바이스 초기화 시에 Reset Pin 도 컨트롤하도록 수정하여야 합니다.
Reset Pin이 DataSheet으로만 존재하고 실제로는 동작하지 않는 경우도 있습니다. 이 경우 HW에 요청하여 해당 디바이스의 전원을 OFF - ON 할 수 있는 회로를 확보하여야 합니다.
디바이스 드라이버의 코드가 Spec과 다르게 짜여진 경우가 있습니다. 말이 안된다고 생각하시겠지만 문제가 자주 발생하지 않으면 찾아내기 어렵습니다.
개발자라면 자신이 담당하는 디바이스의 드라이버가 스펙에 맞게 동작하는지는 확인하는 것이 좋습니다. 품질에 까다로운 회사의 경우에는 모든 신호가 spec 에 맞게 주어지는지 검증부서에서 확인하기도 합니다.
여기까지 '강제 리셋시 발생하는 문제'를 포스팅하였습니다.
이 이슈는 정말 드믈게 발생합니다. 강제리셋을 자주할 정도라면 제품이 매우 많이 팔렸거나 심각한 문제를 가지고 있어야 합니다. 많이 팔리는 제품이라면 출시전에 점검을 철저히 해서 문제를 이미 해결했을 것이고, 심각한 문제를 가지고 있는 제품이라면 다른 문제가 많아서 이 이슈는 묻혀버렸을 것입니다.
개발중에 발생할 수 있는 한가지 사례 정도로 생각해주시면 되겠습니다.
개발자의 일에 자동은 없습니다. 모든게 수동입니다.
포스팅은 여기까지입니다. 궁금한 점 있으시면 댓글로 문의해주세요.
언제나 감사드립니다.
USB3이 포함된 보드 개발 시 유의할 점 (0) | 2022.08.19 |
---|---|
제조업 부품 수급 문제 대응 방안 (0) | 2022.04.21 |
PCB 자를 때 니퍼를 사용하면 안되는 이유 (0) | 2022.04.11 |
댓글 영역