카드뉴스
워치독은 버그를 고치는 기능이 아닙니다
워치독 타이머는 임베디드 시스템이 멈췄을 때 다시 실행 기회를 주는 감시 장치입니다. 정상 동작 중인 펌웨어가 정해진 시간 안에 워치독을 refresh하면 계속 실행되고, refresh가 늦어지면 timeout으로 판단해 reset을 발생시킬 수 있습니다. 그래서 워치독을 넣었다고 코드가 안정해지는 것은 아닙니다. 무한 루프, 데드락, 블로킹 통신, 예외 처리 누락 같은 원인은 여전히 따로 찾아야 합니다.
실무에서는 워치독 reset이 발생했을 때 “살아났으니 됐다”로 끝내면 같은 문제가 반복될 가능성이 큽니다. reset reason 레지스터를 읽고, 가능한 경우 fault log나 마지막 상태를 비휘발성 메모리 또는 백업 RAM에 남겨야 원인을 좁힐 수 있습니다. 모터 제어, 전원 제어, 통신 게이트웨이처럼 출력 상태가 중요한 시스템에서는 재부팅 직후 안전 상태로 들어가는 순서도 같이 설계해야 합니다.
어디서 refresh하느냐가 감시 품질을 결정합니다
워치독을 타이머 인터럽트에서 상황을 보지 않고 refresh하면 감시 의미가 약해질 수 있습니다. 메인 루프가 멈췄거나 RTOS 태스크가 데드락에 빠졌는데도 인터럽트만 살아 있으면 시스템은 계속 정상으로 보일 수 있기 때문입니다. 더 나은 방식은 핵심 태스크들이 주기적으로 상태 플래그를 갱신하고, 그 조건이 모두 만족될 때만 워치독을 먹이는 구조입니다.
예를 들어 통신 수신, 제어 루프, 센서 갱신, 저장 작업이 모두 일정 시간 안에 진행되는지 확인한 뒤 refresh하는 식입니다. 이렇게 하면 워치독이 단순한 주기 타이머가 아니라 시스템 건강 상태를 확인한 결과가 됩니다. 다만 모든 상태를 지나치게 엄격하게 묶으면 순간적인 부하나 정상적인 긴 작업에서도 reset이 날 수 있어 균형이 필요합니다.
RTOS를 쓰는 경우에는 더 조심해야 합니다. 우선순위가 높은 태스크 하나만 계속 실행되고 낮은 우선순위 태스크가 굶주리는 상황에서도 워치독이 refresh될 수 있습니다. 이런 문제를 줄이려면 각 태스크가 heartbeat 값을 남기고, 감시 태스크가 그 값을 확인한 뒤 refresh하는 구조를 고려합니다. 큐, mutex, semaphore에서 멈춘 상태를 어떻게 감지할지도 함께 정해야 합니다.
timeout 값은 최악 실행 시간과 요구사항을 같이 봅니다
워치독 timeout이 너무 짧으면 플래시 erase, 통신 재시도, 초기 캘리브레이션처럼 시간이 오래 걸리는 정상 동작 중에도 reset될 수 있습니다. 반대로 너무 길면 펌웨어가 멈춘 뒤 복구까지 오래 걸립니다. 따라서 최악 실행 시간, 제어 주기, 사용자나 장비가 허용할 수 있는 정지 시간을 함께 놓고 범위를 잡아야 합니다.
일부 MCU는 window watchdog처럼 너무 빨리 refresh해도 오류로 판단하는 구조를 제공합니다. 이 방식은 코드가 예상보다 빠르게 잘못된 루프를 도는 상황까지 잡는 데 도움이 되지만, refresh 타이밍 설계가 더 까다롭습니다. 내부 워치독만으로 충분한지, 별도 외부 워치독 IC가 필요한지는 제품의 안전 요구사항과 전원, 클럭 독립성까지 함께 검토해야 합니다.
초기 bring-up 단계에서는 워치독을 잠시 끄고 디버깅하는 경우도 있지만, 최종 펌웨어에서는 그 결정이 명확히 관리되어야 합니다. 디버거 연결 중에 워치독을 멈출지, 저전력 모드에서 계속 돌릴지, firmware update 중에는 어떻게 처리할지도 제품 동작과 연결됩니다. 워치독은 마지막에 켜는 옵션이 아니라 reset 이후 복구 흐름까지 포함한 설계 항목으로 보는 편이 맞습니다.
