아이제트(I-Jet)와 아이제트 트레이스(I-Jet Trace) 비교분석

[테크월드뉴스=이혜진 기자] 디버깅 인터페이스를 설명하기 전에 현재 사용 중인 인터페이스의 종류에 대해서 알아볼 필요가 있다. 하나는 JTAG(Joint Test Access Group), 다른 하나는 ARM에서 개발된 SWD 인터페이스다. JTAG은 잘 알다시피 1980년대 중반에 조인트 유러피안 테스트 액세스 그룹(Joint European Test Acees Group)으로 시작, 1990년 IEEE에서 표준화해 제정됐다. 그에 반해 SWD는 ARM에서 개발된 디버그 인터페이스이며 2개의 핀(pin)으로 통신이 가능하다. 

그림 1. JTAG 인터페이스(왼쪽)와 SWD 인터페이스. 
그림 1. JTAG 인터페이스(왼쪽)와 SWD 인터페이스. 

각각의 특장점을 살펴보면 JTAG은 최소로 필요한 핀의 개수가 4개인 반면 SWD는 2개다. (SWO 핀의 기능을 사용하면 핀 개수의 차이는 1개). 결선도는 JTAG은 데이지 체인(Daisy Chain) 방식으로 연결되며 SWD는 스타 토폴로지(Star Topology) 방식으로 연결이 가능하다. 지원하는 CPU 종류는 JTAG은 대부분의 MCU에서 사용하고 있고, SWD는 ARM 디바이스에 한정해 사용된다. 마지막으로 SWD 방식에서 SWO 핀의 기능을 언급할 필요가 있는데, 여러가지 디버깅 정보를 SWO 핀으로 출력할 수 있는 점에서 JTAG과 다르다.

아래 그림은 ARM의 코텍스(Cortex) 디바이스 기준, 지원 가능한 디버깅 인터페이스를 나타낸다. CM3, CM4, CM7 기준으로 JTAG/SWD/SWO/ITM/ETM 기능이 기본적으로 제공되는 것을 확인할 수 있다. 

그림 2. ARM Cortex 디바이스 기준, 지원가능한 디버깅 인터페이스

SWO(Serial Wire Output)

SWO가 제공하는 다양한 디버깅 정보를 알고 사용할 수 있으면 더욱 효율적인 디버깅이 가능하다. 주요 기능은 세미호스팅인 'printf()'처럼 실행을 멈추고 동작하는 구조가 아니기 때문에 더 빠르게 정보를 전달한다. 함수 프로파일러(Function Profiler)를 이용해 어느 함수가 얼마나 리소스를 사용하고 있는 지 보여준다. 데이터 로그(Data Log) 기능을 이용해 타임라인 윈도우(Timeline Window)에서 실시간으로 변하는 변수의 모니터링이 가능하다. ITM 포트로 이벤트 전송과 인터럽트 로그도 할 수 있다. 타겟 보드에서 소모되는 전류를 실시간으로 모니터링 할 수 있고, SWO 트레이스(Trace) 기능을 이용해 모든 인스트럭션(Instruction)별로 로그를 저장하지는 못하지만 버그의 위치를 추적할 수 있게 해준다. 

ITM(Instrument Trace Macrocell)

ITM 모듈은 타킷 어플리케이션에서 사용가능한 printf()와 같은 컨셉의 디버깅 요소로써 어플리케이션 이벤트를 생성하고 디버깅 정보를 전달한다. 앞에서 설명한 세미호스팅과의 차이점은 디버깅 프로브를 거쳐 호스팅 컴퓨터로 디버깅 메시지를 전달할 때, 해당 구문에서 멈췄다가 실행되는 것이 아닌 SWO 포트를 이용해 멈춤없이 실행된다. 실시간성을 원하는 어플리케이션에서 사용하길 권고한다.

ETM(Embedded Trace Macrocell)

우선 ETM의 개략적인 기능은 코드 수행 내역을 인스트럭션(Instruction) 단위로 저장해 버그의 위치를 추적할 수 있게 해주는 것이다. 그 외에도 함수의 수행 시간 측정, 함수간 콜 그래프(Call Graph) 생성, 더 정확한 코드 커버리지(Code Coverage) 기능을 제공한다. ETM은 디버그 프로브에 별도의 트레이스 버퍼를 갖고 있어(최대 256MB) 트레이스 정보를 이 버퍼에 저장하는 방식이다. 4~16비트의 데이터 버스를 가지며 최대 ETM 트레이스 클럭은 350MHz로 고속이다. 이 기능을 사용하려면 디버그 프로브 장치명에 일반적으로 Trace라고 표기된 장비를 사용해야 한다(ex. I-Jet Trace). 또 4bit 데이터버스의 경우 다음 그림과 같이 JTAG이나 SWD 인터페이스 외에 5개의 트레이스를 위한 핀이 추가된다.

그림 3. ETM 트레이스 사용을 위한 핀맵
그림 3. ETM 트레이스 사용을 위한 핀맵

ETB(Embedded Trace Buffer)와 MTB(Micro Trace Buffer)

ETB는 칩 내부에 트레이스용 작은 버퍼를 갖고 있는 트레이스 기능을 말한다. 그에 반해 MTB는 코텍스-M0+용이며 어플리케이션에서 사용하는 RAM의 일부를 가변 트레이스 버퍼로 할당해서 사용하는 방식이다.

지금까지 살펴본 디버깅 인터페이스를 정리하면 아래 그림과 같다. DWT(Data Watchpoint and Trace) 블록 내 4개 와치포인트, PC 샘플러, 인터럽트 트레이스의 정보가 ITM 모듈의 각 채널을 통해 시간 정보(Time stamping)와 함께 SWO핀으로 제공된다. 또한 ETM 트레이스는 별도 블록으로 트레이스 포트(Trace port, 4~16bit 데이터버스)를 통해 인스트럭션 별로 추적가능한 트레이스 정보가 제공된다. 

그림 4. ARM 코어사이트 개요
그림 4. ARM 코어사이트 개요

고급 디버깅 기능을 통한 디버깅 시간 단축 방법

1. 아이 제트와 아이제트 트레이스의 성능 비교

그림 5. 아이제트와 아이제트 트레이스의 성능 비교
그림 5. 아이제트와 아이제트 트레이스의 성능 비교

표에서도 볼 수 있듯 가장 큰 차이점은 통신 속도 및 ETM 트레이스 기능 지원 유무다. JTAG, SWD 뿐만 아니라 SWO 대역폭도 아이제트보다 속도가 2배 빠르다. 다운로드 속도도 월등하다. 아이제트 트레이스는 코텍스-M 전용(CM)과 Cortex-A/R/M을 모두 사용할 수 있는 버전으로 나뉘는데, 코텍스-A/R/M기준 트레이스 버퍼는 256Mbyte, 그리고 클럭(clock)은 350MHz다.

2. SWO 트레이스와 ETM 트레이스의 비교

우선 트레이스를 사용하는 목적부터 분명히 해야할 필요가 있다. 트레이스(Trace)의 뜻에서 알 수 있듯이 수행 이력을 추적해 버그가 발생한 정확한 위치를 발견하는 것이다. 하나의 예를 들어 버그가 발생된 것을 감지하고, 혹은 버그 발생 후 브레이크 포인트에 멈춰 있다면, 버그 발생 위치부터 프로그램이 멈춘 곳까지는 많은 동작(Instructions)이 이미 일어났을 가능성이 높다. 이 모든 동작을 인스트럭션 별로 빠짐없이 수집해 추적하는 것이 버그를 잡는 가장 좋은 방법일 것이다.

그림 6. 트레이스 기능을 사용할 때와 사용하지 않는 때 비교

아래 그림은 SWO 트레이스와 ETM 트레이스를 비교 분석한 결과다. 가장 중요한 점은 트레이스 성능이다. SWO 트레이스는 매우 작은 버퍼를 갖고 샘플링(Sampling) 단위로 수행 정보(instruction)를 가져오기 때문에 모든 수행 결과 취득을 보장하지 못한다. 이것은 SWO 트레이스를 분석하더라도 버그의 정확한 위치를 찾지 못할 수 있음을 의미한다.

그림 7. SWO 트레이스와 ETM 트레이스 비교
그림 7. SWO 트레이스와 ETM 트레이스 비교

다음은 같은 코드, 같은 위치에 브레이크 포인트를 삽입한 후 트레이스 데이터를 취득한 결과다. ETM 트레이스는 scale_wave 함수 초기에 멈췄으며, 그 동안 수행한 이력을 모두 취득했지만, SWO 트레이스는 해당 위치를 기록하지 못하고 코드 내의 다른 곳(이전 샘플링 지점)을 가리키고 있다. SWO 트레이스도 버그 위치 근처까지 탐색할 수 있는 기능을 갖고 있지만, 하드폴트(HardFault)나 기타 어려운 디버깅 문제에 당면했을 때, 버그의 정확한 위치는 소요되는 시간과 바꿀 수 있다.

그림 8. 브레이크 포인트 삽입 위치
그림 8. 브레이크 포인트 삽입 위치
그림 9. ETM Trace 취득 결과
그림 9. ETM Trace 취득 결과
그림 10. SWO 트레이스 취득 결과
그림 10. SWO 트레이스 취득 결과

3. 콜 그래프(Call Graph)

콜그래프 기능은 ETM 모듈이 있는 디바이스만 가능하다. IAR 임베디드 워크벤치(Embedded Workbench)에서 제공하는 타임라인(Timeline) 그래프를 콜해 실시간으로 변화하는 함수 콜 관계를 도식화할 수 있다. 물론 커서를 옮겨 더블 클릭을 하면 해당 소스의 위치도 찾아준다. 예를 들면 인터럽트 핸들러에 의해 예기치 않은 경우가 발생되었을 시, 이 콜 그래프를 이용하면 해당 인터럽트가 발생한 위치를 알 수 있고, 그 때 당시의 함수 콜 관계와 소스 코드 위치도 검색할 수 있다.

그림 11. 타임라인 윈도우를 통한 함수 콜 그래프 사용법
그림 11. 타임라인 윈도우를 통한 함수 콜 그래프 사용법

4. 프로파일링(Profiling)

함수 프로파일링 기능은 코드 내의 병목현상과 같은 특정 영역(Hot spot)을 찾는데 유용하다. 해당 함수 수행이 전체 리소스에서 차지하는 비율을 알려주고 에너지 소모량도 계산해준다. SWO로 이 기능을 수행했을 때, 함수가 사용하는 리소스는 PC Samples라는 항목으로 나타나는데, 이것은 해당 함수가 수행하고 있을 때 몇 번의 프로그램 카운터를 샘플링 했느냐는 데이터로 해당 함수 내에 있던 시간을 나타낸다. PC Samples가 높다는 것은 해당 함수가 리소스를 많이 사용하고 있다는 뜻이다.

그림 12. SWO 기반 Profiling
그림 12. SWO 기반 Profiling

아래 그림은 ETM 기반 함수 프로파일링을 나타낸다. 위 내용에 추가적인 내용으로 함수의 정확한 수행 시간을 알 수 있다. 플랫 타임(Flat Time)을 해당 함수만에 대해 수행했을 때, 즉 함수 내의 다른 함수가 수행한 시간은 제외한 시간이다. 어큐뮬레이트 타임(Acc. Time)은 내부 함수 수행 시간을 합친 전체 함수의 수행 시간이다. 

그림 13. ETM기반 프로파일링
그림 13. ETM기반 프로파일링

이렇듯 함수 프로파일링 기능을 이용하면 제한된 리소스를 개발 계획에 맞게 사용하고 있는 지, 병목 현상이 생겼다면 어디서 발생할 수 있는 지 등 코드의 내부 사항을 모니터링 하기 유용하다.

5. 코드 커버리지(Code Coverage)

개발자가 작성한 코드가 적절히 수행이 되고 있지는 코드 커버리지 검사를 통해 알 수 있다. IAR 임베디드 워크벤치에서 제공하는 기능은 구분 커버리지로써 해당 소스가 수행되었는 지 해당 구문을 표기해준다. 이 커버리지 검사는 간단히 클릭 한 번으로 수행될 수 있으며 논리적으로 오류가 없는 지 코드 작성 후 검사를 수행하면 디버깅에 사용되는 많은 시간을 줄일 수 있다.

그림 14. ETM기반 코드 커버리지
그림 14. ETM기반 코드 커버리지

맺음말

지금까지 아이제트와 아이제트 트레이스를 비교 분석하면서, SWO기반의 디버깅 기능들과 ETM 기반의 디버깅 기능들을 살펴봤다. 개발 환경을 개발하는 업체는 개발자들의 노력과 고충을 알고 그것을 해결할 수 있는 대다수의 기능을 개발해 놓고 있다. 선택은 개발자의 몫이다.  

회원가입 후 이용바랍니다.
키워드
개의 댓글
0 / 400
댓글 정렬
BEST댓글
BEST 댓글 답글과 추천수를 합산하여 자동으로 노출됩니다.
댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글수정
댓글 수정은 작성 후 1분내에만 가능합니다.
/ 400
내 댓글 모음
저작권자 © 테크월드뉴스 무단전재 및 재배포 금지