Cortex-M3/M4 응용 프로그램을 위한 문제 해결 도구 RTOS-aware 디버깅과 시리얼 와이어 뷰어(SWV)

Cortex-M3/M4 응용 프로그램을 위한 문제 해결 도구
RTOS-aware 디버깅과 시리얼 와이어 뷰어(SWV)

"백문이 불여일견"이라는 속담에도 있듯이, 이 기고문은 기존의 임베디드 시스템 소프트웨어 디버깅에 시각적 정보를 추가하여 사용하는 것을 주제로 한다. Atollic TrueSTUDIO와 같은 최신의 C/C++ 통합개발환경(IDE)은 응용프로그램의 성능을 가장 정교하게 구현하여 시각화하는 여러가지 방법을 제공하고, 이를 통해 Kernel aware 디버깅과 시리얼 와이어 뷰어(Serial Wire Viewer :SWV)와 같은 고급 디버깅 기술을 확인할 수 있다. Kernel Aware(KA)는 일반적으로 프로세서에 독립적이고, 시리얼 와이어 뷰어(SWV)는 ARM Cortex™ 마이크로컨트롤러에 특별히 적용되었다. 우리는 위의 두 가지 기술과 소프트웨어 품질을 향상시킬 수 있는 방법에 대해서 알아보고자 한다.

글 Mark Moran, Atollic Inc.
번역 : 윤성희 본부장, 이노에스제이㈜

DEBUGGING IN GENERAL
소프트웨어를 디버깅하는 것은 어렵고 힘든 일이다. 소프트웨어 개발 방법에 대한 책은 많이 있지만, 상대적으로 디버깅을 주제로 하는 책들은 그 수가 적다. 가장 뛰어난 디버깅 기술은 베테랑 엔지니어의 머릿속에만 있다. 이러한 디버깅 방법은 기고문, 튜토리얼, 사적인 대화, 멘토링 그리고, 시행착오를 통한 터득 등을 통해서 매우 느리게 전파된다. 각각의 함수와 코드 블록이 주를 이뤄 개발하는 프로젝트 초기단계의 디버깅은 간단하다. 함수 오류의 대부분을 점검을 통해 바로잡거나 Assert() 매크로를 사용하여 잡아낼 수 있다. 그러나 추후에 프로젝트를 통합하고 테스트하는 것은 매우 어려울 뿐만 아니라, 많은 시간이 소요된다. 이것은 제품출시에 대한 극심한 압박으로 작용할 것이다. 물론, 디버깅 사이클을 단축시키는 가장 좋은 방법은 처음부터 버그를 예방하는 것으로 James W. Grenning의 저서 "Test Driven Development for Embedded C"에서 권장하는 방법으로 소개되기도 했다. 다른 방법으로는 코딩시에 엄격하게 표준을 준수하고 코드 리뷰(Code Reviews)를 사용하는 것이다. Atollic TrueSTUDIO짋는 코드 리뷰를 가능하게 하는 도구를 내장하고 있다. 그림 1은 코드 리뷰가 진행되는 동안 "매직넘버(Magic Number)"를 기록하고 해당 위치를 보여준다. 이렇게 발견된 리뷰는 버그가 되거나 그렇지 않을 수도 있다. 그러나 코드를 수정하거나 다른 타깃에 포팅할 때에는 잠재적인 문제가 될 수 있다.

[그림 1] Atollic TrueSTUDIO의 코드 리뷰 툴

SOME HISTORICAL NOTES ON
JTAG DEBUGGING
경험이 풍부한 개발자들은 인서킷 에뮬레이터(In-circuit emulator : ICE)를 디버깅을 위한 표준으로 기억할 것이다. 그러나 인서킷 에뮬레이터(ICE)는 컨트롤러의 클럭 증가로 인하여, 비용 증가와 신뢰성 문제가 발생하여 도태되었다. 그 외에 LED를 깜빡거린다거나 printf() 스타일 디버깅, 롬 모니터링(ROM Monitoring), 롬 에뮬레이터(ROM Emulator), 다양한 백그라운드 디버그 모드(Background debug mode :BDM)에 이르기까지 과거에서부터 지금까지 사용되고 있는 디버깅 방법들이 있다. 그리고 빼 놓을 수 없는 JTAG는 바운더리 스캔(Bounda ry Scan)용으로 개발되어 21세기 임베디드 시스템의 실전 디버깅 기술로 빠르게 자리를 잡았으며, 계속적으로 발전하고 있다.

JTAG 디버깅 기술은 크게 세 부분으로 구성 된다 :

1. 온칩 아이피 블럭(On-chip IP blocks)은 디버깅 정보를 전송하는 것을 가능하게 하고, 호스트 PC의 디버깅 시스템이 칩을 제어할 수 있도록 한다.
2. 디버그 프루브(Debug Probe)는 호스트 PC와 타겟(Target) 사이에 연결되고, 온칩 아이피(On-chip IP)에서 통신채널(UART, USB or LAN)을 통해 호스트 PC에 정보를 전송한다.
3. 호스트 PC상 응용 프로그램은 정보를 송/수신하고 디바이스를 제어하는 것을 시각적으로 표시한다.

오래 전부터 JTAG 디버깅 도구에는 응용 프로그램을 실행하기 위하여 "특정 코드라인까지 실행, 스텝(step)별 실행, 브레이크 포인트(breakpoints) 설정" 등의 메커니즘이 있다. 어떤 경우에는 플래시 메모리에서 사용할 수 있는 브레이크 포인트의 수를 확장할 수 있는 보조 소프트웨어가 있기도 하다. 그리고 응용 프로그램에서 중지(halts)한 후 메모리 위치를 보거나 수정할 수 있다. 온칩 아이피의 확장인 임베디드 트레이스 매크로셀(Embedded Trace Macrocell : ETM)은 명령어와 데이터를 추적하는 것이 가능하다. 이것은 일반적으로 하이엔드급 디버깅에 사용된다.
영국 캠브리지에 소재하고 있는 ARM사에서는 ARM 코텍스 마이크로컨트롤러(Cortex microcontroller)를 위한 코어사이트(CoreSight) 아키텍처를 도입하여 기존 JTAG 디버깅의 기능을 향상시켰다. 참고로, ARM Cortex-M3/M4 마이크로컨트롤러에서는 코어사이트 아키텍처가 모두 구현되지는 않았다. 이것은 Cortex-M3/M4의 저비용 정책을 유지하기 위한 것이다. 그럼에도 불구하고, 개발자가 원하는 특별한 디버깅 기능은 남겨두었다. 이로 인해, 시리얼 와이어 뷰어(SWV)가 가능하게 되었다.

PRACTICAL BENEFITS OF ARM
CORESIGHT TO EMBEDDED DEVELOPERS

코어사이트 아키텍쳐 개발로 인해서 ARM Cortex-M3/M4 마이크로컨트롤러에 실질적인 장점들이 있지만, 몇 가지 유념해야 하는 단점과 제한사항도 있다.
장점
1. 동일한 칩에서 기존의 JTAG보다 적은 핀을 사용
2. 실시간 데이터 보고
3. 인스트럭션 트레이스 매크로셀(Instru ction Trace Macrocell: ITM) 채널을 통한 Printf() 스타일 디버깅
4. 저렴한 디버그 프로브 사용
5. 저전력 모드로 동작
6. 응용 프로그램의 통계 프로파일링(Statistical profiling) 가능
7. 인터럽트와 이벤트 보고 가능
8. 타임 스탬프(Time stamping) 기능으로 쉽게 코드 섹션(Code sections)의 타이밍 측정
단점
1. 1bit로 구성된 SWO핀을 통한 데이터 전송으로 인해 정보 처리량 제한. (특정 부분에서 4bit로도 구성할 수 있지만, 디버그 프로브의 비용이 급격히 증가됨)
2. 실시간 데이터 모니터링은 칩의 비교기 수에 제한됨
(일반적으로 4개)
3. 명령어 추적(Instruction trace) 부분을 4-pin으로 구성하는 것은 가능하지만, 데이터 추적(Data tracing)이 불가함
기존 JTAG의 방식과 코어사이트 디버깅 방식을 각각의 그림으로 비교해 보도록 하자.
그림 2는 변수, 브레이크포인트, 메모리, CPU 코어 및 특수기능 레지스터를 보여준다.

[그림 2] 기존 JTAG의 실행/중지 디버깅 방식

[그림3]은 다음과 같은 추가정보를 포함하고 있다 :
1. Core에 부하가 없는 메모리 위치의 실시간 그래프(X-Y-Z 가속도계 변수값)
2. 어떤 응용 프로그램의 소비 시간에 대한 통계적 프로파일
3. 가속도계 서비스 태스크로부터 ITM port를 통한 Printf() 출력
4. 모든 시스템 인터럽트와 예외처리(상세설명 포함)의 시간 인덱스 기록
5. 인터럽트와 예외처리에 대한 통계

[그림 3] 실시간 데이터 보고 기능과 시리얼 와이어 뷰어(SWV) 디스플레이

위 기능의 근본적인 역할은 정보를 한눈에 볼 수 있다는 것이고, 개발자는 이를 통해 응용 프로그램의 상태를 빠르게 볼 수 있다. 그리고 다음과 같은 질문에 답을 얻을 수 있을 것이다.

1. 실시간으로 변하는 센서의 데이터가 예상했던 것과 일치합니까?
2. 제시간에 인터럽트가 발생하여 올바른 순서대로 진행되었습니까?
3. 응용 프로그램의 특정 함수 또는 특정 코드에서 프로세서의 시간을 과도하게 사용합니까?

위의 기능은 모든 응용 프로그램의 다양한 컴포넌트로 매우 가치 있는 정보를 가지고 있다. 예를 들어, 디바이스 드라이버, 응용 프로그램 코드, RTOS와 TCP/IP Stack, 임베디드 플래시 파일 시스템 그리고, USB Stack 등이 묶여 있을 경우, 관련이 없어 보이는 다른 문제의 원인이 될 수도 있다. 이러한 경우에 우리는 효율적으로 원시 데이터(Raw Data)를 정보로 바꿀 수 있다. 그리고 다양한 잠재적인 문제들을 배제하여 간단하고 신속하게 검사할 수 있다.

USING RTOS IN EMBEDDED APPLICATIONS AND EFFECT ON DEBUGGING

임베디드 시스템에 RTOS를 사용했을 때, 그에 대한 장·단점이 있다. 이것에 대한 논의는 여러 기고문과 백서, 포럼 그리고, 많은 개발 그룹 내에서 수년 동안 진행되었다. 최근에는 Cortex-M3/M4와 같은 프로세서에 RTOS의 적용이 늘어나고 있다. 한가지 흥미로운 점은 예전에는 RTOS를 사용하는 것 자체가 디버깅시에 장애물로 간주되기도 했다. Michael Melkonian의 "Getting by Without an RTOS" 기고문[Embedded Systems Programming VOL. 13 NO. 10 September, 2000]에서 "많은 인서킷 에뮬레이터와 디버거는 RTOS에서 안정적인 동작이 어렵고, 커널 코드의 리스케쥴링(Rescheduling) 동안에는 브레이크포인트(Breakpoint)의 사용을 피해야 하는 불편한 상황이 발생한다"고 주장했다. 이러한 흥미로운 논평은 그 시대를 분명하게 보여 주었다. 이전에 설명한 바와 같이, 이미 인서킷 에뮬레이터(ICE)의 시대는 지나갔다. 하지만 흥미롭게도 그 사고방식은 그대로 남아 있다. 아직도 RTOS를 사용하는 것은 디버깅 문제에 많은 어려움이 있을 것이라고 두려워한다. 그러나 우리는 과거의 인서킷 에뮬레이터가 아닌 JTAG와 시리얼 와이어 뷰어를 통해 안정적으로 RTOS에서 동작하는 응용 프로그램을 디버깅을 할 수 있다.
RTOS의 사용이 디버깅 문제에 미치는 영향을 평가하는 올바른 방법은 RTOS 기반 응용 프로그램을 디버깅할 때 어떠한 정보들이 필요한지를 미리 고려하는 것이다.

모든 RTOS는 다음과 같은 특징이 있다.

1. RTOS에 의해 관리되는 개별 태스크 내 응용 프로그램에서의 정지
2. 태스크를 생성, 관리 그리고 삭제할 수 있는 API의 사용
3. 내부 태스크 간 통신 및 동기화를 위한 다양한 매커니즘을 사용
4. 시간 관리 기능이 제공되는 RTOS의 사용

기존 디버깅 방식의 개발자는 일반적으로 변수값, 레지스터값, SFR의 비트 패턴, 스텝(step)마다 응용 프로그램이 어떻게 동작하는지 등 정확하게 로우레벨(Low-level)의 세부사항을 알고 싶어한다. RTOS를 디버깅 할 때 고려해야 할 정보는 다음과 같다.

1. 언제 중지(halted)되었고, 현재 TASK의 상태는 어떠합니까?
2. 어떤 TASK에서 실행중(Running)이고, 어떤 TASK가 준비(Ready) 상태이고, 어떤 TASK가 대기(Waiting) 상태입니까?
3. 만약 대기중(Waiting)인 상태라면, 어떤 자원(resources)에서 TASK들이 대기중입니까?
4. 세마포어(Semaphores)와 뮤텍스(Mutexes)와 같은 동기화 객체를 얼마나 많이 사용하고 있습니까? 그 객체들의 현재 상태는 어떻습니까?
5. 어떤 이벤트와 메시지가 있습니까? 이들 객체들의 상태는 어떻습니까?
6. 만료된 타이머들은 어떤 것이 있습니까? 계속 실행중인 타이머는 무엇입니까?

위의 질문을 충족시키기 위해 발전된 시각화 도구에 대한 요구가 생겼으며, 디버깅 및 통합 테스트를 수행할 때 그 요구가 만족되어야 한다.
Kernel aware 디버깅에서 "Kernel aware"의 개념은 "코드 객체(code object)의 특정 정보"가 아닌 "RTOS 객체의 정보"이다.
그림4는 여러 정보를 한눈에 볼 수 있는 Kernel aware 디버깅 윈도우이다.

[그림 4] embos Operating system의 Kernel aware 디비깅 윈도우

UNITING KERNEL AWARE DEBUGGING WITH SERIAL WIRE VIEWER

Kernel aware 디버깅의 근본적인 문제는 기존의 JTAG에 있다. TASK 상태, 세마포어, 메시지와 이벤트 등 RTOS의 특정 정보를 보기 위해서는 반드시 응용 프로그램을 중지(halt)해야 하기 때문이다. 특히 모터 컨트롤러와 같은 테스트의 경우에 이것은 좋은 방법이 아니고, 때로는 하드웨어에 손상을 주기도 한다.
이 문제를 해결하기 위한 방법은 시리얼 와이어 뷰어(SWV)를 사용하여 동적으로 RTOS의 특정 정보를 제공받는 것이다. 물론 제약은 있지만, 종종 RTOS aware objects에 대한 결정적인 정보를 제공받을 수 있다.

그림4의 오른쪽 상단 모서리에 있는 창은 시리얼 와이어 데이터 트레이스 타임라인(Data Trace Timeline) 그래프이다. 이것은 메일박스의 메시지 수를 가지고 시간에 따른 데이터 필드의 변화를 그래프로 보여준 것이다. 메시지는 일반적으로 TASK가 다른 TASK에게 정보를 제공하기 위해서 생성한다. 정보를 보내려는 TASK는 메시지를 메일박스에 입력하고, 정보를 받는 TASK에서는 메시지를 추출하고 사용한다.(단, 정보를 받는 TASK에서 메시지를 확인할 때까지 가려져 있다.)
이 검사를 통해서 메일박스에서 메시지가 소비되는 일반적인 패턴을 볼 수 있다.
완벽하지는 않지만, 시리얼 와이어 데이터 트레이스 타임라인 그래프에 그려지는 파형으로 정확한 동작을 하는지 추측할 수 있다. 어떠한 문제가 불쑥 나타난다면, 그래프를 보고 바로 알 수 있다. 이 데이터는 프로세서에 부하를 주지 않는 실시간 정보라는 점을 기억해야 한다.
이 데이터는 응용 프로그램이 실제 환경에서 실행되는 동안에도 모니터링할 수 있다. 덧붙여 화면의 축이 시간단위로 표시되어 있으므로, 소프트웨어 테스터는 테스트 중에 오류가 발생했을 때 정확하게 알 수 있고, 그 오류의 원인을 찾는데 중요한 단서가 될 수 있다.
Atollic TrueSTUDIO의 목표 중 하나는 개발자들이 개발하는데 필요한 "추가적인 툴"의 수를 최소화하는 것이다. 앞에서 언급한 코드 리뷰뿐만 아니라, 버전 컨트롤과 버그 트래킹 데이터베이스 클라이언트가 완벽하게 통합되어 있다. 그리고 코드 분석과 테스트 자동화와 같은 옵션 모듈을 추가하여 사용할 수 있다.
TCP/IP 응용 프로그램에서는 함수에 전송되는 패킷 정보에 관심이 많을 것이다. WireShark와 같은 툴은 이러한 목적을 위해 사용된다. 이 정보를 통해 현재상태("Still talking/Listening")와 통신상에 문제가 있는지 여부를 알 수 있다. 그림 5를 보면, TrueSTUDIO에서는 데이터 트레이스 타임라인 그래프(Data Trace Timeline Graph)로 이 정보를 표시하여 통신 상태에 대해 대략적으로 추측을 할 수 있다. 이것은 TCP/IP 응용 프로그램 또는 서비스에서 중요한 통계 자료이다. 그리고, SWV를 이용하여 필요한 정보를 가시화 할 수 있다. 즉, TrueSTUDIO짋 상에서 테스팅, 디버깅과 데이터 수집까지 모두 가능하다.