MDS테크놀로지 DT사업부
이 상 철 대리
sangcheol@mdstec.com
MDS테크놀로지에서 산업용 표준 디버깅 솔루션 'TRACE32' 기술지원을 맡고 있다. 교육과 세미나를 통해 TRACE32의 다양한 실전 사례와 활용방법을 임베디드 개발자들과 공유하고 있다.
TRACE32 : www.TRACE32.com
MDS테크놀로지 홈페이지 : www.mdstec.com
ITM - Instrumentation Trace Macrocell
ITM은 그 이름에서도 알 수 있듯이 printf 형식의 SW코드의 구현으로 트레이스 기능을 수행하는 로직이다. 개발자는 보통 자신이 보고자 하는 특정 변수 값이나 메모리 값을 보기 위해 printf를 사용하는데, 이와 동일하게 보고자 하는 값을 ITM에 할당된 특정 레지스터에 전달하고 이 값이 출력되는 것이다.
이렇게 CortexA9의 PTM과 같이 데이터 트레이스를 지원하지 않는 환경에서 ITM은 제한적으로나마 데이터 트레이스를 해볼 수 있는 방안을 제공한다.
하지만 ITM과 printf 사이에는 근본적인 차이점이 존재하는데 데이터 출력 과정을 '누가 처리해 주느냐?'와 이에 따른 속도의 차이이다.
printf의 원래의 프로그램이 수행되던 중, 개발자가 지정한 메시지를 출력하기 위해 printf와 UART 관련 함수로 점프해 관련 동작을 수행하게 된다. 하지만 ITM의 경우 목적은 printf와 동일하지만 개발자가 지정한 데이터의 출력을 프로세서가 처리하는 것이 아니라 단순히 ITM으로 이를 전달하고 이후 동작은 ITM이 맡아 관련 동작을 수행한다.
프로세서가 관련 데이터를 ITM으로 던지는 것은 어셈블리로 3~4 라인에 불과하고 다른 함수로 점프하지 않아도 되기 때문에 프로세서의 성능 저하가 거의 없는 상황에서 '개발자가 보고 싶은 특정 데이터의 로깅'이라는 목적을 달성할 수 있는 것이다.
예를 들어, CortexA9의 경우 데이터 트레이스를 지원하지 않기 때문에 이전 버전의 ETM에서 유용하게 사용 할 수 있었던 태스크의 컨텍스트 스위칭에 대한 트레이스에는 약간의 어려움이 있었다. 하지만 ITM이 구현된 SoC를 사용한다면 ITM을 이용해 스케줄러에서 처리되는 태스크 정보를 ITM으로 출력받아 태스크 트레이스에 적용할 수 있다.
CoreSight는 ETM, ITM, HTM 등 다양한 트레이스 소스에서 생성되는 데이터를 트레이스 버스 - ATB - 통해 하나의 트레이스 스트림을 생성하는 Funnel로 전달한다. 때문에 ITM 데이터는 두 가지 경로를 통해 외부로 출력 될 수 있다.
ITM 데이터는 위 그림에서 볼 수 있듯이 Replicator를 통해 다시 트레이스 버스에 전달되어 TPIU 또는 ETB를 통해 ETM 등 다른 드레이스 소스로 부터 생성되는 트레이스 데이터와 ITM을 조합해서 디버깅에 활용할 수 있다. JTAG 디버깅 방식을 이용한다면 JTAG 또는 SWDP를 통해 ETB에 저장된 ITM을 조합해서 디버깅에 활용할 수 있다. JTAG 디버깅 방식을 이용한다면 JTAG 또는 SWDP를 통해 ETB에 담긴 작은 크기만큼의(Cortex의 경우 주로 8KB) 데이터만 읽을 수 있다.
앞서 설명한 SWDP가 활성화되는 경우, 출력핀인 TDO핀이 남게 되는데, 이를 SWO 핀으로 할당하여 그림 9처럼 ITM 데이터가 SWO를 통해 출력될 수 있다. 이 경우 JTAG을 위한 두 핀과 SWO, 그리고 GND까지 4핀이면 JTAG과 ITM 트레이스를 이용할 수 있으며, 실제 JTAG 커넥터를 구성할 때에는 VTref 핀을 같이 구성해 주어야 한다.
HTM-AHB Trace Macrocell
HTM은 시스템 버스인 AHB 버스를 통해 오고 가는 값을 출력한다. ETB은 프로세서가 실행하는 프로그램 코드 또는 읽고 쓰는 데이터에 관한 정보를 출력하기 때문에 DMA와 같이 프로세서의 영역을 벗어나는 부분에 대해서는 아무것도 알 수 없다. 하지만 HTM은 시스템 버스의 데이터를 출력하고 이를 볼 수 있는 것이기 때문에 시스템 분석과 문제 해결에 좀 더 풍부한 정보를 제공해 준다.
또한 사용자는 HTM을 통해 시스템 버스가 어떻게 활용되고 있는지, 버스의 부하 정도는 어떤지 확인(또는 추정)할 수 있는 데이터를 얻을 수 있다. 프로그램 동작 중 락업이나 기타 문제가 발생했을 때 AHB 버스에 데이터가 들어갔는데 그 상태에서 스톨되어 멈춘 것인지, 프로그램 수행 후 읽고 쓰는 데이터가 버스에 들어오기는 했는지 등을 살펴보는 등 프로그램의 수행 여부 수준으로만 디버깅을 하던 차원에서 시스템 상태를 확인하며 디버깅을 위한 정보를 얻을 수 있는 것이다.
다른 트레이스 데이터와 마찬가지로 HTM에서 출력되는 데이터 역시 Funnel - AMBA Trace Bus(ATB) - Tra ce Port Interface Unit(TPIU)를 통해 바로 출력되거나 다른 트레이스 데이터와 하나의 트레이스 스트림을 만들어 출력될 수 있다.
이러한 데이터는 PowerTrace 또는 Co mbiProbe를 통해 받아볼 수 있으며, 트레이스 장비가 없을 때에는 JTAG 또는 SWDP를 통해 ETB에 저장된 데이터에 접근할 수 있다. 물론 ETB에 담긴 작은 크기만큼의(Cortex의 경우 주로 8/kB) 데이터만 읽을 수 있다. CortexA7/A15의 경우 주 시스템 버스로 AXI를 사용하는데, 이를 트레이싱 할 수 있는 트레이스 매크로셀은 아직 발표되지 않았다.
Funnel / TPIU
Funnel과 TPIU는 디버깅에 활용할 수 있는 직접적인 정보를 생성하는 것은 아니지만 멀티코어 환경의 디버깅 방법론을 제공하기 위한 중요한 역할을 한다. 가령 CoreSight가 적용되지 않은 멀티코어의 경우, 각 코어에서 ETM을 통해 생성되는 트레이스 데이터를 받으려면 각 ETM에 연결되는 트레이스 포트를 따로 뽑아주어야 했다.
하나의 트레이스 포트는 총 38핀으로 구성되는데 JTAG과 GND들이 포함된 것이지만 보드 한장에 여러 트레이스 포트를 뽑는 것은 현실적으로 불가능하다. 하지만 Coresight는 ETM, ITM, HTM 등 여러 트레이스 소스에서 생성된 트레이스 데이터들이 ATB를 통해 Funnel로 전달되고 하나의 트레이스 스트림으로 합성된다. 때문에 하나의 트레이스 포트로도 여러 트레이스 소스의 데이터를 받을 수 있게 되는 것이다.
마치며
지금까지 CoreSight의 각 디버그 로직의 역할과 디버깅을 위해 제공하는 정보에 대해 알아보았다.
CoreSight에는 JTAG만이 있는 것이 아니다. 프로그램의 흐름부터 시스템 버스의 트레이스까지 다양한 데이터를 제공하고 있으며 이는 시스템이 리얼타임으로 수행한 내역을 분석할 수 있는 훌륭한 디버깅 정보가 된다. 점차 고도화되는 멀티코어 환경에서 JTAG만이 아닌 다양한 트레이스 소스를 이용해 효율적으로 문제를 해결하는데 조금이나마 도움이 되었으면 한다.
회원가입 후 이용바랍니다.
개의 댓글
댓글 정렬
BEST댓글
BEST 댓글
답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
내 댓글 모음