산업 제조
산업용 사물 인터넷 | 산업자재 | 장비 유지 보수 및 수리 | 산업 프로그래밍 |
home  MfgRobots >> 산업 제조 >  >> Industrial Internet of Things >> 임베디드

Arm Core 장치의 JTAG 구현

이 기사에서는 Arm 디버그 인터페이스 또는 ADI에 특히 주의하면서 JTAG와 Arm 코어 장치 간의 교차점에 대해 설명합니다.

지금까지 JTAG 시리즈에서 테스트 액세스 포트(TAP) 컨트롤러와 TAP 상태 머신을 포함한 IEEE 1149.1 표준을 살펴보았습니다. 그런 다음 커넥터용 공통 핀아웃과 시장에서 사용 가능한 JTAG 인터페이스 및 디버그 프로브를 포함하여 JTAG 작업에 사용할 수 있는 다양한 물리적 인터페이스를 검토했습니다.

이 기사에서는 JTAG 표준에서 약간 벗어나 유비쿼터스 ARM 코어 장치에서 JTAG가 구현되는 방식을 살펴보겠습니다.

암이란 무엇입니까?

Arm은 마이크로프로세서 및 마이크로컨트롤러 인터페이스와 관련된 다량의 지적 재산과 함께 프로세서 아키텍처를 의미합니다. 소비자 PC가 x86 파생 프로세서 또는 PowerPC 또는 MIPS를 사용하는 경향이 있는 경우 임베디드 전자 제품은 Arm-core 프로세서로 구현되는 경우가 가장 많습니다.

프로세서의 "코어"는 ST Microelectronics 또는 NXP와 같은 제조업체에 배포되고 이러한 제조업체는 I2C 및 SPI 인터페이스, ADC 및 DAC, USB 인터페이스 등과 같은 추가 주변 장치 기능을 추가합니다.

Arm 아키텍처는 ARMv로 버전이 지정되며, 예로는 ARMv2(1987년부터), ARMv6(2002-2005년에 생산된 프로세서) 등이 있으며 이러한 아키텍처를 활용하는 프로세서 코어는 ARMx 시리즈(ARM1, ARM6, ARM7)로 브랜드화됩니다. 최근에는 고성능(Cortex-A), 실시간(Cortex-R) 및 마이크로컨트롤러(Cortex-M) 애플리케이션을 위한 ARM Cortex-A/R/M 시리즈로 출시되었습니다. 아키텍처 버전 관리는 Cortex 접미사 명명을 따르며 ARMv6-M, ARMv7-R, ARMv7-A와 같은 버전이 됩니다.

Arm의 디버깅 인터페이스는 Arm CoreSight 아키텍처라는 이름에 속합니다. 여기에는 디버그 인터페이스(Arm Debug Interface, ADI), 임베디드 트레이스 매크로셀(ETM), 고속 직렬 트레이스 포트(HSSTP) 및 CoreSight 프로그램 흐름 트레이스 아키텍처가 포함됩니다. ADI는 Arm-core 프로세서로 디버깅 작업을 위한 기반을 형성하며 이 표준의 일부에는 JTAG 인터페이스와 SWD(Serial Wire Debug) 대안이 포함됩니다. 이 기사의 주제는 ADI, 특히 하드웨어 인터페이스 계층입니다.

Arm 디버그 인터페이스(ADI) 소개

Arm 디버그 인터페이스(ADI)는 호스트와 하나 이상의 장치 간의 디버깅을 위한 하드웨어 인터페이스와 논리적 인터페이스의 사양입니다. 현재 대부분의 프로세서는 ADIv5(Arm IHI0031E에 지정됨)를 구현하는 반면 최신 ADIv6(Arm IHI0074C 참조)은 서서히 단계적으로 도입되고 있습니다. 더 인기가 있기 때문에 여기서는 ADIv5 표준에 초점을 맞출 것입니다.

ADI는 디버그 포트(DP)와 액세스 포트(AP)로 구성된 디버그 액세스 포트(DAP)를 정의합니다. DAP는 디버그 인터페이스의 기본 "단위"입니다. 주어진 장치에는 디버거와의 물리적 연결을 처리하는 하나의 디버그 포트와 디버그 레지스터, 추적 포트 레지스터, ROM 테이블 또는 시스템 메모리와 같은 시스템 리소스에 대한 액세스를 제공하는 여러 액세스 포트가 있습니다. 따라서 DP에는 물리적 연결(JTAG, SWD)과 일부 내장 레지스터가 포함되며, 각 AP는 시스템에 대한 연결과 다수의 자체 레지스터를 가지고 있습니다.

ADIv5에는 두 가지 유형의 디버그 포트와 (대략적으로) 세 가지 유형의 액세스 포트가 있습니다. DP는 장치 외부에서 DAP에 연결하는 데 사용되는 인터페이스의 이름을 따서 명명된 JTAG-DP 또는 SWD-DP일 수 있습니다. AP는 주소 지정(메모리 매핑과 유사하므로 이름)을 통해 리소스에 대한 액세스를 제공하는 MEM-AP, JTAG 스캔 체인을 전체 디버그 장치(DAP)에 연결할 수 있도록 하는 JTAG-AP, 공급업체별 Arm에서 지정하지 않은 AP. MEM-AP는 지금까지 가장 일반적이고 유용하므로 여기에서 다른 유형을 다루지 않습니다.

JTAG의 맥락에서 디버그 인터페이스가 JTAG 명령 코드와 공급업체별 JTAG 기능을 제공할 것으로 예상합니다. 실제로 ADIv5 표준은 다음 지침을 제공합니다.

<울>
  • EXTEST(0b00000000)
  • 샘플(0b00000001)
  • 미리 불러오기(0b00000010)
  • 시험(0b00000100)
  • 클램프(0b00000101)
  • 하이즈(0b00000110)
  • 중단(0b11111000)
  • DPACC(0b11111010)
  • APACC(0b11111011)
  • ID코드(0b11111110)
  • 바이패스(0b11111111)
  • 또한 JTAG 데이터 레지스터에는 다음이 포함됩니다.

    <울>
  • ABORT(35비트), 액세스 포트 강제 중단을 위한 레지스터
  • DPACC(35비트), 디버그 포트 읽기/쓰기 액세스 레지스터
  • APACC(35비트), 액세스 포트 읽기/쓰기 액세스 레지스터
  • IDCODE(32비트)
  • 바이패스(1비트)
  • 여기서 눈에 띄는 것은 DPACC 및 APACC 명령어와 관련 데이터 레지스터입니다. DPACC(디버그 포트 액세스) 및 APACC(액세스 포트 액세스)는 장치의 연결된 DP 및 AP에 명령을 전달하는 데 사용되는 명령/레지스터입니다. DPACC 또는 APACC 데이터 레지스터에 다른 값을 설정함으로써 디버거는 일반적으로 DP 및 AP의 레지스터와 상호 작용하는 다른 작업을 실행할 수 있습니다. 이러한 DPACC 및 APACC 레지스터(JTAG 레지스터)와 DP 및 AP에 내장된 레지스터 간의 차이점에 유의하십시오.

    일반적인 방법론은 디버거가 JTAG 또는 SWD 인터페이스를 사용하여 TAP 상태 머신을 통해 명령을 실행한 다음 명령이 데이터를 가져와서 DP 또는 AP로 로드하고 데이터에 따라 내부의 다른 레지스터를 사용한다는 것입니다. DP 또는 AP에 액세스하여 원하는 시스템 링크를 제공합니다.

    그렇다면 DP 및 AP 레지스터는 무엇입니까? 사용 가능한 DP 레지스터는 다음과 같습니다.

    <울>
  • CTRL/STAT, DP에 대한 상태 정보를 제어하고 획득하는 데 사용
  • DLCR, 데이터 링크 제어 레지스터, 데이터 링크의 작동 모드 제어
  • DLPIDR, 데이터 링크 프로토콜 식별 레지스터, 프로토콜 버전 정보
  • DPIDR, 디버그 포트 식별 레지스터, 디버그 포트 정보
  • EVENTSTAT, 이벤트 상태 레지스터, 시스템에서 외부 디버거에 이벤트 신호를 보내는 데 사용
  • RDBUFF, 읽기 버퍼 레지스터는 읽기 작업을 제공합니다. DP(JTAG 또는 SWD)에 따라 다름
  • SELECT, AP 선택 레지스터는 액세스 포트와 해당 AP와 함께 활성 레지스터 뱅크를 선택합니다. DP 주소 은행 선택
  • TARGETID, 호스트가 단일 장치에 연결된 경우 대상에 대한 정보 제공
  • MEM-AP 레지스터는 다음과 같습니다.

    <울>
  • 제어/상태 워드 레지스터(CSW, 0x00), 제어 및 상태 정보 보유
  • 전송 주소 레지스터(TAR, 0x04), 메모리 시스템 또는 시스템 리소스에 대한 다음 액세스를 위한 주소 보유
  • 데이터 읽기/쓰기 레지스터(DRW, 0x0C), TAR의 주소 읽기 또는 쓰기 설정 – DRW를 읽으면 액세스가 읽기로 설정됩니다. DRW에 쓰는 경우 액세스가 쓰기로 설정됩니다.
  • 뱅크 데이터 레지스터(BD0 ~ BD3, 0x10, 0x14, 0x18, 0x1C)는 TAR의 주소에서 시작하여 4개의 32비트 메모리 블록에 대한 직접 읽기 또는 쓰기 액세스를 제공합니다.
  • 구성 레지스터(CFG, 0xF4), MEM-AP 구성에 대한 정보
  • Debase 기본 주소 레지스터(BASE, 0xF8), 메모리 시스템에 대한 포인터, 디버그 레지스터 세트의 시작 또는 ROM 테이블의 시작
  • 식별 레지스터(IDR, 0xFC)는 MEM-AP를 식별합니다.
  • 연결은 아래 그림 1에 개략적으로 나와 있습니다.

    그림 1. Arm 디버그 인터페이스 다이어그램, 연결 요약. 참고:DP 및 AP에 대해 모든 레지스터가 표시되는 것은 아닙니다.

    DP/AP 레지스터 및 메모리 매핑에 대한 자세한 내용은 IHI 0031E 사양에서 찾을 수 있습니다. 자세한 내용을 설명하는 대신 다른 유형의 디버그 포트인 SWD-DP와 두 개의 와이어만 사용하여 JTAG를 구현하는 방법에 중점을 두고 싶습니다.

    직렬 와이어 디버그(SWD)

    JTAG-DP는 디버깅 인터페이스의 일반적이고 친숙한 예이지만 논의와 가장 관련이 있는 것은 Arm 장치에 대해 정의된 JTAG 대안인 Arm 직렬 와이어 디버그(SWD)입니다. SWD는 핀 수가 제한된 Arm-core 장치용 2선식 인터페이스로 개발되었습니다. 마이크로컨트롤러는 주변 장치에서 상당히 조밀한 경향이 있으므로 대부분의 Cortex-M 장치는 핀 공간을 절약하기 위해 전체 JTAG 대신 SWD를 구현합니다. 그렇다면 이 프로토콜은 어떻게 작동합니까?

    SWD는 ADIv5 사양(B4장)에 지정되어 있습니다. JTAG의 TDI 및 TDO 핀은 SWDIO라는 단일 양방향 핀으로 대체됩니다. 테스트 모드 선택(TMS) 핀이 완전히 제거되었습니다. 클럭(TCK)은 동일하게 유지됩니다(CLK 또는 SWCLK로 레이블 변경). 따라서 SWD는 JTAG에서 사용되는 4개의 핀에 비해 2개의 핀만 사용합니다. 이 작업을 수행하기 위해 SWD는 JTAG 작업의 반복적인 특성에 의존합니다. 상태 머신이 조작되고, 데이터가 안팎으로 이동하고, 프로세스가 반복됩니다. SWD와의 차이점은 상태 머신이 없다는 것입니다. 대신 명령이 SWDIO를 통해 직렬로 실행된 다음 동일한 핀이 데이터를 읽거나 쓰는 데 사용됩니다.

    SWD 통신에는 패킷 요청, 승인 및 데이터 전송의 세 단계가 있습니다. 패킷 요청 동안 호스트 플랫폼은 DP에 요청을 발행하고, 이는 승인 응답이 뒤따라야 합니다. 패킷 요청이 데이터 읽기 또는 데이터 쓰기 요청이고 유효한 승인이 있는 경우 시스템은 데이터 전송 단계에 들어갑니다. 여기서 데이터는 SWDIO를 통해 클럭인(쓰기) 또는 클럭아웃(읽기)됩니다. 데이터 전송 후 호스트는 패킷 요청을 시작하거나 유휴 주기로 SWD 인터페이스를 구동(클럭킹 SWDIO LOW)하는 일을 담당합니다. 패리티 검사는 패킷 요청 및 데이터 전송 단계에 적용됩니다.

    SWD의 세부 사항은 그림 2에 표시된 타이밍 다이어그램을 보면 가장 잘 이해할 수 있습니다.

    그림 2. 직렬 와이어 디버그에 대한 읽기 및 쓰기 작업을 보여주는 타이밍 다이어그램. [확대하려면 클릭]

    읽기 및 쓰기 작업은 모두 호스트가 SWDIO 라인을 HIGH 신호인 시작 비트로 구동하는 것으로 시작하여 동일하게 시작됩니다. 그 다음에는 AP 또는 DP 액세스 비트(APnDP), 읽기 또는 쓰기 비트(RnW), 주소(A[2:3]), 패리티 비트(PAR) 및 정지 비트( LOW 신호), 마지막으로 파크 비트가 옵니다. 이는 라인이 턴어라운드로 들어가기 전에 호스트가 라인을 HIGH로 구동할 때입니다. 턴어라운드 동안 타겟도 호스트도 라인을 운전할 수 없습니다.

    RnW의 값에 따라 읽기 또는 쓰기 작업이 선택됩니다. 쓰는 경우 대상은 3비트 ACK 신호를 제공하고 또 다른 턴어라운드 기간이 있고 그 다음에는 기록할 32비트 데이터(WDATA)와 패리티 비트가 있습니다. 읽는 경우 대상은 ACK를 제공한 다음 32비트 읽기 데이터(RDATA)로 라인을 계속 구동하고 패리티 비트가 뒤따릅니다. 오류가 발생한 경우 ACK 비트는 오류를 표시하고 호스트는 작업을 다시 시작하려고 시도할 수 있습니다. WDATA와 RDATA는 WDATA[31:0] 대신 WDATA[0:31]을 작성하여 그림 2에 표시된 것처럼 먼저 최하위 비트(LSb)로 전송됩니다.

    Arm IHI0031E 문서는 커뮤니케이션의 다양한 사례를 명확히 하기 위해 추가 타이밍 다이어그램을 제공하지만 위는 주요 사용 사례입니다. (작성 당시) 두 가지 버전의 SWD가 있다는 점은 주목할 가치가 있습니다. SWDv1은 호스트와 대상(점대점) 간의 하나의 연결만 지원하는 반면 SWDv2는 단일 호스트 다중 대상 통신(멀티드롭)을 구현합니다. 버전 2는 몇 가지 예외적인 경우를 제외하고는 버전 1과 거의 역호환됩니다.

    JTAG의 다른 변형

    SWD는 JTAG IEEE 1149.1 표준의 유일한 2선 변형이 아닙니다. 특히 IEEE 1149.7 표준은 감소된 핀 수(2선식) JTAG 인터페이스를 제공합니다. IEEE 1149.4(혼합 신호 테스트 버스 표준) 및 IEEE 1149.6(고급 디지털 네트워크의 경계 스캔 표준)과 같은 기타 1149.x 표준은 지난 20년 동안 개발되었으며 더 복잡한 응용 프로그램에 대한 추가 기능을 제공합니다. 여기에는 아날로그 경계 스캔 테스트와 차동 및 AC 결합 라인에 대한 향상된 기능이 포함됩니다.

    최신 표준은 IEEE 표준 협회 웹사이트에서 확인할 수 있습니다.

    결론

    이것으로 JTAG 및 SWD에 대한 내용을 마칩니다. 이 시리즈를 통해 우리는 JTAG가 어디에서 왔는지, 어떻게 작동하는지, 장치를 디버그하고 프로그래밍하는 데 어떻게 사용되는지 배웠습니다. 상용 및 오픈 소스 모두에서 사용 가능한 커넥터 및 인터페이스를 포함하여 JTAG의 물리적 연결을 살펴보았습니다. 마지막으로 SWD 2선 인터페이스를 포함하여 널리 사용되는 Arm 프로세서 핵심 기술에 대한 JTAG 구현의 개요로 결론을 내렸습니다.

    여기에서 우리는 임베디드 장치의 디버깅 및 프로그래밍 기능을 자신 있게 사용하고 다양한 구현에 대한 세부 사항을 배우고 시간을 최대한 활용할 수 있습니다.


    임베디드

    1. Arm은 Cortex-M 코어에 대한 맞춤형 지침을 가능하게 합니다.
    2. 배터리로 작동되는 의료 기기의 안정적인 전원 켜기
    3. 마우저:ADIS1647x ​​IMU는 IoT 장치의 탐색을 개선합니다.
    4. 3D 광학 감지 기술의 구현을 용이하게 합니다.
    5. Marvell, Arm과의 전략적 파트너십 확대
    6. 의료 기기 발전 모니터링
    7. 모터 컨트롤러는 Arm Cortex-M0 코어를 통합합니다.
    8. 분리형 RS-485 트랜시버로 설계 간소화
    9. Arm, Stream Technologies 인수로 IoT 연결 및 장치 관리 기능 확장
    10. 풍차 안전 장치