임베디드 시스템에서 SWD 인터페이스 작동 방식

SWD 인터페이스란 무엇이며 어떻게 작동하는가

ARM 기반 임베디드 제품을 출시하는 팀은 보드 초기화 과정에서 익숙한 패턴에 직면합니다. 펌웨어가 로드되고, 보드에 전원이 켜지지만 아무 일도 일어나지 않습니다. 출력이 없고, 응답이 없으며, 명백한 오류도 없습니다. UART 로그는 조용합니다. LED는 꺼진 상태로 유지됩니다. 프로세서를 중지하고 레지스터 상태를 검사할 방법이 없으면 조사 작업은 즉시 중단됩니다.

이것이 바로 SWD 인터페이스가 해결하기 위해 설계된 상황입니다. SWD는 PCB 상의 단 두 개의 신호선을 사용하여 프로세서에 직접 접근(실행 중지, 메모리 읽기, 중단점 설정, 리플래시)할 수 있는 경로를 제공합니다. 이러한 낮은 핀 비용과 깊은 접근성의 조합으로 인해 SWD는 ARM Cortex 임베디드 설계 전반에 걸쳐 기본 디버그 및 프로그래밍 인터페이스가 되었습니다.

Serial Wire Debug 프로토콜 — 신호 아키텍처 및 핀 역할

SWD는 SWDIO와 SWDCLK라는 두 개의 필수 신호를 사용합니다. SWDCLK는 디버그 프로브에서 대상 MCU로 클럭을 전달합니다. SWDIO는 양방향으로, 반이중 프레이밍을 사용하여 단일 와이어를 통해 호스트로부터의 명령과 대상으로부터의 응답을 모두 전달합니다.

반이중 설계는 턴어라운드 사이클을 통해 작동합니다. 호스트가 요청 패킷 전송을 완료하면, 대상이 확인 및 읽기 데이터 단계를 위해 회선 소유권을 전환합니다. 프로토콜은 이러한 전환을 정확하게 정의하므로 양쪽 모두 언제 드라이브하고 언제 수신해야 하는지 알고 있습니다. JTAG가 병렬로 전송하는 모든 것을 직렬화하므로 두 개의 와이어로 충분합니다.

두 개의 선택적 신호가 인터페이스를 확장합니다. nRESET 라인은 프로브가 대상에 하드웨어 리셋을 어설션할 수 있도록 하여, 프로세서가 멈추어 디버그 포트를 통한 소프트 리셋이 신뢰할 수 없을 때 유용합니다. SWO 핀(Serial Wire Output)은 대상에서 프로브로 추적 데이터를 전달합니다. ITM 기반 printf 로깅 및 ETM 명령어 추적 모두 SWO를 출력 경로로 사용합니다.

두 개의 와이어로 중지, 메모리 액세스, 플래시 프로그래밍 및 중단점을 제공하며, SWO를 세 번째 핀으로 추가하면 완전한 JTAG 추적 포트 없이 실시간 추적이 가능합니다.

전기적 인터페이스는 간단합니다. SWDIO는 회선을 드라이브하지 않을 때 높은 상태로 유지하기 위해 일반적으로 10kΩ의 풀업 저항이 필요합니다. SWDCLK는 플로트하거나 풀다운할 수 있습니다. 풀업 값은 중요합니다. 너무 약하면 높은 클럭 속도에서 회선이 느리게 충전되고, 너무 강하면 전환 중에 프로브의 드라이브 강도와 충돌합니다.

SWD 대 JTAG — 각 프로토콜이 적합한 경우

SWD와 JTAG 모두 동일한 ARM Debug Interface (ADI) 사양에서 파생됩니다. 두 프로토콜은 동일한 기본 Debug Port 및 Access Port 아키텍처를 공유합니다. 차이점은 물리적 토폴로지와 신호 수이며, 디버깅 기능 자체의 차이는 아닙니다.

JTAG는 TCK, TMS, TDI, TDO 및 선택적으로 TRST의 5가지 신호를 사용합니다. 여러 장치가 단일 JTAG 체인을 공유할 수 있으며, 각 장치는 TDI에서 TDO로 데이터를 전달하여 데이지 체인을 형성합니다. SWD는 점대점 방식입니다. 즉, 하나의 프로브가 하나의 타겟에 연결됩니다. 이것이 핵심적인 절충점입니다.

기준	SWD	JTAG
신호 수	2개 (+ 선택적 SWO, nRESET)	4-5개
토폴로지	점대점	데이지 체인 (다중 장치)
다중 장치 지원	제한적 (SWD 멀티드롭, 범용 아님)	기본
트레이스 출력	SWO (단일 핀, 제한된 대역폭)	전체 TPIU 추적 포트 (4비트 병렬)
최적	싱글 코어 ARM, 핀 제약 PCB	다중 장치 체인, 고대역폭 추적

오늘날 대부분의 ARM Cortex-M 설계는 SWD를 기본 인터페이스로 사용합니다. 소형 폼 팩터 PCB의 핀 수 제약으로 인해 JTAG가 사용 가능한 GPIO의 상당 부분을 차지하는 경우 2선 설계를 실용적으로 만듭니다. 듀얼 코어 SoC 또는 여러 프로그래밍 가능한 장치가 있는 보드에서는 JTAG의 체인 토폴로지가 더 나은 선택으로 남아 있습니다.

많은 ARM 장치에서 동일한 물리적 커넥터에서 JTAG와 SWD 간 전환이 가능합니다. JTAG-to-SWD 선택 시퀀스는 TCK/SWDCLK를 클럭하면서 TMS/SWDIO에 특정 16비트 매직 값을 보내는 것을 포함합니다. 대부분의 디버그 프로브는 이를 자동으로 처리합니다. ARM 10핀 및 20핀 Cortex 디버그 커넥터는 동일한 풋프린트에 두 프로토콜 모두를 전달하므로 둘 간에 전환할 때 PCB 설계를 변경할 필요가 없습니다.

제약된 보드 공간이 있는 싱글 코어 ARM 타겟의 경우 SWD가 실용적인 기본값입니다. 다중 장치 체인 또는 고대역폭 병렬 추적이 확실한 요구 사항인 설계에는 JTAG를 예약하십시오.

SWD 커넥터, 핀 매핑 및 전기적 호환성

ARM Cortex 디버그 커넥터는 두 가지 표준 크기로 제공됩니다. 20핀 버전(0.1인치 피치)은 평가 보드와 대부분의 벤치 디버그 어댑터에 사용되는 클래식 폼팩터입니다. 10핀 버전(0.05인치 피치, 2×5)은 보드 공간이 제한된 생산 하드웨어에서 더 일반적입니다. 두 버전 모두 SWDIO, SWDCLK, nRESET, SWO, VTref(타겟 전압 감지) 및 GND를 지원합니다.

Tag-Connect는 생산 보드에 대한 인기 있는 대안입니다. 커넥터를 완전히 제거하며, 스프링 로드 프로브가 PCB의 작은 패드 풋프린트에 접촉합니다. TC2030-IDC 풋프린트는 6개의 패드로 SWD를 지원하며 대량 생산 설비에서 널리 사용됩니다. 보드 비용은 거의 0으로 떨어지고 풋프린트는 좁은 레이아웃에 맞을 만큼 충분히 작습니다.

전압 호환성은 주의가 필요합니다. 프로브는 타겟의 I/O 전압과 일치해야 합니다. 대부분의 최신 프로브는 VTref를 감지하고 이에 따라 드라이브 레벨을 조정하여 1.8V, 3.3V 및 5V 타겟을 지원합니다. 레벨 시프팅 없이 3.3V 프로브를 1.8V 타겟에 직접 연결하면 통신이 처음에 작동하는 것처럼 보여도 시간이 지남에 따라 타겟의 I/O 셀이 손상됩니다.

• SWDIO 풀업: VCC에 10kΩ이 표준 시작 값입니다. 높은 SWDCLK 속도에서 신호 상승 시간이 느린 경우 4.7kΩ으로 줄입니다.
• 트레이스 길이: SWDIO 및 SWDCLK 트레이스를 짧고 일치하게 유지합니다. 고속 스위칭 신호의 긴 트레이스는 패킷을 손상시키는 반사를 유발합니다.
• 디커플링: MCU의 VDD 핀에 100nF 디커플링을 가깝게 배치합니다. SWD 트랜잭션은 신호 무결성에 영향을 미치는 전류 스파이크를 생성합니다.
• GPIO 충돌: 연결을 시도하기 전에 펌웨어에서 SWDIO 및 SWDCLK 핀이 다른 주변 장치로 재할당되지 않았는지 확인합니다.

전체 커넥터 핀맵 참조, 전압 레벨 배선 다이어그램 및 PCB 레이아웃 지침은 다음을 참조하십시오. SWD 커넥터 핀아웃 및 배선 참조.

임베디드 시스템에서의 SWD 인터페이스 — 디버깅, 프로그래밍 및 생산 용도

프로토콜을 이해하는 것이 기본입니다. 대부분의 임베디드 팀에게 더 중요한 질문은 SWD가 초기 부트스트랩부터 생산 프로그래밍 및 현장 유지보수에 이르기까지 전체 제품 수명 주기에 어떻게 적용되는지입니다. 각 단계에는 다른 요구 사항이 있으며, SWD는 동일한 2선 인터페이스를 통해 이 모든 것을 처리합니다.

SWD를 통한 펌웨어 플래싱 및 인서킷 프로그래밍

SWD는 ARM Cortex-M 및 Cortex-A 타겟의 주요 인서킷 프로그래밍 경로입니다. 타겟에 사전 부트로더가 필요하지 않습니다. 디버그 프로브는 프로세서의 디버그 포트에 직접 연결되고, 코어를 중지시키며, 메모리 맵핑된 플래시 컨트롤러를 통해 플래시에 기록합니다.

프로그래밍 시퀀스는 공급업체 및 도구에 걸쳐 일관된 패턴을 따릅니다.

• 연결: 프로브는 SWD 통신을 설정하고 타겟의 IDCODE를 읽어 장치 식별을 확인합니다.
• Halt: 프로브가 디버그 포트를 통해 Cortex 코어를 중지합니다.
• Erase: 프로브가 타겟 RAM에 로드된 플래시 알고리즘을 사용하여 타겟 플래시 섹터를 지웁니다.
• Program: 바이너리 이미지가 페이지 단위로 기록되며, 플래시 알고리즘이 타겟에서 각 쓰기를 수행합니다.
• Verify: 프로브가 기록된 데이터를 다시 읽어 소스 바이너리와 비교합니다.
• Reset: 프로브가 코어를 해제하고 펌웨어가 실행을 시작합니다.

플래시 알고리즘은 MCU 공급업체별로 다릅니다. OpenOCD, pyOCD 및 공급업체 IDE에는 이러한 알고리즘 라이브러리가 각각 포함되어 있습니다. 새로운 MCU 변형이 아직 도구의 데이터베이스에 없을 경우, 알고리즘을 수동으로 추가해야 합니다. 이는 생산 램프 중에 새로운 실리콘 개정을 채택할 때 일반적인 불편 사항입니다.

SWD 프로그래밍에는 두 가지 주요 호스트 측 흐름이 있습니다. 드래그 앤 드롭 프로그래밍(CMSIS-DAP 및 DAPLink 기반 프로브에서 사용)은 프로브를 USB 대용량 저장 장치로 표시합니다. 여기에 바이너리 파일을 떨어뜨리면 플래시 시퀀스가 자동으로 트리거됩니다. 이 접근 방식은 현장 기술자에게 빠르고 소프트웨어 설치가 필요하지 않습니다. OpenOCD와 함께 GDB를 사용하거나 STM32CubeProgrammer 또는 nrfjprog와 같은 공급업체 CLI 도구를 사용하는 호스트 제어 흐름은 더 많은 제어를 제공합니다. 스크립팅, 성공/실패 로깅 및 자동화된 테스트 시스템과의 통합을 지원합니다.

프로브 선택 및 호스트 측 툴체인 설정에 대한 지침은 SWD 디버그 프로브 선택 및 구성.

SWDCLK 주파수는 실제 프로그래밍 속도를 결정합니다. 대부분의 Cortex-M 타겟은 안정적인 조건에서 최대 10MHz의 SWDCLK를 지원하지만, 온도 및 케이블 길이 변화에 따른 여유를 유지하기 위해 많은 양산 픽스처는 4-8MHz로 작동합니다. 4MHz에서 256KB 이미지를 프로그래밍하는 데는 일반적으로 소거 및 검증을 포함하여 10초 미만이 소요됩니다. 갱 프로그래밍 픽스처(하나의 호스트가 4개 또는 8개의 보드를 동시에 프로그래밍하는 방식)는 사이클 시간 목표를 달성하기 위해 대량 생산에서 일반적입니다.

테스트 포인트 배치는 중요합니다. SWDIO, SWDCLK, GND 및 VCC 테스트 포인트는 보드의 픽스처 측에서 접근 가능해야 합니다. 이를 부품 측에 배치하면 양면 픽스처가 필요하게 되어 비용과 복잡성이 증가합니다. 제품 개정 전반에 걸쳐 일관된 위치에 이를 그룹화하면 픽스처 재사용이 실용적입니다.

실시간 디버깅, 추적 및 CoreSight 통합

SWD는 ARM CoreSight 디버그 아키텍처의 전송 계층입니다. 이 아키텍처를 이해하면 프로브가 타겟에 연결된 후 실제로 무엇을 할 수 있는지 설명합니다.

CoreSight는 두 가지 포트 유형을 통해 디버그 액세스를 구성합니다. DP(Debug Port)는 SWD 인터페이스 자체로, 연결, 인증 및 최상위 제어를 처리합니다. AP(Access Port)는 DP 뒤에 있으며 특정 리소스에 대한 액세스를 제공합니다. AHB-AP는 전체 메모리 맵에 대한 읽기/쓰기 액세스를 제공하며, Core Debug 레지스터는 해당 맵 내에 있습니다. AHB-AP를 통해 프로브는 코어가 중지된 동안 모든 메모리 주소, 주변 레지스터 또는 CPU 레지스터를 읽고 쓸 수 있습니다.

중단점과 감시점은 Cortex-M 코어의 DWT 및 FPB 장치를 통해 작동합니다. 하드웨어 중단점은 실행이 특정 주소에 도달하면 프로세서를 중지합니다. 감시점은 지정된 주소 또는 주소 범위에 대한 메모리 액세스(읽기, 쓰기 또는 둘 다) 시 중지합니다. Cortex-M4는 일반적으로 6개의 하드웨어 중단점과 4개의 감시점을 제공합니다. 이 개수를 초과하려면 소프트웨어 중단점이 필요하며, 이는 플래시의 명령어를 수정하고 자체적인 제한 사항이 있습니다.

Halt 모드 디버깅은 본질적으로 침습적입니다. 프로세서가 멈추고, 실시간에 민감한 주변 장치(워치독 타이머, 통신 주변 장치, 모터 제어 루프)는 코어가 중지된 동안 계속 실행되거나 오류가 발생합니다. 실시간 시스템에서 작업하는 엔지니어는 시간 제약이 있는 섹션에 대해 비침습적 디버그 방법을 필요로 합니다.

SWO 트레이스가 이를 해결합니다. Serial Wire Output 핀은 Instrumentation Trace Macrocell(ITM)의 데이터와, ETM이 있는 코어의 명령어 트레이스를 전달합니다. ITM 트레이스를 통해 펌웨어는 32채널 소프트웨어 FIFO로 로그 메시지를 기록할 수 있습니다. 프로브는 코어를 중지하지 않고 실시간으로 데이터를 읽습니다. 이것은 printf 디버깅의 임베디드 버전이지만, UART 출력에 비해 런타임 오버헤드가 미미합니다. 일반적인 ITM 쓰기는 몇 클럭 사이클이 걸리고, 데이터는 초당 몇 메가비트의 속도로 SWO를 통해 나갑니다.

RTT(Real-Time Transfer)는 SWO를 사용할 수 없거나 프로브가 트레이스를 지원하지 않을 때의 대안입니다. RTT는 타겟 RAM에 작은 링 버퍼를 사용합니다. 프로브는 코어가 실행되는 동안 디버그 포트를 통해 버퍼를 읽습니다. 추가 핀이 필요하지 않습니다. 단점은 RAM 사용량(일반적인 RTT 버퍼는 로그 볼륨에 따라 512바이트에서 4KB 사용)과 SWO에 비해 약간의 지연 시간입니다.

중단점, SWO 트레이스 구성 및 RTT의 실습 설정을 보려면 단계별 SWD 디버그 환경 설정을 참조하십시오.

산업용 HMI, IoT 및 생산 임베디드 시스템에서의 SWD

ARM 기반 산업용 HMI 컨트롤러, IoT 엣지 노드, 모터 드라이브 MCU 및 빌딩 자동화 장치 전반에 걸쳐 SWD는 제품 수명 주기에서 개발 디버그, 생산 프로그래밍 및 현장 유지 관리의 세 가지 뚜렷한 역할을 수행합니다. 각 역할은 다른 요구 사항을 가지며, 인터페이스는 동일한 물리적 연결을 통해 이 세 가지 모두를 처리합니다.

산업용 HMI 및 자동화 컨트롤러 생산 프로그래밍 및 현장 펌웨어 업데이트에 주로 SWD를 사용합니다. HMI 생산 라인의 일반적인 테스트 지그는 SWDIO, SWDCLK, GND 및 VCC 테스트 포인트에 포고핀 커넥터를 사용합니다. 호스트는 스크립트된 플래시 시퀀스를 실행하고 보드 일련 번호로 결과를 기록하며, 재작업을 위해 실패를 표시합니다. 보드당 사이클 시간은 기능 테스트 단계를 포함하여 일반적으로 15-30초입니다. SWD 인터페이스 자체는 총 시간에 10초 미만을 추가합니다.

산업용 IoT 엣지 노드 종종 TrustZone 또는 읽기 방지 기능이 활성화된 Cortex-M33 또는 Cortex-M4 타겟에서 실행됩니다. 개발 중에는 SWD가 전체 디버그 액세스를 제공합니다. 출하 전에 펌웨어는 읽기 방지를 활성화합니다. 이는 옵션 바이트 또는 퓨즈 레지스터에 한 번만 쓰는 것으로, SWD 디버그 액세스를 비활성화하고 메모리 읽기를 방지합니다. 플래시 내용은 디버그 포트를 통해 읽을 수 없게 됩니다. 이는 출하된 제품에서 펌웨어 IP를 보호하는 표준 메커니즘입니다.

읽기 방지가 설정된 후 SWD를 다시 활성화하려면 전체 삭제가 필요합니다. 장치는 디버그 액세스를 다시 열기 전에 모든 플래시를 삭제합니다. 이는 펌웨어를 보호합니다. 이미지를 읽고 복원할 수 있는 방법은 없지만, 보증 수리 또는 공장 재작업 시 장치를 처음부터 다시 플래시해야 합니다. 첫 번째 반송 장치가 도착한 후가 아니라 생산 시작 전에 이를 고려한 재작업 흐름을 구축하십시오.

모터 드라이브 및 전력 전자 MCU 타이밍 제약이 추가됩니다. 이러한 설계 중 다수는 정상 작동 시 SWD 핀을 GPIO로 사용합니다. MCU는 부팅 후 SWDIO 및 SWDCLK를 다른 기능으로 리매핑합니다. 리매핑 후 프로브를 연결하면 조용히 실패합니다. 해결책은 디버그 창입니다. 펌웨어가 리매핑 전에 SWD를 활성 상태로 유지하는 짧은 시작 시점입니다. 이는 프로브가 창 중에 연결하고 리매핑 전에 코어를 중지할 수 있도록 합니다.

듀얼 코어 SoC—STM32H7 시리즈 또는 NXP i.MX RT와 같은 산업용 MCU에서 점점 더 보편화됨—은 SWD 멀티드롭 또는 코어당 별도의 디버그 커넥터를 필요로 합니다. SWD 멀티드롭은 동일한 SWDCLK/SWDIO 라인에서 각 코어에 고유한 타겟 ID를 할당합니다. 모든 프로브가 이를 지원하는 것은 아닙니다. 새 설계에서 듀얼 코어 SWD 디버그 아키텍처를 채택하기 전에 프로브 펌웨어 버전 및 멀티드롭 지원을 확인하십시오.

CI/CD 통합은 이제 커넥티드 제품을 출시하는 임베디드 팀에서 표준 사례가 되었습니다. OpenOCD, pyOCD 및 대부분의 공급업체 CLI 도구는 빌드 파이프라인에서 직접 호출할 수 있는 명령줄 인터페이스를 제공합니다. 일반적인 자동 테스트 단계는 펌웨어를 플래싱하고, 디버그 포트를 통해 전원 켜기 자체 테스트를 실행하며, 알려진 메모리 주소에서 통과/실패 결과를 읽고, 결과를 기록합니다. 이를 통해 매번 빌드 시, 수동 테스트 주기뿐만 아니라 플래시 쓰기 실패 및 기본 펌웨어 결함을 감지할 수 있습니다.

STONE HMI는 자동화 프로젝트 전반에 걸쳐 구조화된 펌웨어 개발 프로세스를 적용합니다.

임베디드 제품 팀의 경우, 이러한 종류의 프로세스 규율은 개발 랩을 넘어 중요합니다. 첫 생산 실행 전에 생산 프로그래밍, 자동화된 테스트 및 현장 수리 절차가 정의되고 테스트되면, 납품 위험이 크게 감소합니다. 해당 워크플로에서 SWD의 역할은 단순한 디버그 편의성이 아니라, ARM 기반 하드웨어에서 반복 가능하고 검증 가능한 생산 프로그래밍을 가능하게 하는 메커니즘입니다.

SWD 인터페이스에 대한 자주 묻는 질문

SWD 인터페이스는 무엇에 사용되나요?

SWD는 ARM Cortex 프로세서에 대한 디버그 액세스, 펌웨어 플래싱 및 실시간 추적을 제공합니다. 개발 중 초기 디버깅, 제조 중 생산 프로그래밍, 현장 펌웨어 업데이트를 포함한 전체 제품 수명 주기를 다룹니다. 아키텍처 및 프로그래밍 워크플로는 위 섹션에서 자세히 다룹니다.

SWD는 몇 개의 핀이 필요합니까?

SWD는 두 개의 핀(SWDIO 및 SWDCLK)을 필요로 합니다. 세 번째 핀인 nRESET은 선택 사항이지만, 타겟이 알 수 없는 상태에 있을 수 있을 때 안정적인 프로브 연결을 위해 권장됩니다. 네 번째 핀인 SWO는 추적 출력 기능을 추가합니다. 전체 신호 분해는 H3 1.1을 참조하십시오.

SWD를 개발 디버깅뿐만 아니라 양산 프로그래밍에 사용할 수 있습니까?

예. ARM 기반 임베디드 제품의 경우 SWD를 통한 양산 프로그래밍이 표준적인 방식입니다. 포고 핀 픽스처, 갱 프로그래머 및 스크립트 CLI 도구는 모두 대량 플래시 프로그래밍을 위해 SWD 인터페이스를 사용합니다. 프로그래밍 시퀀스, 속도 제한 및 픽스처 설계 요인은 H3 2.1에서 다룹니다.

펌웨어 플래싱 시 SWD와 UART의 차이점은 무엇입니까?

UART 기반 플래싱은 MCU의 ROM 또는 플래시에 이미 존재하는 부트로더를 사용합니다. 즉, 프로세서가 실행 중이어야 하고 부트로더가 활성화되어야 합니다. SWD는 프로세서를 완전히 우회하여 디버그 포트를 통해 플래시에 직접 씁니다. SWD는 대상에 펌웨어가 없거나, 이미지가 손상되었거나, 프로세서가 멈춘 경우에도 작동합니다.

모든 ARM Cortex 프로세서에서 SWD를 지원합니까?

SWD는 모든 ARM Cortex-M 및 대부분의 Cortex-A 프로세서에서 지원됩니다. 이는 ARM 디버그 인터페이스(ADI) 사양의 일부이며 Cortex-M0 이후의 Cortex-M 실리콘에 포함되었습니다. 구형이거나 매우 내장된 Cortex-A 구성 중 일부는 JTAG만 노출하지만, 이는 현재 설계에서는 드뭅니다.

출하된 제품에서 펌웨어를 보호하기 위해 SWD를 비활성화하려면 어떻게 해야 합니까?

대부분의 ARM Cortex-M MCU는 읽기 방지 메커니즘을 제공합니다. 이는 옵션 바이트 또는 보안 퓨즈에 대한 일회성 쓰기로, 디버그 포트 액세스를 비활성화하고 메모리 읽기를 방지합니다. 이를 다시 활성화하려면 펌웨어가 파괴되는 전체 대량 삭제가 필요합니다. 보안 워크플로 및 재작업 고려 사항은 H3 2.3에서 다룹니다.