이 장에서 다룰 내용
- Oscilloscope, Logic Analyzer, DMM 사용
- SWD/JTAG Debugging
- UART Log와 Trace
- 전원 기동 파형 측정
- 통신 오류와 노이즈 원인 추적
11.1 보드 디버깅의 기본 순서
보드가 동작하지 않을 때 가장 먼저 확인할 것은 펌웨어 코드가 아니라 전원이다. 전원, Reset, Clock, Boot, Debug 연결, 통신, I/O 순서로 확인하면 원인을 빠르게 좁힐 수 있다. 순서를 건너뛰면 단순 전원 문제를 펌웨어 문제로 착각해 시간을 낭비하기 쉽다.
기본 순서는 다음과 같다.
- 입력 전원 전압과 전류를 확인한다.
- 내부 전원 Rail이 정상인지 측정한다.
- Reset Pin이 정상적으로 해제되는지 본다.
- Clock이 동작하는지 확인한다.
- Debugger가 연결되는지 확인한다.
- Boot Log 또는 UART 출력이 나오는지 본다.
- 통신과 I/O를 하나씩 확인한다.
각 단계에서 측정 결과를 기록해야 한다. "정상 같음"이 아니라 전압, 시간, 파형, 조건을 적는다. Rev 변경이나 재현 테스트 때 이 기록이 기준이 된다.
11.2 전원과 Reset 먼저 확인하기
전원 문제는 다양한 증상으로 나타난다. 보드가 가끔 Reset되거나, 통신이 끊기거나, ADC 값이 흔들리거나, Debugger 연결이 불안정할 수 있다. DMM으로 DC 전압만 보는 것으로는 부족하고, 오실로스코프로 기동 파형과 Ripple을 확인해야 한다.
Reset Pin은 전원 인가 후 일정 시간 Low를 유지한 뒤 High로 올라가야 한다. Reset이 너무 빨리 풀리거나 전원 Ripple 때문에 다시 떨어지면 MCU가 불안정하게 부팅된다. Power Good, Reset, 3.3V, Clock Enable을 동시에 측정하면 원인을 보기 쉽다.
Loadport나 Pre-Aligner 보드에서는 Solenoid나 Motor Driver가 켜질 때 Logic 전원이 흔들리는지 확인해야 한다. 최대 부하 상태에서 측정하지 않으면 실제 장비 안에서만 발생하는 문제를 놓칠 수 있다.
11.3 Clock과 Boot 확인
Clock 문제는 부팅 실패, 통신 Baud Rate 오류, USB/Ethernet 불량으로 나타날 수 있다. Crystal 회로는 Probe를 대는 것만으로도 영향을 받을 수 있으므로 측정 방법을 조심해야 한다. 가능하면 Clock Output Pin이나 MCO 기능을 사용해 확인한다.
Boot Mode Pin도 확인한다. Pull-up/Pull-down이 잘못되었거나 Jig가 Pin을 잡고 있으면 MCU가 Application이 아닌 Bootloader로 들어갈 수 있다. Reset 직후 Boot Pin 상태를 오실로스코프로 보면 의도치 않은 흔들림을 확인할 수 있다.
Boot Log는 강력한 진단 도구다. Firmware Version, Reset Cause, Boot Mode, 초기화 결과를 UART로 출력하면 보드가 어디까지 살아 있는지 알 수 있다.
11.4 통신 파형 분석
통신 문제는 펌웨어 버그일 수도 있지만 물리 계층 문제일 때가 많다. UART는 TX/RX 전압 레벨과 Baud Rate를 확인한다. RS-485는 A/B 차동 파형, DE 제어 타이밍, Termination, Idle Bias를 확인한다. CAN은 CANH/CANL 파형과 종단저항을 확인한다. Ethernet은 PHY Link, Magnetics, Cable, IP 설정을 함께 봐야 한다.
RS-485 Half-duplex에서는 송신 후 수신으로 전환하는 타이밍이 중요하다. DE를 너무 빨리 내리면 마지막 Byte가 잘리고, 너무 늦게 내리면 다른 노드 응답과 충돌할 수 있다. Logic Analyzer로 UART TX와 DE Pin을 동시에 보면 확인하기 쉽다.
통신 오류는 Error Counter와 로그를 남겨야 한다. CRC Error, Timeout, Retry Count, Frame Error, Bus Off 상태를 구분하면 현장 문제 분석이 빨라진다.
11.5 로그 설계
좋은 로그는 문제를 설명한다. 나쁜 로그는 글자가 많지만 원인을 찾기 어렵다. 로그에는 시간, 상태, 이벤트, Error Code, 주요 입력 상태가 들어가야 한다. 예를 들어 123456ms RUN -> ERROR, reason=VACUUM_FAIL, input=0x12처럼 상태 전이와 원인이 함께 보이면 좋다.
로그는 개발용 상세 로그와 제품용 이벤트 로그를 구분한다. 개발용 로그는 많아도 괜찮지만 제품용 로그는 Flash 수명과 통신 부하를 고려해야 한다. 현장에서는 마지막 몇십 개 이벤트만 있어도 큰 도움이 된다.
Debug Console 명령으로 현재 상태, 입력값, 출력값, 통신 상태, Error History를 조회할 수 있게 하면 유지보수가 쉬워진다. 단, 출력 강제 On 같은 명령은 서비스 모드에서만 허용해야 한다.
11.6 재현 어려운 현장 문제 대응
현장 문제는 항상 개발실에서 재현되지 않는다. 온도, 전원 품질, 케이블 길이, 주변 모터 동작, 작업자 순서가 모두 다를 수 있다. 이런 문제를 다루려면 로그와 측정 포인트를 설계 단계에서 준비해야 한다.
재현 어려운 문제는 조건을 좁히는 방식으로 접근한다. 발생 시간, 장비 상태, 직전 명령, 입력 상태, 통신 상태, Reset Cause, 전원 이벤트를 모은다. 이후 개발실에서 같은 조건을 만들어보고, 필요하면 임시 펌웨어로 더 많은 로그를 남긴다.
보드에는 주요 전원, Reset, 통신, 센서 입력, 출력 Driver에 Test Point를 두는 것이 좋다. Test Point가 없으면 현장 계측이 어려워지고, 문제 분석이 추측에 의존하게 된다.
체크리스트
- 전원, Reset, Clock, Boot 순서로 확인했는가?
- Power-up 파형을 오실로스코프로 측정했는가?
- 통신 파형과 펌웨어 로그를 함께 확인했는가?
- Reset Cause와 Error History가 남는가?
- 현장 계측에 필요한 Test Point가 있는가?
- 재현 조건을 숫자와 로그로 기록했는가?