[첨단 헬로티]

ETM Trace 

마이크 로컨트롤러(MCU)의 제어를 위한 펌워어, 소프트웨어를 작성하고 디버깅하다보면 원인을 알 수 없는 문제에 직면하는 경우가 많이 있다. 이러한 경우 일반적인 디버거는 문제가 발생하고 문제를 인식했을 때의 상황만 확인 가능한 반면 Trace 기능을 이용하면 문제 발생 이전의 상황이 확인 가능해 문제 발생의 경로까지 알 수 있다. Trace 기능의 실제 사용 횟수는 많지 않지만 훨씬 버그를 찾아내고 해결하는데 효과적이다.

Embedded Trace Macrocell(ETM)은 애플리케이션에서 실행되는 모든 명령어를 기록하고 마이크로 컨트롤러의 명령 수행에 대한 모든 정보를 제공한다. 이번 글에서는 ETM 기술이 수행에 대해 설명하고 ETM Trace가 도움이 될 수 있는 방법 관련 예제를 통해 설명하겠다.

ETM Trace는 고속으로 실행 이력 저장이 가능하며 가장 어려운 문제를 해결하는 데 도움되는 다양한 디버그 모드를 제공한다. ETM  Trace의 가장 큰 특징 중 하나는 코드 수행에 방해가 되지 않는다는 것이다. 즉, 시스템 실행에 영향을 미치지 않고 코어의 모든 명령어의 실행 이력을 저장할 수 있다. 

코드 범위, 최적화, 디버깅은 ETM Trace를 통해 코드를 심층적으로 파악하고 최적화하는 방법이다. 디버깅의 효율성이 올라가면 개발 비용과 시간의 절약되는 효과를 얻을 수 있다. ETM을 사용하려면 IAR시스템즈의 I-jet Trace와 같이 메모리에 명령을 저장할 수 있는 Trace 기능이 포함된 디버그 프로브가 필요하다. I-Jet Trace는 IAR 임베디드 워크벤치(Embedded Workbench)와 함께 Trace 기능을 제공하고 있다. 

ETM Trace 활용하기 

LED가 깜빡여야하지만 LED가 깜박이지 않는 시나리오를 예제로 들어 설명하겠다. 

이 예제 애플리케이션은 일반적인 디버거 사용으로 버그를 해결하는데 많은 어려움이 있어 Trace를 활용해 버그를 찾아 해결한다. 

예제를 설명하기 전 몇 가지 요구 사항을 알고 있어야 한다. ETM Trace를 사용하려면 대상 보드에 ETM이 있는 ARM Cortex 디바이스가 필요하다(예 : ARM Cortex -M3 코어에서 ETM은 선택적 구성 요소 임). 또한 ARM Cortex 디바이스의 ETM Trace 핀은 보드의 디버그 커넥터와 연결해야한다. 모든 평가 보드에 항상 Trace 핀이 연결되는 것은 아니니 확인이 필요하다. 

찾기 어려운 버그

[그림 1]의 예제 애플리케이션에서는 blink_LED 함수에서 LED가 주기적으로 깜박인다. 변수 led_state는 LED 상태를 유지하며 1과 0 사이를 토글한다. 프로젝트의 다음 스크린 샷을 참조해라. 

▲ 사진 1.

이 매우 간단한 응용 프로그램은 잘 작동해야 하지만 타깃 디바이스에서 실행될 때 LED가 약 30 초 동안만 깜박이면 LED가 꺼진다.

main.c에서 소스 코드를 검사하면 문제의 원인을 알 수 없다. 아마도 board_init 함수에 응용 프로그램이 오작동을 일으킬 수 있는 무언가가 있을 수 있다. 하지만 이 함수는 보드 지원 라이브러리(boardlib.a)에서 가져온 거대하고 복잡한 라이브러리라고 가정해 보자. 

문제를 더 자세히 조사하기 위해 ETM Trace가 도움이 될 수 있다. I-jet Trace 프로브를 보드에 연결하고 디버깅을 시작하면 디버그 로그 창에서 다음과 비슷한 메시지가 표시된다.

위의 로그 메시지는 프로브 연결이 고속 USB 3.0 모드(이 경우 384MB/초)를 사용 중이다는 것을 나타낸다. 또한 Flash 다운로드가 완료되고 확인됐다는 것을 알려준다. trace : 보정 라인은 프로브가 90 MHz ETM 클럭을 성공적으로 감지했음을 나타낸다. 그런 다음 LED가 깜박임을 멈출 때까지 응용 프로그램을 실행 시킨다. 이 경우 blink_LED 함수에 브레이크 포인트를 설정한다. 

브레이크포인트가 트리거 될 때 Watch 창에 예상대로 led_state (항상) 0이 표시된다[그림 2]. 바로 위의 토글 코드가 실행되면 1또는 0으로 변경될 것이다. 

▲ 사진 2.

이를 알아 내기 위해 I-jet / JTAGjet> Function Trace 창을 열어 이전에 응용 프로그램에서 어떤 일이 있었는지 확인할 수 있다. 기능 추적 창에서 찾아보기 모드를 두 번 클릭해라. 찾아보기 모드에서 창은 노란색으로 변하고 키보드 화살표 버튼을 사용해 뒤로 또는 앞으로 이동할 수 있다[그림 3]. 

▲ 사진 3.

Trace 데이터에서 몇 단계 뒤로 거치면 이전에는  보지 못했던 함수 인 SysTick_Handler 함수로 이동한다[그림 4].

▲ 사진 4.

그리고 여기서 문제점의 원인과 해결책을 찾을 수 있다. 시스템 틱 인터럽트 처리기 기능은 주기적으로 실행되도록 구성돼 있고 여러 틱 수(약 30 초) 후에 주소 0x20000004에 정수 값을 쓸 것이다. 그곳은 led_state 변수의 주소다. led_state 변수의 값이 시스템 틱 인터럽트 핸들러에 의해 주기적으로 덮어 쓰여지고 LED가 깜박 거리지 않는다는 것을 의미한다. (Trace의 기능 설명을 위해 임의로 만들어 놓은 버그다.)

분명히 이 예제는 실제의 버그 사례는 아니지만, Trace 기능이 애플리케이션 코드에서 이상한 버그를 찾는데 유용한 도구가 될 수 있다는 것을 보여준다. 

맺음말

Trace 는 코드 디버깅에 있어 반드시 필요한 장비·기능은 아니다. 또한 아주 자주 사용하는 기능도 아니다. Cortex 코어 출시로 MCU에 많은 디버깅을 위한 기능들이 추가되고 디버거의 기능이 많은 향상을 이뤄 이 전 보다 훨씬 수월하게 버그를 찾아내고 수정할 수 있다. 하지만 위의 예제와 같이 문제발생의 원인과 해결을 위해 코드의 실행 흐름을 파악할 필요가 있는 경우가 있다. 일반적으로 HardFualt가 발생한 경우가 속한다. 이런 경우 Trace 장비/기능의 사용이 가능하다면 버그를 찾아내고 수정하는데 많은 도움이 될 것이다. 

글 : 이현도 IAR 시스템즈(IAR Systems) 기술지원팀 과장(Hyun-Do.Lee@iar.com)