ETM 트레이스를 이용한 임베디드 환경의 디버깅
상태바
ETM 트레이스를 이용한 임베디드 환경의 디버깅
  • 정환용 기자
  • 승인 2018.11.19 13:28
  • 댓글 0
이 기사를 공유합니다

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

임베디드 트레이스 매크로셀(Embedded Trace Macrocell, 이하 ETM)은 애플리케이션에서 실행되는 모든 명령어를 기록하고 마이크로 컨트롤러의 명령 수행에 대한 모든 정보를 제공한다. 이번 글에서는 ETM 기술이 수행할 수 있는 것을 설명하고, ETM 트레이스가 도움이 될 수 있는 방법을 보여주는 예제를 통해 설명하겠다.

ETM 트레이스는 고속으로 실행 이력을 저장할 수 있고, 가장 어려운 문제를 해결하는 데 도움이 되는 다양한 디버그 모드를 제공한다. ETM 트레이스의 가장 큰 특징 중 하나는 코드 수행에 방해가 되지 않는다는 것이다. 즉, 시스템 실행에 영향을 미치지 않고 코어의 모든 명령어의 실행 이력을 저장할 수 있다. 코드 범위, 최적화, 디버깅은 ETM 트레이스를 통해 코드를 심층적으로 파악하고 최적화하는 방법이다. 디버깅의 효율성이 올라가면 개발 비용과 시간의 절약되는 효과를 얻을 수 있다. ETM을 사용하려면 IAR 시스템(IAR Systems)의 ‘I-jet Trace’와 같이 메모리에 명령을 저장할 수 있는 트레이스 기능이 포함된 디버그 프로브가 필요하다. I-Jet Trace는 IAR 임베디드 워크벤치(IAR Embedded Workbench)와 함께 트레이스 기능을 제공한다.

 

ETM 트레이스 활용하기
다음 예에서는 LED가 깜빡여야 하지만 LED가 깜박이지 않는 시나리오다. 이 예제 애플리케이션은 일반적인 디버거 사용으로 버그를 해결하는데 많은 어려움이 있어, 트레이스를 활용해 버그를 찾아내고 해결하는 것이 좋다.

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

 

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

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

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

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

 

Probe: I-jet-Trace-ARM detected.
Probe: Opened in USB 3.0 mode
Probe: I-jet-Trace, FW ver 2.5 (2016/08/25, USB 2016/01/25), HW Ver:B
Probe: USB reading speed 384.0 MB/sec Data verified.
Download completed and verification successful.
Trace: ETMv3CM powered-up OK (ETMCR=0xc10)
Trace: Configured to collect ETM trace via MIPI-20 connector, 256MB trace memory used
Trace: Calibration [4-bit,tclk=90.00MHz,auto]: OK=#0,
pattern=++++++++++++++++++++++++++++++C++++++++++++++++++++++++++++++
Trace: ETM read and validated (256B in 2ms - total 256B kept)

 

▲[그림 1]

이 로그 메시지는 프로브 연결이 고속 USB 3.0 모드(이 경우 384MB/s)를 사용하고 있는 것을 나타낸다. 또한, 플래시(Flash) 다운로드가 완료되고 확인됐음을 알려준다. trace: 보정 라인은 프로브가 90MHz ETM 클럭을 성공적으로 감지했음을 나타낸다.

그런 다음 LED가 깜박임을 멈출 때까지 응용프로그램을 실행시킨다. 이 경우 blink_LED 함수에 브레이크 포인트를 설정한다[그림 2].

▲[그림 2]

브레이크 포인트가 트리거될 때 Watch 창에 예상대로 led_state (항상) 0이 표시된다. 바로 위의 토글 코드가 실행되면 1 또는 0으로 변경될 것이다. I-jet / JTAGjet> Function Trace 창을 열어 이전에 응용 프로그램에서 어떤 일이 있었는지 확인할 수 있다. 기능 추적 창에서 찾아보기 모드를 두 번 클릭한다. 찾아보기 모드에서 창은 노란색으로 변하고 키보드 화살표 버튼을 사용해 뒤로 또는 앞으로 이동할 수 있다[그림 3].

▲[그림 3]

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

▲[그림 4]

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

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

맺음말
트레이스는 코드 디버깅에 있어 반드시 필요한 장비나 기능은 아니다. 또한, 매우 자주 사용하는 기능도 아니다. 코어텍스 코어 출시로 MCU에 많은 디버깅을 위한 기능들이 추가되고 디버거의 기능이 많이 향상돼, 이전보다 훨씬 수월하게 버그를 찾아내고 수정할 수 있다.

하지만 위의 예제와 같이 문제 발생의 원인과 해결을 위해 코드의 실행 흐름을 파악할 필요가 있는 경우가 있다. 일반적으로 HardFualt가 발생한 경우가 그렇다. 이런 경우 트레이스 장비와 기능을 사용할 수 있다면, 버그를 찾아내고 수정하는데 많은 도움이 될 것이다.

 

작성: IAR Systems 이현도 과장