임베디드 및 HMI 시스템을 위한 SWD 디버그 워크플로

SWD 연결을 설정하는 것은 첫 단계일 뿐입니다. 프로브가 타겟을 인식한 후 더 어려운 문제가 시작됩니다. 디버그 세션이 조용히 오작동하거나, UART 출력 없이 폴트 벡터가 발생하여 설명할 수 없거나, 생산 라인에서 동일한 2선 인터페이스를 통해 결정론적 합격/불합격 검증이 필요한 경우입니다. 이 문서는 세션 초기화, 폴트 격리 및 생산 디버그 전략과 같은 능동적인 디버그 워크플로에 중점을 둡니다. 이 모든 것의 기반이 되는 물리적 및 프로토콜 계층에 대해서는 다음을 참조하십시오. SWD 인터페이스 아키텍처 및 핀 역할.

SWD 디버그 워크플로, 폴트 격리 및 생산 디버그 전략

임베디드 타겟에서 안정적인 SWD 디버그 세션 설정

연결 확인은 프로브가 와이어를 통해 비트를 클럭할 수 있음을 확인합니다. 디버그 세션에는 더 많은 것이 필요합니다: 디버그 액세스 포트가 초기화되어야 하고, 타겟이 알려진 리셋 상태에 도달해야 하며, 유의미한 작업이 시작되기 전에 프로브가 안정적인 SWCLK 주파수를 협상해야 합니다. 이러한 각 단계는 독립적으로 실패할 수 있으며, 대부분의 디버그 도구에서 제공하는 오류 메시지는 세 가지 실패 모두를 동일하게 처리합니다.

리셋 시퀀싱은 ARM Cortex-M 타겟에서 가장 흔하게 발생하는 사일런트 실패 지점입니다. SYSRESETREQ은 대부분의 주변 장치를 다시 초기화하는 전체 시스템 리셋을 어설트합니다. VECTRESET은 프로세서 코어만 리셋하고 주변 장치 상태는 그대로 유지합니다. 주변 장치가 클럭 게이트 또는 전원 도메인을 잡고 있는 타겟에서 VECTRESET을 선택하면, 초기화되지 않은 주변 장치에 액세스하려고 할 때 즉시 오류가 발생하는 코어에 디버그 세션이 연결될 수 있습니다. 대부분의 개발 보드는 두 가지 옵션 모두를 허용합니다. 맞춤형 전원 시퀀싱을 사용하는 프로덕션 하드웨어는 그렇지 않은 경우가 많습니다.

클럭 속도 선택은 유사한 논리를 따릅니다. 보수적인 SWCLK 속도(일반적으로 1MHz 이하)에서 시작하면 프로브가 DAP 초기화를 시작하기 전에 타겟이 리셋 후 안정화될 시간을 제공합니다. 세션이 실행되면 4~10MHz로 속도를 높이면 플래시 프로그래밍 시간과 메모리 읽기 지연 시간을 줄일 수 있습니다. SWDIO 및 SWDCLK 신호 사양 더 긴 트레이스나 케이블 연결 타겟에서는 몇 메가헤르츠 이상의 주파수에서는 라인 반사가 실제 제약 조건이 됩니다.

멀티드롭 SWD는 또 다른 계층을 추가합니다. 두 개 이상의 장치가 동일한 SWD 버스를 공유하는 경우(주 MCU와 디스플레이 컨트롤러가 모두 SWD를 노출하는 HMI 보드에서 흔함), 프로브는 DAP 초기화 전에 타겟 선택 시퀀스를 발행해야 합니다. 멀티드롭 버스에서 이 단계를 건너뛰면 일반적으로 배선 오류와 동일하게 보이는 DAP 초기화 실패가 발생합니다.

알려진 양호한 배선 확인 후 디버그 세션이 실패하는 경우, 첫 번째 질문은 이전 펌웨어 빌드가 장치 옵션 바이트의 디버그 비활성화 비트를 설정했는지 여부입니다. 잠긴 DAP는 연결되지 않은 것과 동일한 오류를 반환합니다.

잠긴 DAP와 배선 오류를 구별하려면 실리콘 공급업체가 지원하는 경우 매스-이레이즈 잠금 해제 시퀀스를 통해 장치의 읽기 보호 레지스터를 확인해야 합니다. 일부는 그렇지 않으며, 잠긴 장치는 디버거에서 영구적으로 액세스할 수 없게 됩니다.

활성 SWD 디버그 세션 중 결함 격리 기법

Cortex-M 타겟이 하드 폴트 상태로 진입하고 UART 주변 장치가 폴트 소스인 경우, 읽을 수 있는 시리얼 출력이 없습니다. CPU가 폴트 핸들러에서 중지된 후에도 DAP는 계속 액세스할 수 있습니다. DAP를 통해 CFSR(Configurable Fault Status Register), HFSR(Hard Fault Status Register), 폴트 주소 레지스터(BFAR, MMFAR)를 직접 읽으면 작동하는 주변 장치 출력 없이 완벽한 폴트 진단이 가능합니다. UART가 라우팅된 보드에서도 하드웨어 초기 설정 중에 SWD 디버그 액세스를 계속 유지해야 하는 주된 이유입니다.

브레이크포인트 전략은 대부분의 엔지니어가 예상하는 것보다 중요합니다. Cortex-M의 FPB(Flash Patch and Breakpoint) 장치는 적은 수의 하드웨어 브레이크포인트(코어 버전에 따라 일반적으로 4~8개)를 제공합니다. 소프트웨어 브레이크포인트는 런타임 시 플래시에 패치된 BKPT 명령어를 사용합니다. 플래시 상주 코드에 혼합하여 사용하면 문제가 발생합니다. 플래시의 소프트웨어 브레이크포인트는 명령어 스트림을 수정하여 일부 부트로더 및 보안 모니터에서 사용하는 플래시 체크섬을 무효화합니다. 보안이 중요한 초기 설정 중에 플래시 상주 코드에는 하드웨어 브레이크포인트를 사용하십시오.

DWT(Data Watchpoint and Trace) 장치를 통한 워치포인트는 실제 사용에서 과소평가됩니다. 특정 메모리 주소를 감시하도록 DWT 컴퍼레이터를 구성하면 디버거가 해당 주소에 값이 쓰여지는 순간 CPU를 중지할 수 있어 — 손상이 폴트 벡터로 전파되기 전에 — 가능합니다. 스택 오버플로우 또는 초기화되지 않은 포인터 쓰기를 추적할 때 브레이크포인트를 사용하여 이진 분할하는 것보다 훨씬 빠릅니다.

RTOS 인식 디버깅은 특별한 주의가 필요합니다. FreeRTOS 또는 ThreadX 애플리케이션에 연결된 베어메탈 디버그 세션은 폴트를 유발한 스레드가 아닌, 중지 시 실행 중이던 스레드의 스택을 보여줍니다. 프로브는 RTOS 스레드 인식을 지원해야 하며, 이는 올바른 RTOS 플러그인을 로드하고 정확한 커널 버전과 일치시키는 것을 의미합니다. 일치하지 않는 플러그인은 그럴듯해 보이지만 잘못된 스택 추적을 생성합니다.

한 가지 실질적인 주의사항: 라이브 세션 중에 DAP를 통해 주변 장치 레지스터를 읽으면 상태 플래그가 지워질 수 있습니다. 많은 Cortex-M 장치의 UART 상태 레지스터는 읽을 때 지워집니다. 라이브 표현식 창에서 UART 상태 레지스터를 감시하면 펌웨어가 기다리던 플래그가 소모되어 디버그 세션이 닫힐 때 사라지는 방식으로 애플리케이션이 중단됩니다.

프로덕션 및 최종 검사 환경에서의 SWD 디버그

프로덕션 SWD 디버그는 개발 디버그와 다른 목표를 갖습니다. 세션은 탐색적이지 않고 — 지우기, 프로그래밍, 확인, 부트 확인, 선택적으로 잠금과 같은 고정된 시퀀스를 실행합니다. 성공의 척도는 진단 깊이가 아니라 사이클 시간과 반복성입니다. 프로덕션 라인에서 개발 프로브 워크플로를 사용하려는 팀은 일반적으로 너무 느리고 수동 단계에 너무 많이 의존한다는 것을 알게 됩니다.

자동화된 세션 스크립팅이 이를 해결합니다. J-Link 스크립트 파일, pyOCD 스크립트 및 OpenOCD TCL 시퀀스는 수동 개입 없이 전체 최종 생산 라인 흐름을 제어할 수 있습니다. 일반적인 스크립트는 타겟을 지우고, 펌웨어 이미지를 쓰고, 체크섬 블록을 다시 읽고, 부트 벡터를 확인하고, 로그 파일에 합격/불합격 결과를 기록합니다. 일반적인 임베디드 HMI 펌웨어 이미지의 경우 플래시 크기와 클럭 속도에 따라 유닛당 10~30초 범위의 사이클 시간을 달성할 수 있습니다.

전체 디버그 기능 없이 전용 플래시 프로그래밍 워크플로의 경우, 전용 SWD 플래시 프로그래밍 도구는 더 빠른 사이클 시간과 자동화된 테스트 장비에 대한 더 간단한 통합을 제공합니다. 단점은 프로그래머 전용 도구는 DAP를 통해 플래시 후 부트 확인을 실행할 수 없다는 것입니다. 대신 기능 테스트 단계로 전환됩니다.

디버그 액세스 잠금 해제는 기술적인 결정만큼이나 비즈니스 결정입니다. 최종 생산 라인 프로그래밍 후 읽기 방지 기능을 활성화하면 펌웨어 IP를 보호하지만 반환된 유닛에서 오류 레지스터를 읽는 기능을 제거합니다. 까다로운 산업 환경으로 제품을 출하하는 팀은 현장 RMA 분석을 위해 잠금 해제된 유닛의 소규모 집단을 유지하거나, DAP가 서명된 자격 증명으로만 액세스할 수 있는 공급업체별 디버그 인증 메커니즘을 사용합니다.

HMI 보드에는 종종 여러 SWD 타겟이 있습니다. 즉, 메인 애플리케이션 MCU, 디스플레이 컨트롤러, 때로는 터치 컨트롤러가 모두 같은 보드에 있습니다. 단일 디버그 세션을 통해 이를 관리하려면 다중 드롭 SWD 구성 또는 프로브를 타겟 간에 전환하는 장비가 필요합니다. 생산 라인에서 타겟 간의 케이블을 다시 연결하는 것은 신뢰성 위험입니다. 프로브 전환 기능이 있는 고정 장비가 대량 생산에는 더 나은 선택입니다.

STONE HMI 엔지니어링 팀은 IEC 61508 기반 관행을 따릅니다.

팀이 직면한 경우 HMI 생산에서의 임베디드 디버그 문제공정 규율이 종단 라인 시퀀스가 최종 확정되기 전, 즉 픽스처 설계 단계에서 중요하다는 것을 의미합니다. 디버그 액세스 정책, 잠금 타이밍 및 픽스처 아키텍처를 초기에 올바르게 설정하면 생산량이 증가할 때 비용이 많이 드는 재작업을 피할 수 있습니다.

SWD 헤더를 위한 PCB 공간은 반복적인 절충 사항입니다. 개발 중에는 채워진 4핀 헤더가 편리합니다. 생산 시에는 포고 핀 픽스처가 있는 비어있는 테스트 패드가 해당 공간을 회수하고 커넥터 마모를 줄입니다. 기기가 잠긴 후에는 populated 헤더의 현장 서비스 가능성에 대한 주장이 약해집니다. DAP가 닫혀 있다면, 출하 후에는 헤더가 아무런 역할을 하지 않습니다.

FAQ

SWD 디버그는 대상 펌웨어가 실행되는 동안 사용할 수 있습니까?
예. SWD는 DAP를 통해 CPU를 중지하지 않고 라이브 실행 중 비침입적 메모리 및 레지스터 읽기를 지원합니다. 이를 위해서는 백그라운드 메모리 액세스를 지원하는 프로브가 필요합니다. 모든 저가형 프로브가 이를 구현하는 것은 아닙니다. 라이브 레지스터 읽기의 실제적인 제한 사항은 위의 장애 격리 섹션을 참조하십시오.

SWD 배선이 올바르게 보이는 데도 "대상 장치가 연결되지 않았습니다" 오류가 발생하는 이유는 무엇입니까?
위의 세션 설정 섹션에서는 세 가지 주요 원인을 자세히 설명합니다. 펌웨어로 잠긴 DAP, 대상의 현재 클록 상태에 대한 잘못된 SWCLK 주파수, 누락되거나 잘못된 리셋 시퀀스입니다. 멀티드롭 버스에서는 대상 선택 시퀀스가 누락되면 동일한 오류가 발생합니다.

모든 ARM Cortex-M 장치에서 SWD 디버그를 지원하나요?
SWD 디버그는 ARM CoreSight 아키텍처의 일부이며 Cortex-M0, M0+, M3, M4, M7, M23 및 M33 코어에서 지원됩니다. 특정 장치가 DAP를 노출하는지는 실리콘 공급업체의 구현에 따라 달라집니다. 일부 원가 절감 부품은 DAP를 비활성화하거나 생략하므로 SWD 디버그 액세스가 가능한지 가정하기 전에 장치 참조 설명서를 확인하십시오.

SWD 디버그와 SWD 프로그래밍의 차이점은 무엇인가요?
SWD 프로그래밍은 2선 인터페이스를 사용하여 플래시에 펌웨어를 씁니다. SWD 디버그는 더 나아가 CPU 중지, 레지스터 읽기, 중단점 삽입 및 실행 중 메모리 감시점을 지원합니다. 전용 SWD 프로그래머는 플래시 쓰기 경로만 처리하며 생산용으로는 더 빠르고 간단하지만, 플래시 후 부팅 확인 또는 오류 진단을 수행할 수 없습니다.

임베디드 제품 개발에서 가장 많은 시간을 낭비하게 만드는 패턴은 SWD 디버그를 단일 워크플로우를 가진 단일 도구로 취급하는 것입니다. 세션 설정, 오류 격리 및 생산 검증은 각각 고유한 실패 모드와 고유한 도구 요구 사항을 갖습니다. 이 세 단계를 분리하고 각 단계를 신중하게 구성하는 엔지니어는 일반적으로 초기화 시간과 생산 수율이 모두 향상됨을 알게 됩니다. HMI 프로그램에서 임베디드 디버그 지원을 평가하는 프로젝트 관리자는 벤치에 개발 프로브가 있는지 여부뿐만 아니라 엔지니어링 팀이 정의된 최종 라인 디버그 정책을 가지고 있는지 여부를 조기에 묻는 것이 좋습니다.