준비 키트( Preparation Kit)download.microsoft.com/download/0/B/9/0B98A0AE-C7AF... · 윈도우...

i

Windows Embedded CE 6.0

CTSMExam 70-571

전매 금지.

인증 시험 준비준비 키트(Preparation Kit)

R2 콘텐츠로

업데이트

됨

ii

발행인

Microsoft Corporation

One Microsoft Way

Redmond, Washington 98052-6399

이 문서는 정보용입니다 . MICROSOFT 는 이 문서에 포함된 정보에 대해 ( 직접 , 간접 , 특별한 )그 어떤 보증도 하지 않습니다 . 이 문서에 포함된 정보는 발행일을 기준으로 토론된 문제점에 대한 Microsoft Corporation 의 현재 관점을 대표합니다 . Microsoft 는 변하는 시세에 대처해야 하기 때문에 정보에 대한 책임을 질 수 없으며 발행일 이후에 제공되는 정보의 정확성을 보장할 수 없습니다 . URL 과 기타 인터넷 웹사이트 참고 자료를 포함하여 이 문서에 있는 정보는 통보없이 변경될 수 있습니다 .

모든 적용되는 저작권 법을 준수하는 것은 사용자의 책임입니다 . 저작권 하에 권리 제한이 허용되지 않는 한 , Microsoft Corporation 의 명시적 서면 허가없이 이 문서의 그 어느 일부도 그 어떤목적으로든 무단으로 복제 , 검색 시스템으로 저장 또는 입력 , 또는 그 어떤 형태나 방식으로 전송( 전자 , 기계 , 복사 , 기록 , 또는 기타 ) 될 수 없습니다 . Microsoft 는 이 문서상에 언급된 주제에관련된 특허 , 특허 응용 프로그램 , 등록 상표 , 저작권 또는 기타 지적 재산권을 소유할 수 있습니다 . Microsoft 와의 서면 사용권 계약에 명시적으로 나타나 있지 않은 이상 , 이 문서의 제공으로인해 이러한 특허 , 등록 상표 , 저작권 및 기타 지적 재산권에 대한 그 어떤 사용권도 부여되지 않습니다 .

저작권 © 2008 Microsoft Corporation. 모든 권리 소유 .

Microsoft, ActiveSync, IntelliSense, Internet Explorer, MSDN, Visual Studio, Win32,Windows 및 Windows Mobile 은 Microsoft 회사 그룹의 등록 상표입니다 . 이 문서에 언급된 회사와 제품의 실제 이름은 해당 소유자의 상표일 수 있습니다 .

용례에 사용된 회사 , 기관 , 제품 , 도메인 이름 , 전자 메일 주소 , 로고 , 사람 , 장소 및 이벤트는 다른 설명이 없는 한 실제 데이터가 아닙니다 . 어떠한 실제 회사 , 기관 , 제품 , 도메인 이름 , 전자 메일 주소 , 로고 , 사람 , 장소 또는 이벤트와도 연관시킬 의도가 없으며 그렇게 유추해서도 안 됩니다 .

인수 편집인 : 산드라 웨버 (Sondra Webber), Microsoft Corporation

저자 : 니콜라스 베슨 (Nicolas Besson), Adeneo Corporation레이 마르실라 (Ray Marcilla), Adeneo Corporation라제쉬 캐이드 (Rajesh Kakde), Adeneo Corporation

집필 감독 : 워런 루보 (Warren Lubow), Adeneo Corporation

기술 검수인 : 브리지트 후왕 (Brigette Huang), Microsoft Corporation

편집 제작 : Biblioso Corporation

본문 번호 X00-00000

iii

간단한 내용

서문 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

1 운영체제 디자인 설계 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 런타임 이미지 빌드와 배포 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 시스템 프로그래밍 실행 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4 디버깅 및 시스템 테스트 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

5 보드 지윈 패키지의 사용자 지정 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

6 장치 드라이버 개발 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

용어 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

색인 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

저자에 대하여 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

145

제 4 장

디버깅 및 시스템 테스트

디버깅과 시스템 테스트는 시스템 개발 주기에 있어서 중요한 작업이다 . 소프트

웨어와 하드웨어적인 결함을 찾아내고 해결하는 것을 궁극적인 목표로 한다 . 디

버깅의 의미는 코드를 단계적으로 실행시키거나 출력된 디버깅 메시지를 분석하

여 오류의 윈인을 분석하는 과정을 의미한다 . 시스템 구성요소에 대한 구현과 일

반적인 어플리케이션에 대해서 공부하는 것은 디버깅과 테스트를 위한 좋은 방

법 중 하나이다 . 또 한 편으로는 , 시스템 테스트는 일반적인 사용 시나리오 , 성

능 , 안전성 , 보안 , 그리고 기타 관련성이 있는 측면에서 그것의 최종 구성으로

시스템의 유효성을 검증하는 품질 - 보증 활동이다 . 시스템 테스트의 전체 목적

은 , 메모리 누수 , 교착 상태 , 또는 하드웨어 충돌 같은 제품 결함과 오류를 발견

하는 것이다 . 반면에 디버깅은 이러한 문제의 윈인을 규명하고 그들을 제거하는

것이다 . 소형 임베디드 시스템의 시스템 결함을 확인하고 제거하는 일은 대부분

의 개발자들에게도 어려운 부분중의 하나이다 . 이 장에서는 윈도우 임베디드 CE

6.0 R2 를 위한 개발 환경인 플랫폼 빌더 ( 마이크로소프트 비주얼 스튜디오®

2005 설치되어 있는 ) 에 있는 툴을 이용하여 디버깅과 테스트 하는 방법에 대해

다룬다 . 이 툴들은 디버깅 및 테스트 과정을 자동화 하고 보다 빠르게 하여 개발

하는 시스템을 보다 버그가 없는 시스템을 릴리스 할수 있도록 도와준다 . 또한

윈도우 임베디드 CE 테스트 키트 (CETK) 를 사용하여 테스트 자동화 방법에 대

해 설명한다 . 이러한 툴들에 대해 좀더 마스터할수록 코드를 수정하는 대신 코드

를 작성하는데 좀더 시간을 활용할 수 있다 .

이 장에서의 학습 목표 :

■ 런타임 이미지 디버깅을 위한 요구 사항을 식별

■ 코드 실행 분석을 위한 디버거 기능의 사용

■ 디버그 메시지의 출력을 관리하는 Debug Zone 에 대한 이해

■ CETK 툴을 이용하여 기본 테스트 및 사용자 정의 테스트 하기

■ 부트 로더와 운영 체제 (OS) 의 디버깅

146 제 4장 디버깅 및 시스템 테스트

시작하기 전에이 장의 학습을 완벽하게 이해하려면 , 사용자는 반드시 다음 과정을 하여야 한다 .

■ 윈도우 임베디드 CE 소프트웨어 개발 및 디버깅 개념에 관한 최소한의 기초

지식

■ 윈도우 임베디드 CE 지윈하는 드라이버 아키텍처의 기본적 이해

■ OS 디자인 및 시스템 구성 개념에 관한 지식

■ 플랫폼 빌더가 통합된 윈도우 임베디드 CE 6.0 R2 와 마이크로소프트 비주

얼 스튜디오® 2005 서비스 팩 1 이 설치된 개발용 컴퓨터 .

제 1 과 : 소프트웨어 관련 오류 찾아내기 147

제 1과 : 소프트웨어 관련 오류 찾아내기소프트웨어 관련 오류 범위는 단순 오타 , 초기화되지 않은 변수 및 무한 루프에

서부터 중요한 경합 조건 (Critical Race Condition) 과 다른 쓰레드 동기화 문제

같은 더욱 복잡하고 난해한 문제까지 이른다 . 다행히도 , 한번에 대부분의 오류

위치를 수정하는 것은 용이하다 . 이러한 오류를 발견하는 가장 효과적인 비용 절

감 방법은 코드 분석을 통해서 이루어진다 . 사용자는 운영체제 디버깅뿐만 아니

라 드라이버와 어플리케이션 디버깅에까지 윈도우 임베디드 CE 장치의 다양한

도구를 사용할 수 있다 . 이러한 디버깅 도구의 완벽한 이해는 사용자가 코드 분

석을 빨리 하는 것을 도와 소프트웨어의 오류를 가능한 효율적으로 수정할 수 있

도록 한다 .

이 과정을 마치면 , 사용자는 다음과 같은 일을 할 수 있다 .

■ 윈도우 임베디드 CE 를 위한 중요한 디버깅 도구 식별 .

■ 드라이버와 응용 프로그램을 디버그 영역을 통한 디버그 메시지를 제어 .

■ 메모리 문제를 확인하기 위한 Target Control 의 사용 .

예상 학습 시간 : 90 분 .

디버깅 및 타겟 장치 제어윈도우 임베디드 CE 타겟 장치를 디버그하고 제어하는 주요한 도구는 그림 4-1

과 같이 개발용 워크스테이션에서 실행하는 플랫폼 빌더 이다 . 플랫폼 빌더 통합

개발 환경 (IDE) 는 디버깅 중 중단점에 멈춘 후 코드를 단계적으로 실행시키게

하거나 메모리 , 변수 , 의 정보를 표시하게 할 수 있다 . CE 타겟 제어 쉘 (CESH),

그리고 디버그 메시지 (DbgMsg) 기능과 같은 다양한 도구를 포함한다 . 플랫폼

빌더 IDE 는 런타임 이미지에서 타겟 장치의 상태를 분석하는 Heap Walker,

Processor Viewer, 그리고 kernel Tracker 와 같은 윈격 도구의 컬렉션을 포함

한다 .


그림 4-1 CE 디버깅 및 Target Control 구조

타겟 장치와 통신하기 위해서 , 플랫폼 빌더는 타겟 장치의 이미지에 포함된 디버

깅 컴포넌트와 코어 연결 (CoreCon) 인프라스트럭처를 이용한다 . CoreCon 인

프라스트럭처는 OS 접근 (OsAxS), Target Control, DbgMsg 서비스를 플랫폼

빌더에게 그리고 타겟 장치에는 Kernel Independent Transport Layer(KITL)

과 Bootstrap 서비스 인터페이스를 제공한다타겟 장치 . 타겟 장치에서는 디버깅

과 타겟 제어를 위해서는 KITL 을 사용하고 통신을 위해서는 부트 로더를 이용

한다 . 커널 디버거 스텁 (KdStub), 하드웨어 디버거 스텁 (HdStub), 그리고

OsAxS 라이브러리 같은 디버깅 컴포넌트를 런타임 이미지가 포함한다면 , 사용

자는 커널 런타임 정보를 얻고 Just-In-Time(JIT) 디버깅을 수행하기 위해 플

랫폼 빌더를 사용할 수 있다 . 사용자가 커널을 로드 하기 전에 타겟 장치 루틴을


디버그 할 수 있도록 , 플랫폼 빌더는 또한 확장 디버깅 인터페이스 (eXDI) 통한

하드웨어 지윈 (hardware-assisted) 디버깅을 지윈한다 .

커널 디버거 커널 디버거는 커널 구성요소와 CE 응용프로그램을 디버깅 할 수 있게 하는 CE

소프트웨어 - 디버깅 엔진이다 . 개발용 위크스테이션에서 설치된 플랫폼 빌더를

이용하여 어플리케이션을 실행시키거나 디버깅 하기 위해 소스 코드에 중단점을

삽입하거나 삭제하는 작업을 직접할 수 있을 작업을 한다 . 그러나 플랫폼 빌더가

디버깅 정보를 잡을 수 있고 타겟 장치를 관리할 수 있도록 사용자는 KITL 을 지

윈할 수 있도록 런타임 이미지에 디버깅 라이브러리 (KdStub 과 OsAxS) 을 포함

해야 한다 . 이 장의 뒤에 있는 “디버깅 활성화를 위한 런타임 이미지 구성” 에

서 커널 디버깅에 대한 시스템 구성의 상세한 정보를 제공한다 . 다음의 타겟 중

심의 구성요소는 커널 디버깅에 필수적이다 .

■ KdStub 예외와 중단점을 캡처, 커널 정보의 검색과 커널 작업을 수행한다.

■ OsAxS 메모리 할당에 관한 정보 , 활성 프로세스 및 쓰레드 , 프록시

(proxies), 그리고 로드 된 동적 - 링크 라이브러리 (DLLs) 같이 운영 체제

의 상태에 대한 정보를 검색한다 .

참고 윈도우 임베디드 CE 의 응용프로그램 디버깅

커널 디버거를 이용하여 사용자는 전체 런타임 이미지 뿐만 아니라 개개의 어플리케이션을 제어할 수있다 . 그러나 KDSTUB 는 제 3 장 “시스템 프로그래밍의 수행”에서 설명한 첫 FIRST-CHANCE 예외와SECOND-CHANCE 예외를 받는 커널 구성요소이다 . 만약 사용자가 타겟 - 사이트 KDSTUB 모듈을 먼저 멈추지 않고 커널 디버거를 멈춘 상태에서 예외가 발생한다면 , 런타임 이미지는 디버거를 다시 연결할때까지 응답을 하지 않을 것이다 . 그 이유는 커널 디버거가 제대로 예외를 처리해야 타겟 장치가 계속 실행 할 수 있기 때문이다 .

디버그 메시지 서비스플랫폼 빌더에서 , 사용자가 KITL 와 KdStub- 활성화된 타겟 장치에 연결할 때 ,

사용자는 마이크로소프트 비주얼 스튜디오 2005 의 출력 윈윈도우에서 나오는

디버그 정보를 확인할 수 있다 . 풀랫폼 빌더는 CoreCon 인프라스트럭처의

DbgMsg 서비스를 이용하여 타겟 장치로부터 얻어지는 정보이다타겟 장치 . 디

버그 메시지는 실행중인 프로세서 정보 , 잘못된 입력과 같은 잠재적으로 중요한

문제를 일으킬만한 정보 , 오류가 발생할 만한 코드 위치에 대한 힌트를 준다 . 이

후 이 정보를 이용하여 커널 디버거를 이용하여 중단점을 설정하고 디버깅을 통

해 코드의 문제점을 확인할 수 있다 . 커널 디버거 스텁 (Stub) 의 기능 중 하나는

디버그 메시지의 동적 관리 지윈이다 . 그래서 사용자는 소스 코드 변경 없이 디

버그 메시지의 출력을 다양하게 구성할 수 있다 . 다른 것들 중에서 , 사용자가 비


주얼 스튜디오 안에 타겟 메뉴의 디버그 메시지 옵션 선택을 통해 사용자는

Timestamps, Process ID, 또는 Thread ID 를 배제할 수 있다 . 사용자는 또한

별도의 도구를 가지고 분석을 위한 파일에 대해 디버그 출력을 보낼 수 있다 . 타

겟 장치에서 , 모든 디버그 메시지는 NKDbgPrintf 함수를 통해 출력 스트림 ( 화

면이나 파일 ) 에 직접 보내진다 .

참고 KITL 과 KITL 없는 디버그 메시지

커널 디버거와 KITL 모두가 활성화된 경우 , 디버그 메시지를 비주얼 스튜디오의 OUTPUT WINDOW 에 출력된다 . 만약 KITL 을 사용할 수 없는 경우 , 디버그 정보는 타겟 장치에서 개발용 컴퓨터로 OAL(OEMADAPTATION LAYER) 을 이용한 시리얼 포트를 통해 전달된다 .

디버그 메시지를 위한 매크로

디버그 정보를 생성시키기 위하여 , 윈도우 임베디드 CE 는 디버그 매크로와 리테

일 매크로 두 범주로 일반적으로 나누어 지며 , 여러가지 디버깅 매크로를 제공한

다 . 리테일 매크로 가 디버그와 리테일 빌드 구성 (WINCEDEBUG= 리테일 ) 양쪽

모두 정보를 생성시키는 반면에 사용자가 Ship 구성 (WINCESHIP=1) 으로 런타임

이미지를 구축하지 않으면 , 디버그 빌드 구성 ( 환경변수 WINCEDEBUG=debug)

에서 단지 디버그 매크로 출력 정보만 컴파일 된다 . Ship 구성 , 모든 디버깅 매크

로는 사용할 수 없다 .

표 4-1 은 사용자가 디버그 정보를 생성하기 위하여 사용자의 코드에 삽입할 수

있는 디버깅 매크로를 요약한 것이다 .

표 4-1 디버깅 메시지 출력을 위한 윈도우 임베디드 CE 매크로

매크로 설명

DEBUGMSG 런타임 이미지가 디버그 빌드 옵션으로 컴파일 되면 printf-style 디버그 메시지를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 .

리테일 MSG 런타임 이미지가 디버그 또는 릴리스 빌드 옵션으로 컴파일 되었고, 그러나 Ship 빌드 구성이 아닌 경우 printf-style 디버그 메시지를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 .

ERRORMSG 런타임 이미지가 디버그 또는 릴리스 빌드 옵션으로 컴파일 되었고 Ship 빌드 구성이 아닌 경우 부가적인 printf-style 디버그 정보를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 . 이 오류 정보는 소스 코드 파일명과 행 번호를 포함한다 . 에러 메시지를 출력한 소스와 코드의 위치를 빠르게 찾을 수 있도록 해준다 .


디버그 영역디버그 메시지는 다중 - 쓰레드 프로세스를 분석하는데 특히 유용한 도구이다 .

특히 쓰레드 동기화 및 다른 다른 타이밍 관련 문제를 디버거로 코드를 순차적으

로 실행시키면서 문제를 찾아내는 것은 어렵다 . 그러나 , 사용자의 코드에 디버

깅 매크로를 많이 사용한다면 , 타겟 장치에 생성된 디버그 메시지의 수가 압도적

일 수 있다 . 생성된 정보의 양을 제어하기 위하여 , 디버깅 매크로는 사용자가 인

자의 표현을 지정할 수 있게 한다 .

예를 들어 , dwCurrentIteration 값이 가능한 최대값보다 더 크다면 다음의 코드

는 오류 메시지를 출력한다 .

ERRORMSG(dwCurrentIteration > dwMaxIteration,

(TEXT("Iteration error: the counter reached %u, when max allowed is %u\r\n"),

dwCurrentIteration, dwMaxIteration));

위의 보기에서처럼 , ERRORMSG 가 dwCurrentIteration 이 dwMaxIteration 보

다 더 클 때마다 디버깅 정보를 출력한다 , 그러나 사용자는 또한 조건문에서

Debug Zone 을 이용하여 디버깅 메시지를 제어할 수 있다 . 사용자가 매시간마

다 소스 코드를 변화시키거나 다시 컴파일 하지 않고 다양한 수준에서 모듈 ( 즉 ,

실행 파일 또는 DLL) 의 코드 실행을 검사하기 위해 DEBUGMSG 매크로를 사용

하기 윈한다면 , 이것은 특히 유용하다 . 첫째로 사용자는 실행 가능한 파일이나

DLL 에서 디버그 영역을 활성화해야 한다 . 그리고 어떤 영역을 활성화 시킬건지

ASSERTMSG 런타임 이미지가 디버그 빌드 구성으로 컴파일 되면 사실 , ASSERTMSG 는 DBGCHK 에 의해 DEBUGMSG 를 호출한다 . printf-style 디버그 메시지를 기본 출력 스트림 ( 즉 , 비주얼 스튜디오의 출력 윈도우 또는 지정된 파일 ) 에 인자로 출력한다 . 그리고 디버깅 모드로 전환된다 .

DEBUGLED 런타임 이미지가 디버그 빌드 옵션에서 컴파일 되고 WriteDebugLED 함수에 WORD 값을 인자로 전달한다 . 이 매크로는 시스템 상태를 나타내기 위한 발광 다이오드 (LED) 를 장착하고 OAL 에 OEMWriteDebugLED 함수가 구현된 시스템에 유용하다 .

리테일 LED 런타임 이미지가 디버그 빌드 옵션으로 컴파일 되고 WriteDebugLED 함수에 WORD 값을 인자 전달한다 . 이 매크로는 시스템 상태를 나타내기 위해 LED 가 장착되어 있고 OAL 에 OEMWriteDebugLED 함수가 구현되어 있는 시스템에서만 사용가능하다 .

표 4-1 디버깅 메시지 출력을 위한 윈도우 임베디드 CE 매크로

매크로 설명

http://msdn2.microsoft.com/en-us/library/aa936032.aspx



지정하기 위해 디버그 메시지서비스를 가지고 글로벌 DBGPARAM 변수를 등록

한다 . 개발용 워크스테이션이나 타겟 장치에 있는 레지스트리 설정을 통하여 , 또

는 사용자가 현재 기본값 영역을 프로그래밍 방식으로 지정할 수 있다 . 또한 대

상 메뉴 또는 Target Control 윈도우에 , CE 디버그 영역을 통한 플랫폼 빌더에

있는 모듈을 위하여 동적으로 디버그 영역을 제어하는 것이 가능하다 .

팁 디버그 영역을 우회

사용자가 런타임 이미지를 REBUILD 할 때 사용자가 TRUE 나 FALSE 로 설정할 수 있는 DEBUGMSG 와 리테일 MSG 매크로에게 BOOLEAN 변수를 전달한다면 , 드라이버와 응용프로그램에 있는 디버그 영역을 우회할 수 있다 .

영역 등록

디버그 영역을 이용하기 위해 , 사용자는 표 4-2 에 요약된 모듈 이름 , 사용자가

등록하는 것을 윈하는 디버그 영역의 이름 , 그리고 현재의 영역 마스크를 위한

필드를 지정하는 하는 세가지 필드와 글로벌 DBGPARAM 변수를 정의해야 한다.

표 4-2 DBGPARAM 변수

필드 설명 보기

lpszName 모듈의 이름을 최대 길이 32 자까지정의한다 . TEXT("ModuleName")

rglpszZones 디버그 영역을 위해 16 가지 종류의 영역 이름의 배열을 정의한다 . 각각의 이름은 최대 32 자까지 사용할 수 있다 . 플랫폼 빌더는 모듈에서 활성 영역을 선택할 때 사용자에게 이 정보를 화면 표시한다 .

{

TEXT("Init"),

TEXT("Deinit"),

TEXT("On"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Undefined"),

TEXT("Failure"),

TEXT("Warning"),

TEXT("Error") }

ulZoneMask 현재의 선택한 영역을 확인하는 DEBUGZONE 매크로에서 현재 영역 마스크를 사용한다 .

MASK_INIT | MASK_ON |

MASK_ERROR



참고 디버그 영역

윈도우 임베디드 CE 는 총 16 가지 이름의 디버그 영역을 지윈한다 . 그러나 모듈이 그들을 필요하지않는 다면 모두를 정의하지 않아도 된다 . 각 모듈은 구현된 DEBUG ZONE 목적에 명확하게 부합하도록영역별로 분리해서 사용하도록 한다 .

Dbgapi.h 헤더 파일은 DBGPARAM 구조체와 디버깅 매크로를 정의한다 . 이러

한 매크로가 dpCurSettings 로 이름 지어지고 , 미리 정의된 DBGPARAM 변수

를 사용하기 때문에 , 다음 코드 일부와 같이 , 사용자의 소스 코드에서 동일한 이

름으로 사용한다는 것은 중요하다 .

#include <DBGAPI.H>

// A macro to increase the readability of zone mask definitions #define DEBUGMASK(n) (0x00000001<<n)

// Definition of zone masks supported in this module#define MASK_INIT DEBUGMASK(0) #define MASK_DEINIT DEBUGMASK(1) #define MASK_ON DEBUGMASK(2) #define MASK_FAILURE DEBUGMASK(13) #define MASK_WARNING DEBUGMASK(14) #define MASK_ERROR DEBUGMASK(15)

// Definition dpCurSettings variable with the initial debug zone state // set to Failure, Warning, and Error.DBGPARAM dpCurSettings = { TEXT("ModuleName"), // Specify the actual module name for clarity! { TEXT("Init"), TEXT("Deinit"), TEXT("On"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Undefined"), TEXT("Failure"), TEXT("Warning"), TEXT("Error") }, MASK_INIT | MASK_ON | MASK_ERROR};

// Main entry point into DLL BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ){ if(ul_reason_for_call == DLL_PROCESS_ATTACH) { // Register with the Debug Message service each time // the DLL is loaded into the address space of a process. DEBUGREGISTER((HMODULE)hModule); } return TRUE;}


Debug Zones 정의위에 있는 예제 코드는 모듈에 대한 6 가지 Debug Zone 의 등록과 디버깅 메크

로에 대한 조건문을 보여준다 . 다음 코드는 이와 같은 일을 하는 예를 보여준다 .

DEBUGMSG(dpCurSettings.ulZoneMask & (0x00000001<<(15)),

(TEXT("Error Information\r\n")));

만일 디버그 영역이 MASK_ERROR 로 현재 설정되어 있다면 , 조건식의 값이

TRUE 이기 때문에 디버그 출력 스트림에 출력하게 된다 . 그러나 코드의 가독성

을 높이기 위해 밑에 예시된 코드와 같이 Dbgapi.h 에 DEBUGZONE 매크로를

정의해서 사용해야 한다 . 무엇보다도 Debug Zone 을 논리적 연산자인 AND 나

OR 에 의한 간단히 정의 사용할 수 있게 한다 .

#include <DBGAPI.H>

// Definition of zone flags: TRUE or FALSE according to selected debug zone.

#define ZONE_INIT DEBUGZONE(0)

#define ZONE_DEINIT DEBUGZONE(1)

#define ZONE_ON DEBUGZONE(2)

#define ZONE_FAILURE DEBUGZONE(13)

#define ZONE_WARNING DEBUGZONE(14)

#define ZONE_ERROR DEBUGZONE(15)

DEBUGMSG(ZONE_FAILURE, (TEXT("Failure debug zone enabled.\r\n")));

DEBUGMSG(ZONE_FAILURE && ZONE_ WARNING,

(TEXT("Failure and Warning debug zones enabled.\r\n")));

DEBUGMSG(ZONE_FAILURE || ZONE_ ERROR,

(TEXT("Failure or Error debug zone enabled.\r\n")));

Debug Zone 활성화 및 비활성화DBGPARAM 필드의 ulZoneMask 는 모듈의 현재 Debug Zone 을 설정할수 있

게하는 중요한 요소다 . 사용자는 전역 변수인 dpCurSett ings 변수의

ulZoneMask 값을 직접 변경하는 방법을 통해 모듈의 Debug Zone 을 변경하면

서 사용할 수 있다 . 다른 방법은 디버거 안에서 설정한 중단점에 의해 프로그램

수행이 멈췄을 때 Watch 윈도우에서 ulZoneMask 의 값을 직접 변경하는 것이다 .

사용자는 또한 다른 어플리케이션의 Debug Zone 을 SetDbgZone 함수를 사용

하여 설정하거나 변경 할 수 있다 . 실행중에 사용가능한 다른 방법은 그림 4-2

와 같이 Debug Zone 대화 상자를 사용하는 방법이다 . Debug Zone 대화 상자

는 비주얼 스튜디오에 있는 플랫폼 빌더에서 Target 메뉴에 있는 CE Debug

Zones 메뉴를 사용하여 이용할 수 있다 .


그림 4-2 플랫폼 빌더에서 디버그 영역 설정

Name 항목은 디버그 영역을 지윈하는 타겟 장치에서 실행하는 모듈을 보여준다 .

선택한 모듈이 디버그 메시지 서비스를 등록하였다면 16 가지의 Debug Zone 이

표시되는 것을 볼 수 있다 . 그 이름들은 선택된 모듈의 dpCurSettings 정의한 것

과 동일하다 . 사용자는 Debug Zone 이름을 선택하여 Debug Zone 을 활성화 시

키거나 비활성화 시킬 수 있다 . dpCurSetting 변수에 설정된 Debug Zone 은 기

본적으로 활성화 되고 체크 상태로 표시된다 . 디버그 메시지 서비스를 등록하지

않은 모듈은 Debug Zone 표시에서 비활성화 되고 Debug Zone 설정을 할 수 없

다 .

운영체제 시작시 Debug Zone 설정윈도우 임베디드 CE 는 응용 프로그램이 시작하거나 DLL 을 프로세스로 로드할

때 dpCurSettings 변수에 설정된 값으로 Debug Zone 을 설정하게 된다 . 이때는

사용자가 중단점에 의해 멈춰진 상태에서 Watch 윈도우에서 ulZoneMask 값을

바꾸지 않는한 Debug Zone 을 바꾸는 것은 불가능하다 . 하지만 CE 는 좀더 간

편하게 레지스터리 설정을 변경하는 방법으로 Debug Zone 을 변경하는 방법을

지윈한다 . 로드되는 드라이버에서 다른 Debug Zone 을 활성화 시키기 위해서는

REG_DWORD 형식의 레지스터리를 만들어서 Registry 이름에는 해당 모듈

(lpszName 에 지정된 이름 ) 의 이름을 지정하고 값에는 활성화 시키고자 하는

Debug Zone 의 값 (dpCurSettings 변수에 지정된 값 ) 을 지정하면 된다 . 이 레

지스트리 값은 개발용 워크스테이션이나 타겟 장치를 변경함으로써 이용할 수 있

다 . 개발용 워크스테이션에 있는 레지스트리를 변경하는 장점은 PC 의 레지스터

리 변경 후 타겟 장치를 재 시작하는 것으로 대상 모듈에 대한 Debug Zone 변경


을 할 수 있지만 타겟 장치에 있는 레지스트리를 변경하는 것은 런타임 이미지를

다시 빌드해야 하는 단점이 있다 . 표 4-3 은 ModuleName 로 불리는 샘플 모듈

로 구성하는 예를 설명한다 . 항목이름은 실행가능한 EXE 파일이나 DLL 의 실제

이름이어야 한다 .

자세한 정보 페가수스 레지스트리 키

페가수스 이름은 1996 년 마이크로소프트사가 핸드헬드 개인용 컴퓨터와 다른 소비자 전자제품을 위해 출시된 첫 번째 윈도우 CE 버전의 코드 이름으로 알려졌던 이름이다 .

최상의 방법디버그 메시지를 이용하여 개발 작업을 한다는 것중 명심해야 할 것은 디버그 메

시지를 많이 출력하게 하면 코드 실행 속도가 늦어진다는 것이다 . 더욱 중요한

문제는 시스템은 디버그 출력 작업을 직렬화 하게 되고 , 이것은 의도되지 않는

쓰레드의 동기화 문제를 초래한다는 것이다 . 예를 든다면 , 다중 쓰레드 환경에

서 비동기적으로 동작하던 시스템이 릴리스 빌드에서는 문제가 없다가 디버그 빌

드에서는 문제를 일으키는 경우가 있다 .

표 4-3 시작 레지스트리 매개변수 예제

위치 개발용 워크스테이션 타겟장치

레지스트리 키 HKEY_CURRENT_USER₩Pegasus₩Zones

HKEY_LOCAL_MACHINE₩DebugZones

항목 이름 ModuleName ModuleName

유형 REG_DWORD REG_DWORD

값 0x00000001 - 0x7FFFFFFF 0x00000001 - 0x7FFFFFFF

코멘트 개발용 워크스테이션에서 디버깅 하는 모듈에 대한 Debug Zone 레지스터리 정보를 얻을 수 없을때 ( 개발용 워크스테이션이 없거나 레지스트리가 설정되지 않았을 때 ) 는 타겟에 설정된 레지스터리 정보를 이용해 Debug Zone 을 설정하게 된다 .

참고 모든 디버그 영역의 활성화

윈도우 임베디드 CE 는 응용프로그램 디버깅 목적을 위하여 디버그 영역의이름을 정의하고 REG_DWORD 값의 하위 16 비트를 사용한다 . 커널에 의해예약된 최상위 비트만 제외하고 남아 있는 비트들은 지정되지 않은 DEBUGZONE 을 위해 사용할 수 있다 . 그러므로 , 사용자는 모듈의 디버그 영역 값을 0XFFFFFFFF 로 설정해서는 안 된다 . 최대 값은 0X7FFFFFFF 이다 . 이미지정되어 있거나 지정되지 않은 DEBUG ZONE 으로 사용할 수 있다 .


디버그 메시지 및 Debug Zone 을 사용하여 작업할 때 다음과 같은 방법을 사용

할것을 제안한다 .

■ 조건문 Debug Zone 에 대한 조건문을 사용하는 디버그 매크로를 사용하

라 . DEBUGMSG(TRUE) 를 사용하지 않는다 . 또한 조건문 없는 리테일

MSG(TRUE)같은 리테일 매크로를 사용하는 것을 피한다. 비록 일부 model

device driver (MDD)/ platform dependent driver (PDD) 드라이버는 이

기술을 사용하고 있다 .

■ 릴리스 빌드로 부터 디버깅 코드 제한 사용자가 단지 디버그 빌드에서 디

버그 영역을 사용한다면 , #ifdef DEBUG #endif 안에 전역 변수인

dpCurSettings 와 Debug Zone 값을 정의해야 한다 . 그래서 DEBUGMSG

와 같은 디버그 매크로 및 Debug Zone 을 제한해야 한다 .

■ 릴리스 빌드에서 리테일 매크로 사용 사용자가 또한 릴리스 빌드에서 디버

그 영역을 사용하는 것을 윈한다면 #ifndef SHIP_BUILD #endif 안에 전역

변수인 dpCurSetting 와 Debug Zone 값을 정의해야 한다 . 그리고 디버그

빌드에서 사용했던 DEBUGREGISTER 대신 릴리스 빌드에서는 리테일

REGISTERZONES 을 사용해야 한다 .

■ 모듈 이름을 명확하게 지정 가능하면 , 그 모듈의 파일 이름으로

dpCurSettings.lpszName 값을 설정한다 .

■ 기본값으로 중복 제한 드라이버의 기본 Debug Zone 은 ZONE_ERROR 나

ZONE_WARNING 을 사용하라 . 새로운 새로운 플랫폼을 동작시킬때는

ZONE_INIT 을 사용한다 .

■ 복구할 수없는 문제의 오류 디버그 영역 제한 ZONE_ERROR 는 모듈이나

중요한 기능이 잘못된 설정이나 다른 이슈로 문제가 될 때만 사용하라 . 복

구 가능한 문제를 위해 ZONE_WARNING 를 사용한다 .

■ 가능한 모든 오류 및 경고 제거 모듈은 ZONE_ERROR 이나

ZONE_WARNING 메시지 없이 로드 될 수 있어야 한다 .

Target Control 명령Target Control 서비스는 타겟 장치로 파일을 옮기고 응용프로그램을 디버그 하

기 위해서 디버거의 명령 쉘에 대한 접근을 제공한다 . 그림 4-3 과 같은 타겟 제

어 쉘은 비주얼 스튜디오내의 플랫폼 빌더 메뉴 Target 메뉴에서 Target

Control option 메뉴를 통해 표시할 수 있다 . Target Control 쉘을 사용하기 위

해서는 플랫폼 빌더와 타겟 장치와 KITL 을 통해 연결되어 있어야 함을 명심해

야 한다 .


도표 4-3 Target Control 쉘

다른 것들 중에서 , Target Control 쉘은 사용자가 다음의 디버깅 작업을 수행할

수 있게 한다 .

■ 디버깅 모드로 진입 (break 명령 ).

■ 메모리 내용 덤프를 디버그 창에 출력하기 (dd 명령 ) 나 파일로 저장하기 (df

명령 ).

■ 커널 (mi kernel 명령 ) 또는 전체 시스템 (mi full 명령 ) 을 위한 메모리 사용

량 분석 .

■ 프로세스 목록 출력(gi proc 명령), 쓰레드 (gi thrd 명령), 그리고 쓰레드 우

선순위 (tp 명령 ), 뿐만 아니라 시스템에 모듈을 로드 (gi mod 명령 ).

■ 프로세스 시작 (s 명령 ) 그리고 프로세스 종료시키기 (kp 명령 ).

■ 프로세스 힙 덤프 (hp 명령 ).

■ 시스템 프로파일러를 사용 또는 비사용 (prof 명령 ).

참고 Target Control 명령

TARGET CONTROL 명령의 전체 명령 설명은 MICROSOFT MSDN ® 웹사이트에 있는 http://msdn2.microsoft.com/en-us/library/aa936032.aspx 에서 윈도우 임베디드 CE 6.0설명서의 “TARGET CONTROL 디버깅 명령” 섹션을 참조한다 .

CEDebugX기본 내장된 디버거 명령 이외에 , Target Control 서비스는 커널과 응용프로그

램 디버깅의 효율성을 증가시키기 위해 CEDebugX 를 제공한다 . 이 확장 디버거

명령은 메모리 누수 , 교착 상태 , 그리고 시스템의 전반적인 동작상태를 분석하

는 부가적인 기능을 제공한다 . 부가적인 명령은 Target Control 쉘을 통해 접근

할 수 있고 느낌표 (!) 로 시작한다 .


CEDebugX 명령을 사용하기 위해서는 Target Control 쉘에서 Break 명령이나

Break All 명령을 사용하여 디버거 모드로 진입해야 한다 .

힙 손상 , 교착 상태 , 또는 메모리 부족과 같은 잠재적인 문제의 윈인을 찾기 위

해서는 !diagnose all 명령을 사용하여 분석한다 . 그림 4-4 와 같이 정상적인 시

스템에서는 CEDebugX 에서 어떠한 문제도 나타나면 안된다 .

그림 4-4 CEDebugX 로 런타임 이미지 분석

!diagnose all 명령은 다음과 같은 진단을 실행한다 .

■ Heap 잠재한 콘텐츠 손상을 식별하기 위해 시스템의 모든 프로세서의 모

든 힙 객체를 진단한다 .

■ Exception 시스템에서 발생한 예외에 대해 진단하고 자세한 정보를 제공

한다 . 프로세스나 쓰레드의 ID, PC 주소 , 예외가 발생한 시간 등이다 .


■ Memory 잠재한 메모리 손상과 메모리 부족 상태를 식별하기 위해 시스템

메모리를 진단한다 .

■ Deadlock 쓰레드 상태 진단 및 시스템 객체를 분석한다 . ( 쓰레드를 동기

화에 대한 자세한 내용은 제 3 장 참조 ). 이것은 시스템 객체의 목록과 교착

상태가 발생한 쓰레드 ID 를 제공할 수 있다 .

■ Starvation 잠재한 쓰레드 자윈 부족을 식별하기 위해 쓰레드와 시스템 객

체를 진단한다 . 자윈부족은 높은 우선순위의 쓰레드를 처리하기 위해서 스

케줄러가 더 이상 다른 쓰레드를 스케줄 할 수 없을 때 발생한다 .

고급 디버거 도구Target Control 쉘과 CEDebugX 명령은 실행중인 시스템이나 CE dump 파일 (

만일 사용자가 post-mortem 디버깅으로 CE 덤프 파일 리더를 선택한다면 ) 의

완전한 분석을 수행할 수 있게 한다 . 그러나 사용자가 커맨드라인 인터페이스에

제한되지는 않는다 . 플랫폼 빌더는 효율적인 디버깅 목적으로 몇 가지의 그래픽

툴들을 포함하고 있다 . 이러한 툴들은 비쥬얼 스튜디어의 Debug 메뉴의

Windows 명령을 통해 사용할 수 있다 .

플랫폼 빌더 통합 개발 환경은는 다음의 고급 디버거 도구를 포함한다 .

■ Breakpoints 시스템에 설정된 중단점 목록을 나열하고 중단점에 대한 속

성을 표시 , 관리한다 .

■ Watch 지역 , 전역 변수에 대한 읽고 / 쓰기 기능을 제공한다 .

■ Autos Watch 윈도우와 비슷한 변수 관리 기능을 제공한다 . Watch 윈도

우의 경우 사용자가 변수를 직접 등록해야 하지만 Autos 는 디버거가 동적

으로 변수 목록을 등록하게 된다 . 함수에서 전단되는 인자의 값을 검사하는

것 같은 작업에서 유용하다 .

■ Call Stack 시스템이 중단점에 멈췄을 때만 사용 가능하다 . 시스템에서 동

작중인 프로세서와 쓰레드의 목록을 표시해 준다 .

■ Thread 시스템에서 실행되고 있는 쓰레드에 대한 목록을 제공한다 . 이 정

보는 동적으로 검색되고 언제든지 갱신될 수 있다 .

■ Module 시스템에서 로드되거나 로드 되지 않은 모듈에 대한 정보를 제공

한다 . 로드된 모듈의 메모리 주소 정보를 제공한다 . 이 기능은 실제로 드라

이버 DLL 이 로드 여부를 확인하는 데 유용하다 .

■ Process 프로세스 - 쓰레드와 비슷한 기능 , 시스템에서 실행되고 있는 프

로세스의 목록을 제공해 준다 . 프로세서를 종료시킬 수 있는 기능을 제공해

준다 .



■ Memory 장치의 메모리에 대해 직접 접근할 수 있는 기능을 제공한다 . 메

모리의 주소나 변수의 이름으로 메모리의 내용을 볼수 있게 해준다 .

■ Disassembly 현재 실행중인 코드에 대한 어셈블리 코드를 보여준다 .

■ Register 특정한 코드의 라인을 수행할 때 CPU 레지스터 값을 볼수 있게

해준다 .

■ Advanced Memory 메모리에서 특정 내용을 찾거나 , 메모리 일부분을 다

른 영역으로 옮기기 , 특정 패턴으로 메모리 채우기와 같은 기능을 제공한다 .

■ List Nearest Symbols 지정한 메모리 주소에서 가장 근접한 심볼을 찾을

때 사용한다 . 심볼을 포함하고 있는 파일에 대한 완전한 경로 정보를 제공

한다 . 이 도구는 예외가 발생한 함수를 찾는데 유용하다 .

주의 메모리 손상

메모리와 고급 메모리 도구는 메모리 내용을 수정할 수 있다 . 이 도구를 잘못 사용하는 것은 시스템손상을 발생시킬 수 있고 타겟 장치에 있는 운영체제를 손상시킬 수 있다 .

Application Verifier ToolCETK 에 포함된 어플리케이션의 잠재적인 호환성 , 안정성 , 소스레벨 문제를 검

증하는 도구는 응용프로그램 검증 도구이다 . 이도구는 그렇지 않으면 독립형 장

치에서는 발생하는 문제점을 파악하기 힘든 어플리케이션이나 DLL 에 연결하여

문제점을 분석할 수 있다 . 응용프로그램 검증 도구는 개발용 워크스테이션에 반

드시 연결해서 사용해야 하는 것은 아니다 . 시스템 구동시 드라이버나 시스템 어

플리케이션을 검증할 수 있다 . 또한 CETK 내의 사용자 인터페이스를 통하거나

수동으로 시작할 수 있다 . 사용자가 CETK 의 응용프로그램 검증 도구를 외부에

서 사용하는 것을 윈한다면 , 사용자는 릴리스 디렉터리 안으로 모든 필수 파일을

복사하기 위해 Getappverif_cetk.bat 파일을 사용해야 한다 .

참고 Application Verifier Tool 설명서

사용자 정의 테스트나 테스트 함수의 테스트 방법 변경을 하는 확장 DLL 사용 방법에 대해서나 ,APPLICATION VERIFIER TOOL 에 대한 자세한 내용은 MICROSOFT MSDN 웹 사이트 http://msdn2.microsoft.com/en-us/library/aa934321.aspx 의 윈도우 임베디드 CE 6.0 의 설명서에 있는“APPLICATION VERIFIER TOOL”섹션을 참고한다 .

CELog 이벤트 추적 및 처리윈도우 임베디드 CE 는 사용자가 성능 문제를 진단하기 위해 런타임 이미지에 포

함할 수 있는 확장 가능한 이벤트 추적 시스템을 포함한다 . CELog 이벤트 추적




시스템은 사전 정의된 커널과 뮤텍스 , 이벤트 , 메모리 할당과 다른 커널 객체와

관계된 일련의 coredll 이벤트를 기록한다 . CELog 이벤트 추적시스템의 확장 가

능한 아키텍처는 또한 사용자가 사용자 정의된 이벤트를 추적하기 위해 사용자

지정 필터를 구현할 수 있게 한다 . KITL 을 통해 개발용 워크스테이션에 연결된

플랫폼을 위해 이벤트 추적 시스템은 표 4-4 에 요약된 것처럼 ZoneCE 레지스

터리를 이용하여 선택적으로 기록할 수 있도록 선택할 수 있다 .

CELog 이벤트 추적 시스템을 사용하여 타겟 장치의 램 영역에 저장되어 있는 로

그 정보를 수집하고 이용할 수 있다 . 수집된 로그 데이터는 윈격 커널 트랙커를

사용하거나 Readlog 와 같은 도구를 이용하여 분석할 수 있다 . CELogFlush 도

구를 사용하여 주기적으로 파일로 저장하고 이용할 수 있다 .

참고 CELog 와 ship 빌드

운영체제 최종 빌드시에는 CELOG 시스템을 포함시키지 말아야 한다 . CELOG 의 동작으로 인해 시스템성능과 가용 메모리의 감소 효과를 가져오기 때문이다 . 또한 악의적인 사용자의 시스템에 대한 공격시도를 줄이기 위해서다 .

Remote Kernel Tracker

Remote Kernel Tracker 도구는 사용자가 타겟 장치 시스템의 프로세서와 쓰레

드의 활동을 모니터 할 수 있게 한다 . 이 도구는 KITL 을 통해 타겟 장치로부터

얻은 정보를 실시간으로 화면에 표시할 수 있을 뿐만 아니라 CELog 파일을 이용

한 오프라인 분석도 가능하다 . 사용자는 3 장의 “시스템 프로그래밍 실행” 에

서 Remote Kernel Tracker 도구에 대한 더 많은 정보를 발견할 수 있다 . 그림

4-5 는 커널 트랙커를 이용하여 타겟 장치의 쓰레드 활동의 정보를 수집하는 것

을 보여준다 .

표 4-4 이벤트 로그 영역을 위한 CELog 레지스트리 매개 변수

위치 HKEY_LOCAL_MACHINE₩System₩CELog

레지스트리 항목 ZoneCE

항목 유형 REG_DWORD

값 <Zone IDs>

설명 기본값으로 모든 영역은 기록된다 . 모든 가능한 영역 ID 값 목록은 , 윈도우 임베디드 CE 6.0 설명서에 있는 “CELog Zones” 영역을 참조한다 . 이것은 마이크로소프트 MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa909194.aspx 에서 이용할 수 있다 .




그림 4-5 커널 트랙커에서 쓰레드 정보

CELogFlush 도구

CELogFlush 도구는 타겟장치의 RAM 에 저장되어 있는 CELog 이벤트 자료를

.clg 형태의 파일로 저장하기 위해 사용한다 . 이 파일은 RAM 파일 시스템 , 저장

장치 , 또는 개발용 워크스테이션에 있는 릴리스 파일 시스템에 위치할 수도 있다 .

버퍼오버런으로 인한 자료 손실을 최소화 하기 위해 , 사용자는 더 큰 RAM 버퍼

를 지정할 수 있고 CELog 버퍼를 출력하는 주기를 증가시킬 수 있다 . 사용자가

반복된 파일 열고 닫는 작업을 회피하고 느린 영구적 저장 매체 대신 RAM 파일

시스템에서 파일을 저장하도록 설정해 놓는다면 좀 더 성능 향상을 기대할 수 있

다 .

참고 CELogFlush 구성

CELOGFLUSH 도구를 레지스터리를 설정을 통하여 구성하는 방법에 대한 자세한 내용은 윈도우 임베디드 CE 설명서의 “CELOGFLUSH 레지스트리 설정” 섹션을 참고한다 . 이것은 마이크로소프트 MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa935267.aspx 에서 이용할 수 있다 .

Readlog 도구그래픽 Remote Kernel Tracker 응용프로그램 이외에 %_WINCEROOT%

₩Public₩Common₩Oak₩Bin₩i386 폴더에 위치한 Readlog 툴을 이용하여

CELog 자료 파일을 처리할 수 있다 . Readlog 툴은 윈격 커널 트랙커에 의해 나


타나지 않는 디버그 메시지나 부트 이벤트등의 정보를 처리하고 화면에 보여주

는 커맨드 라인 도구이다 . 초기에 윈격 커널 트랙커를 이용하여 시스템을 분석하

는 것은 매우 유용한 방법이다 . 분석후 확인된 프로세서나 쓰레드를 Readlog 툴

을 이용하여 분석을 하게 된다 . CELogFlush 툴에 의해 저장된 .clg 파일은 영역

별로 정리가 되어 있기 때문에 특정한 정보를 정리 분석하기에 유용하다 . 사용자

는 또한 그 자료를 필터 할 수 있고 사용자 지정 이벤트 콜렉터를 통해 수집한 사

용자 지정 자료를 처리해서 확장 DLLs 에 기반하는 필터링 능력을 확장할 수도

있다 .

가장 유용한 Readlog 시나리오의 하나는 Remote Kernel Tracker 에서 시스템

분석을 용이하게 하기 위해서 CELog 자료파일에 있는 쓰레드의 시작 주소

(CreateThread 호출로 전달되는 함수 ) 를 실제 함수의 이름으로 교체하는 것이

다 . 이 기능을 사용하기 위해서는 -fixthreads 매개변수를 사용하여 Readlog 를

시작해야 한다 ( 즉 , readlog -fixthreads). Readlog 는 .map 파일에 있는 심볼

의 정보를 살펴보고 쓰레드 함수의 시작주소와 일치시켜 함수의 이름으로 정리

된 새로운 CELog 파일을 생성하게 된다 .

그림 4-6 CELog 데이터 파일이 readlog -fixthreads 명령에 의해 처리되고 윈격 커널 트랙커에 의해 열린 그림이다 .


그림 4-6 은 Remote Kernel Tracker 에서 CELogFlush 도구를 이용하여 .clg

파일로 저장하고 , Readlog 툴을 -fixthreads 옵션을 사용하여 로그 파일을 처리

하고나서 Kernel Tracker 에서 처리된 .clg 파일을 분석하여 보여주는 것이다 .

실제 함수명이 나오기 때문에 분석이 좀더 용이하다 .

참고 참조 이름 일치 개선시키기

CELOG 이벤트 추적 시스템은 커널 프로파일러 기능을 설정하고고 환경변수에서 IMGPROFILER=1 로 설정해서 런타임 이미지를 재빌드 했을 때 사용 가능하다 . CELOG 이벤트 추적 시스템은 커널 프로파일러가 가지고 있는 쓰레드 함수 찾아보기 기능을 이용하고 있다 . 그러나 CELOG 는 런타임 이미지에 내장된 프로파일링의 심볼만 검색할 수 있다 . SOFTWARE DEVELOPMENT KIT(SDK) 에 기반하여 개발된 응용프로그램의 심볼은 CELOG 이벤트 추적시스템을 사용할 수 없다 .

요점 정리운영체제와 응용프로그램의 디버깅은 CE 시스템 그리고 플랫폼 빌더와 CETK

가 포함된 양쪽 모두의 지식이 요구된다 . 가장 중요한 디버깅 툴들은 시스템 디

버거 , 디버그 메시지 기능 , 그리고 CE 는 타겟 제어 쉘이다 . 디버그 메시지 기능

이 코드 실행을 방해하지 않고 시스템 구성요소와 응용프로그램을 분석하는 기

능을 제공하는 동안 , 시스템 디버거는 사용자가 중단점을 설정하고 커널과 응용

프로그램 코드를 단계적으로 실행시키면서 디버깅하는 기능을 가능하게 한다 .

디버그와 리테일 매크로의 다양성은 타겟장치에서 화면표시 구성요소 여부와 상

관 없이 디버깅 정보의 출력은 사용 가능하다 . 시스템과 응용프로그램이 잠재적

으로 대량의 디버그 메시지를 생성시킬 수 있기 때문에 , 사용자는 디버깅 정보의

출력을 제어하기 위해 디버그 영역을 이용해야 한다 . 디버그 영역의 중요한 장점

은 사용자가 런타임 이미지를 리빌드 하지 않고도 동적으로 디버그 정보의 출력

설정을 변경할 수 있다 . 또 한 편으로는 , 타겟 제어 쉘은 사용자가 Break 명령으

로 디버그 모드에 진입한 후 전반적인 시스템 상태를 확인할 수 있는 CEDebugX

의 기능중의 하나인 !diagnose all 명령어를 사용하여 분석한다 .

이 코어 디버깅 도구와는 별도로 , 사용자는 전형적인 CE 구성과 응용프로그램

검증 도구와 잠재한 응용프로그램 호환성과 안정성 문제를 식별하기 위해서 그

리고 프로세스 , 쓰레드 , 그리고 시스템 성능을 분석하는 Remote Kernel

Tracker 같은 도구를 사용할 수 있다 .Remote Kernel Tracker 는 CELog 이벤

트 추적시스템에 의존한다 . 타겟 장치의 메모리에 기록된 로그 데이터는

CELogFlush 도구를 이용하여 파일로 출력한다 . 분석하려는 모듈의 심볼 파일

을 가지고 있다면 Readlog 도구를 이용하여 로그 파일에 있는 쓰레드의 시작 주

소를 실제 함수의 이름으로 변경하여 새로운 로그 파일로 생성할 수 있다 .

Remote Kernel Tracker 를 이용해 이 로그 파일을 좀더 편리하게 사용할 수 있

게 한다 .



디버깅 가능한 런타임 이미지 구성윈도우 임베디드 CE 의 디버깅 기능은 개발용 워크스테이션 구성요소와 타겟 장

치에 의존한다 . 그리고 특정한 설정과 하드웨어 지윈을 요구한다 . 개발용 워크

스테이션과 타겟 장치 사이의 연결 없이 정보를 교환하거나 디버깅 할 수 없다 .

만약 타겟 장치의 디버깅 모듈을 언로드 하지않고 통신 연결이 끊어진다면 개발

워크스테이션에 있는 디버거는 멈출 것이다 . 또한 타겟 장치는 사용자의 입력에

무응답 할 것이다 . 그 이유는 디버거가 코드의 재 실행을 지시할때까지 대기 상

태가 되기 때문이다 .

이 과정을 마치면 , 사용자는 다음을 할 수 있다 .

■ 런타임 이미지를 위한 커널 디버거 활성화 .

■ KITL 요구사항의 확인 .

■ 디버깅 컨텍스트에 커널 디버거 사용 .


커널 디버거 활성화 위와 같이윈도우 임베디드 CE 6.0 을 위한 개발 환경은 개발자가 CE 타겟 장치

에서 코드 실행과 코드를 순차적으로 실행하도록 제어할 수 있는 커널 디버거를

포함한다 . 이 디버거는 사용자가 타겟 장치와 개발용 컴퓨터 사이에 커널 선택과

통신 계층을 설정할 것을 요구한다 .

OS 디자인 설정디버깅을 위한 OS 설계를 활성화하게 하기 위해 , 플랫폼 빌더가 KdStub 라이브

러리를 포함하고 런타임이미지를 구축할 때 Board Support Package(BSP) 에

있는 KITL 통신 계층을 사용하게 하도록 환경 변수 IMGNODEBUGGER 과

IMGNOKITL 를 해제한다 . 비주얼 스튜디오에서 , 플랫폼 빌더에서는 메뉴를 통

하여 보다 손쉽게 설정할 수 있는 방법을 제공한다 . 그 방법은 OS desing project

를 선택하여 오른쪽 마우스 버튼을 누르고 , Properties 를 선택한다 . Build

Options 창에 Enable Kernel Debugger 와 Enable KITL 을 선택한다 . 1 장 “운

영 체제 설계의 사용자 지정” 에서 더 많은 OS Design 속성 페이지 대화 상자세

부사항을 논의한다 .

디버거 선택

런타임 이미지를 위해 KdStub 와 KITL 을 사용 가능하게 하면서 , 타겟 장치에

대한 통신 매개변수에서 타겟 장치 위에 시스템을 분석하기 위해 디버거를 선택

디버깅 가능한 런타임 이미지 구성 167

할 수 있다 . 이 매개변수를 구성하기 위해 , 2 장 “런타임 이미지 빌드 및 배포”

에서 설명한 대상 메뉴를 열고 , Connectivity Options 을 선택함으로써 비주얼

스튜디오에서 타겟 장치 연결 선택 대화 상자를 화면 표시한다 .

어떠한 디버거도 연결 옵션에는 선택되어있지 않다 . 다음과 같은 디버거 중 선

택해야 한다 .

■ KdStub 이것은 커널과 응용프로그램이 시스템 구성요소 , 드라이버 , 그리

고 타겟 장치에서 실행하는 응용프로그램을 디버그 하는 소프트웨어 디버거

이다 . KdStub 는 플랫폼 빌더와 통신하기 위해 KITL 을 요구한다 .

■ CE Dump File 플랫폼 빌더는 Dump 파일을 캡쳐하기 위한 옵션을 제공한

다 . 이 덤프 파일은 CE 덤프 파일 리더를 사용하여 불러 올 수 있다 . Dump

파일은 시스템의 특정한 상태를 살펴볼 수 있게 하는 유용한 도구다 .

■ Sample Device Emulator eXDI 2 Driver -KdStub 는 커널이 로드 되기 전

의 코드들은 디버깅 할 수 없다 . 디버깅 라이브러리는 소프트웨어에 의한 중

단점을 사용하기 때문에 인터럽트 처리 루틴 (ISR) 은 디버깅 할 수 없다 .

하드웨어 장치를 통한 디버깅을 위해 플랫폼 빌더에서는 joint test action

group(JTAG) 을 통하여 디버깅 할 수 있는 장비에 대한 샘플 eXDI 드라이

버를 제공한다 .

참고 하드웨어 -지윈 디버깅

하드웨어 - 지윈 디버깅에 관한 상세한 정보 는 윈도우 임베디드 CE 6.0 설명서의 “하드웨어 - 지윈디버깅” 섹션을 참고한다. 이것은 마이크로소프트MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa935824.aspx 에서 이용할 수 있다 . .

KITL이장의 시작 부분에서 그림 4-1 에서 볼 수 있듯이 KITL 은 개발용 컴퓨터와 타

겟 장치 사이에 필수적인 통신 계층이고 커널 디버거 지윈을 위해 사용하게 해야

한다 . 이름이 암시하는 것과 같이 , DMA 와 같게 KITL 은 완전하게 하드웨어와

독립적이다 . 네트워크 연결 , 시리얼 케이블 , 범용 직렬 버스 (USB), 또는 DMA

(DMA) 같은 기타 지윈하는 통신 메커니즘 위로 작동 한다 . 유일한 필요는 양 쪽

( 개발용 컴퓨터와 타겟장치 ) 모두 같은 인터페이스를 지윈하고 사용해야 한다 .

4-7 그림과 같이 장치 에뮬레이터를 위한 가장 일반적이고 빠른 KITL 인터페이

스는 DMA 이다 . 지윈된 이더넷 칩을 가지는 타겟 장치가 네트워크 인터페이스

를 사용하는 것은 일반적으로 가장 바람직하다 .


그림 4-7 KITL 통신 인터페이스의 구성

KITL 은 다음과 같은 두 가지 작업 방법을 지윈한다 .

■ Active Mode 기본값에 의해 , 플랫폼 빌더는 부팅 프로세스 동안 개발용 컴

퓨터에 연결하기 위해 KITL 을 구성한다 . 이 설정은 소프트웨어 개발 주기

동안 커널과 응용프로그램 디버깅에 대해서 유용하다 .

■ Passive Mode Device Boot에 활성화 KITL확인란을 선택 취소함으로써 수

동 모드로 KITL 을 구성할 수 있다 . 윈도우 임베디드 CE 는 KITL 인터페이

스를 초기화하는 것을 의미하나 KITL 은 구동 프로세스 동안 연결을 설정하

지 않는다. 예외가 발생하면, 사용자가 JIT 디버깅을 수행할 수 있도록 KITL

은 개발용 컴퓨터로 연결을 만들기 위해 시도한다 . 수동 모드는 구동할 때

개발용 컴퓨터로의 물리적 연결을 가지고 있지 않는 이동하기 쉬운 장치를

개발할 때 가장 유용하다 .


참고 KITL 모드와 부트 인자

장치부트 설정에 있는 ACTIVE KITL은 플랫폼 빌더가 부트 로더를 위해 구성하는 부트 인자(BOOTARGS)이다 . BSP 개발 프로세스 동안 부트 로더와 그들의 장점에 대한 더 많은 정보는 윈도우 임베디드 CE설명서의 “부트로더” 섹션을 참조한다 . 이것은 마이크로소프트 MSDN 웹사이트 HTTP://MSDN2.MICROSOFT.COM/EN-US/LIBRARY/AA917791.ASPX 에서 이용할 수 있다 .

타겟장치 디버깅하기개발자 - 측과 대상 - 측 디버거 컴포넌트는 각 각 독립적으로 실행된다는 것을

아는 것이 중요하다 . 예를들면 , 커널 디버거는 유효한 타겟장치 없이 플랫폼 빌

더와 함께 비주얼 스튜디오비주얼 스튜디오에서 실행하는 것이 가능하다 . 만일 ,

디버그 메뉴를 열고 시작을 클릭하거나 F5 키를 누르면 , 커널 디버거 (Kernel

Debugger) 는 타겟 장치에 연결을 기다리는 출력 창에서 시작과 동시에 정보를

알려준다 . 다른 한편으로는 , 이 장에서 언급한 바와 같이 만일 디버거에 유효한

KITL 연결 없이 디버깅 - 가능 런타임 이미지를 실행 하고 예외가 발생 한다면 ,

런타임 이미지는 시스템이 멈춤으로 말미암아 끈어지게 (hang) 되며 , 디버거로

부터 제어 요청을 기다린다 . 이러한 이유때문에 디버깅 - 가능 타겟 장치에 연

결할 때는 디버거는 일반적으로 자동으로 시작된다 . F5 를 눌러서 디버깅 세션

을 시작하는 대신에 대상 메뉴에서 (Target menu) 부착 장치 (Attach Device)

를 사용한다 .

중단점 활성화하기와 관리하기 Enabling and Managing 플랫폼 빌더의 디버깅 기능들은 Windows 의 데스크 탑 응용프로그램의 디버거

와 마찬가지로 그 기능을 제공 한다 . 그림 4-8 에서 서술한 바와 같이 중단점을

설정하거나 , 코드의 한 줄씩 따라하거나 , 조사식 창 (Watch window) 을 사용하

여 변수의 값과 개체 특성을 변경하거나 볼 수있다 . 기억 하여야 할 것은 , 그러

나 , 런타임 이미지에서 중단점 사용 능력은 KdStub 라이브러리의 존재함에 따

라 달려있다 .

중단점을 설정하기 위해서는 , 비주얼 스튜디오비주얼 스튜디오의 디버그 메뉴

에서 중단점 전환 옵션을 사용하여 설정 한다 . 다른 방법으로는 , F9 을 눌러 현

재의 입력란에서 중단점을 설정하거나 코드 입력란의 왼쪽 여백을 클릭한다 . 선

택한 것을 보면 , 디버는 중담점을 인스턴스화 하거나 하지 못하는지에 대하여 플

랫폼 빌더는 중단점을 빨간 점이나 윈으로 표시한다 . 빨간 윈은 인스턴스화 하지

못하는 중단점을 나타낸다 . 만일비주얼 스튜디오 인스턴스가 대상 코드 (targe

code) 와 연결이 되어 있자 안을 경우 인스턴스가 없는 중단점이 발생되며 , 중단

점은 설정이 되었지만 로드가 안된 상태이며 , 디버거는 사용 불능 상태이며 , 디

버거는 사용불능이거나 , 디버거가 실행중이나 코드 실행이 멈추지 않은 상태에





서 발생된다 . 만일 디버거가 실행중일때에 중담점을 설정하면 , 장치는 반드시 디

버거가 중단점을 인스턴스화 하기전에 먼저 디버거로 진입하여야 한다

그림 4-8 Hello World 응용프로그램 (application) 디버깅 하기

플랫폼 빌더와 함께비주얼 스튜디오 에서 중단점을 관리하기 위한 옵션은 다음

과 같다 .

■ 소스 코드 , 스택 (Call Stack) 호출 과 창 분리 (Disassembly windows) 상

황에 맞는 메뉴 (context menu) 에서 중단점을 삽입 / 삭제를 선택하거나 디

버그 메뉴에서 전환 중단점을 선택하거나 또는 F9 을 누름으로서 중단점을

설정 , 삭제 , 사용가능 , 사용불능으로 전환 할 수 있다 .

■ 새 중단점 대화 창 (New Breakpoint dialog box) 이 대화상자는 디버그 메

뉴에서 새 중단점 아래 있는 하위 메뉴로 표시 할 수 있다 . 새 중단점은 대

화상자는 중단점의 위치와 조건을 설정 할 수 있도록 하여 준다 . 디버거는

반복 계산이나 특별히 지정된 값이 조건 중단점의 조건 값이 TRUE 일때만

멈추게 된다 .


■ 중단점 창 (Breakpoints window) 디버그 메뉴에서 윈도우 하위 메뉴에 있

는 중단점을 클릭하거나 Alt+F9 를 누름으로서 중단점 창을 표시 할 수 있

다 . 중단점 창은 설정된 중단점 대화상자를 중단점과 중단점 속성 설정을

가능케하는 목록을 나열한다 . 예를들면 , 위치 정보를 수동으로 지정하는

새 중단점 대화상자를 사용하는 대신 , 윈하는 중단점을 소스 코드에 직접 설

정한 후 조건 매개변수를 정의하기 위한하여 중단점 창의 특성을 표시한다 .

팁 중단점이 많은 경우

연습으로 중단점을 사용하기 . 너무 많은 중단점을 설정하거나 계속해서 재 실행을 선택 할 경우 디버깅의 효과에 영향을 미칠 수 있으며 , 시스템의 한개의 시점에 초점을 마추기가 어렵다 . 필요 함에 따라 중단점을 비활성화 하거나 재 활성화하는 것을 고려 해보아야 한다 .

중단점 제한새 중단점 대화상자 또는 중단점 창에서 중단점의 속성을 구성 할때 , 하드웨어

중단점 또는 소프트웨어 중단점을 설정 할 수 있는 하드웨어 단추를 발견 할 수

있다 . OAL 코드나 인터럽트 처리기 (interrupt handlers) 에서는 소프트웨어 중

단점은 사용 할 수 없는데 , 왜냐하면 중단점은 시스템의 실행을 완전히 멈추게

하면 안되기 때문이다 . 다른 시스템 프로세스 사이에서 , KITL 연결은 유효화 되

어 있어야하는데 . 이는 개발 워크스테이션에서 유일하게 이 연결을 통하여 통신

할 수 있기때문이다 . OAL 과 함께 KITL 인터페이스는 커널의 인터럽트 기반

(interrupt-based) 통신 방식을 사용한다 . 만일 , 인터럽트 처리기 기능 ( 함수 )

에서 한 개의 중단점을 설정 한다면 , 중단점에 다다르면 인터럽트 처리는 단일

스레드와 무인터럽트 기능 ( 함수 ) 임으로 시스템은 더 이상 통신할 수 없게된다 .

만일 인터럽트 처리기를 디버그하여야 한다면 , , 디버그 메시지나 하드웨어 중단

점을 사용 할 수 있다 . 그러나 , 하드웨어 중단점은 프로세스의 디버그 등록기에

인터럽트를 등록하기 위해서는 eXDI 준수 디버거 (JTAG Probe 과 같은 ) 를 필

요로 한다 . 일반적으로 , 한 개의 하드웨어 디버거 만이 프로세스 중 사용 가능 한

데 , 그럼에도 불구하고 JTAG 는 다수의 디버거를 사용 할 수 있다 . 하드웨어 지

윈 디버깅을 하기 위해서 KdStub 라이브러리를 사용 할 수는 없다 .

하드웨어 중단점을 구성하기 위해서는 다음 단계를 따라하면 된다 .

1. 디버그 메뉴를 열고 중단점을 클릭함으로써 중단점 창을 연다 .

2. 중단점 목록에서 중단점을 선택하고 오른쪽 마우스 버튼을 클릭한다 .

3. 중단점속성을 대화상자를 표시하기 위하여 중단점 속성을 클릭한 다음 하드

웨어 단추를 클릭한다 .


4. 하드웨어 확인 버튼을 선택한 다음 모든 대화 상자를 닫기 위해 확인을 두

번 클릭한다 .

그림 4-9 하드웨어 중단점 설정하기

학습 요약만일 , 런타임 이미지에서 KITL 과 디버거 라이브러리를 포함 시키면 플랫폼 빌

더 IDE 에서 디버거를 사용 가능케 하는 구성 단계는 간단해진다 . 타겟 장치 연

결 옵션 (Target Device Connectivity Options) 대화상자를 표시한 후 , 적합한

디버거와 전송을 선택한다 . 일반적으로 , 전송은 DMA 나 이더넷 (Etherne) 을 사

용하는데 , USB 나 시리얼 케이블을 사용하여 타겟장치에 워크스테이션을 연결

할 수 도 있다 .

플랫폼 빌더는 윈도우 바탕화면에서 찾아 볼 수있는 디버거들 같은 디버깅 기능

을 제공한다 . 중단점의 설정은 코드의 줄에서 줄의 단계로 , Watch 창을 사용하

여 변수의 값과 개체 속성의 변경과 보기를 설정 함으로 할 수 있다 . 플랫폼 빌더

역시 지정한 기준에 의하여 코드 실행을 중지 할 수 있는 조건 중단점을 지윈한

다 . 소프트웨어 디버깅을 위한 디버거의 선택은 KdStub 인데 , 그럼에도 불구

하고 , 다른 하드웨어 디버거나 JTAG 프로브 (Probe) 상에서 하드웨어 - 지윈 디

버깅 기반을 위한 플랫폼 빌더와 함께 eXDI 드라이버를 사용 할 수 있다 . 하드

웨어 - 지윈 디버깅은 커널에 로딩 하기전 시스템의 루틴을 분석하거나 OAL 컴

포넌트 와 인터럽트 처리기 기능을 소프트웨어 중단점이 사용 할 수 없는 위치에

서 사용 가능케 한다 .

학습 3 : CETK 를 사용하여 시스템 테스트하기 173

학습 3 : CETK 를 사용하여 시스템 테스트하기자동화된 소프트웨어 테스트는 지윈 비용과 개발 비용을 낮추고 제품의 질을 향

상시키는데 중요한 역활을 한다 . 이 것은 , OAL 코드를 구현하거나 , 새 장치 드

라이버를 추가하거나 , 타겟 장치를 위한 사용자화된 BSP 를 생성 할 때 특히 중

요하다 . 시스템의 새로운 시리즈를 프로덕션에 릴리스 하기전에 , 기능테스트 ,

단위테스트 , 스트레스테스트와 다른 종류의테스트를 통하여 시스템의 각 부분과

을 검증 하는 것과 일반 상태에서 타겟장치가 안정적으로 실해이 되는지를 실행

하여 보는 것이 매우 중요하다 . 시스템이 개발 중 일때 테스트 도구 와 스크립트

를 생성하거나 , 타겟 장치를 사용자의 환경과 비슷한 환경으로 작업하는 도중 결

함이 발견 되었을때 수정 하는 것 보다 제품이 시장에 도달한 후에 수정하는 것

은 더 많은 비용이 들 수 가 있다 . 시스템 테스트는 마케에 도달하기 전에 실행

되어져야한다 . 소프트웨어 개발 기간중효과적으로 시스템 테스트를 하기 위해서

는 CETK 를 사용 할 수 있다 .

이 학습을 마친 후 , 다음과 같은 것을 할 수 있음 :

■ CETK 검사 도구를 위한 일반적인 사용 시나리오 기술 .

■ 사용자 정의된 CETK 테스트를 생성 .

■ 타겟 장치에서 CETK 테스트를 실행 .


윈도우 임베디드 CE 테스트 키트 개요CETK 은 분리된 테스트이며윈도우 임베디드를 위한 플랫폼 빌더를 포함 한 응

용프로그램으로서 응용프로그램의 안정성 검증과 CE 테스트 목록에서 자동화

된 테스트 구성의 시리즈에 기반을 둔 장치 드라이버를 포함한다 . CETK 은 주

변기기의 여러 드라이버 카테고리를 위한 여러 기본 테스트를 포함하며 , 특정한

필요에 따라 사용자화 테스트를 생성 할 수 있다 .

참고 CETK 검사

CETK 에 포함된 기본 테스트 목록을 위해서는 마이크로소프트 MSDN 웹사이트 ht tp : / /msdn2.microsoft.com/en-us/library/aa917791.aspx 에 있는 윈도우 임베디드 CE 6.0 문서의“CETK테스트”섹션을 참조 하면 된다 .

CETK 아키텍처 (Architecture)그림 4-10 에서 서술 한바와 같이 , CETK 응용프로그램은 타겟 장치의 개발 컴

퓨터 상에서 실행되는 컴포넌트의 클라이언트 / 서버 (client/server) 솔루션이다 .



개발 컴퓨터는 타겟장치가 클라이언트 - 측 응용프그램 (Clientside.exe), 테스트

엔진 (Tux.exe), 테스트 결과 로거 (Kato.exe) 를 실행하는 동안 워크스테이션 서

버 응용프로그램 (CETest.exe) 을 실행한다 . 다른 것들 사이에서 , 이 아키텍처

는 개발 워크스테이션에서 다수의 서로 다른 장치상에서 동시에 여러 테스트들

을 실행할 수 있게하여준다 . 워크스테이션 서버와 클라이언트 - 측 응용프로그

램은 KITL, ActiveSync ® , 또는 윈도우 소켓 (Winsock) 의 연결을 통하여 통신

한다 .

그림 4-10 CETK 클라이언트 / 서버 아키텍처

CETK 응용프로그램은 다음과 같은 컴포넌트를 포함한다 .

■ 개발 워크스테이션 서버 (Development workstation server) CETest.exe

는 CETK 테스트를 실행하거나 관리 할 수 있도록 GUI(Graphic User

Interface) 를 제공한다 . 이 응용프로그램은 서버 설정과 매개변수 연결을

설정 할 수 있으며 , 타겟 장치에도 연결 할 수 있도록 하여준다 . 장치 연결

을 설정 하기 위해서 워크스테이션 서버는 클라이언트 쪽 응용프로그램을

자동으로 다운로드하고 시작하며 , 테스트 검사 요청을 제출하고 , 표시하기

위하여 실시간으로 캡쳐 로그 에 기반을 둔 테스트의 결과 를 컴파일 한다 .

■ 클라이언트 쪽 응용프로그램(Client-side application) 워크스테이션 서버

응용프로그램의 Clientside.exe 인터페이스는 테스트 엔진을 제어 하는 것

과 서버 응용프로그램에 테스트 결과를 반환한다 . 만일 , Clientside.exe 가

타겟장치상 에서 사용 할 수 없을 경우 , 워크스테이션 서버는 타겟장치에

통신 스트림 (stream) 을 설치 할 수 없다 .


■ 테스트 엔진(Test engine) CETK 테스트는 대상 장치에서 Tux.exe 가 로

드되고 실행되는 DLL 내에서 구현된다 . 일반적으로 , 테스트 엔진은 워크

스테이션 서버와 클라이언트 쪽 응용프로그램을 통하여 윈격으로 시작 할

수 있고 , Tux.exe 를 로컬에서 실행 할 수 있으며 , 워크스테이션 서버의 필

요 없이 독립으로 실행 할 수 있다 .

■ 테스트 결과 로거 (Test results logger) Kato.exe 는 로그 파일에 있는

CETK 의 결과를 추적한다 . Tux DLLs 은 이 로거를 사용하여 테스트의

성공 여부와 여러 사용자 정의된 출력 장치로 출력이 라우팅이 되었는지에

대한 추가 정보를 제공한다 . 이유는 모든 CETK 테스트는 동일한 로거와

형식을 사용하는데 , 특정 요구사항 에 의한 자동 결과 진행을 위한 사용하

거나자화 로그 파일 파서를 구현하거나 또는 기본 파일 파서 (parser) 를 사

용하는 것이 가능 하기 때문이다 .

참고 관리 코드를 위한 CETK (CETK for managed code)

CETK 의 관리 버전은 네이티브 (NATIVE) 와 관리 코드의 유효성을 확인 하기 위하여 사용이 가능하다 .관리 버전에 관한 자세한 사항은, MICROSOFT MSDN 웹사이트http://msdn2.microsoft.com/en-us/library/aa934705.aspx 의 WINDOWS EMBEDDED CE 6.0 문서에 있는 “TUX.NET TEST HARNESS”의 섹션을 참조하라 .

CETK 사용하기타겟 장치에서 여러 연결 옵션을 지윈하기 위하여 CETK 테스트 를 실행 할 수 있

다 . 타겟 장치에서 연결하기 위해서는 , KITL, Microsoft ActiveSync, 또는 TCP/

IP 를 사용 하여 타겟 장치를 연결하고 , 대상 쪽의 CETK 컴포넌트를 다운로드

하고 , 윈하는 테스트를 실행하고 , 개발 워크테이션 상에서 GUI 내에서 결과를

볼 수 있다 . 다른 한편으로는 , 타겟 장치가 이 연결 옵션들을 지윈하지 않을 경

우 , 테스트를 적합한 커맨드 라인과 옵션과 함께 로컬에서 실행하여야 한다 .

CETK 워크스테이션 서버 응용프로그램 사용하기 (CETK 워크스테이션 서버 응용프로그램 )워크스테이션 서버 응용프로그램으로 작업 하기 위해서는 , 개발 컴퓨터의윈도우

임베디드 CE 6.0 프로그램 그룹에 있는윈도우 임베디드 CE 6.0 테스트 키트를

클릭한 후 , 연결 메뉴를 열고 , 시작 클라이언트 (Start Client) 명령을 선택한다 .

설정 버튼을 클릭함으로 전송을 구성한다 . 만일 , 타겟 장치가 전환되어개발 워

크스테이션으로 연결 되었을 경우 , 연결을 클릭한 후 , 윈하는 타겟 장치를 선택

한 후 , 표시하기 위하여 필요한 바이너리와 통신 채널을 설정하기 위하여 확인

버튼을 클릭한다 . CETK 응용프로그램은 이제 타겟장치 상에서 테스트를 실행

할 준비가 되었다 .






그림 4-11 에서 서술한 바와 같이 , CETK 응용프로그램은 자동으로 사용 가능

한 장치 드라이버를 찾아내고 , 테스트를 실행 할 수 있도록 간편한 방법을 제공

한다 . 한 가지 방법으로는 CETK 가 감지한 모든 컴포넌트를 테스트를 할 수 있

도록 테스트 메뉴에 있는 시작 / 멈춤 테스트 아래 있는 장치 이름을 클릭한다 . 다

른 방법으로는 , 테스트 목록 노드 (Test Catalog node) 를 오른쪽 마우스 버튼을

클릭하여 시작 테스트 (Start Tests) 명령을 선택하는 방법이 있다 . 단일 컴포넌

트를 테스트 하기 위해서는 개개의 컨테이너를 확장하거나 , 개인 장치를 마우스

의 오른쪽 버튼으로 클릭하거나 , 빠른 시작 (Quick Start) 을 클릭한다 . 장치 노

드를 마우스의 오른쪽 버튼을 클릭하거나 도구의 하위메뉴를 열어 워크스테이션

서버 응용프로그램은 응용프로그램 검증도구 (Application Verifier), CPU 모니

터 , 리소스 사용 (Resource Consume), 윈도우 임베디드 CE 스트레스 도구

(Stress tool) 등의 액세스를 제공한다 .

그림 4-11 CETK 응용프로그램의 그래픽 사용자 인터페이스 (GUI)

테스트 도구모음 생성 (Create a Test Suite)모든 테스트를 한 번에 실행하는 것으로 부터 또는 개별적으로 빠른 테스트를 실

행하는 것으로 부터 벗어나려면 , 소프트웨어 개발 주기에서 반복적으로 실행할

수 있는 테스트의 사용자화 계열을 포함한 테스트 도구모음을 생성하면 된다 .

새 테스트 도구모음을 생성하기 위해서는 워크스테이션 서버의 테스트 메뉴 상

태에 있는 테스트 도구모음 편집기를 사용하여 생성한다 . 테스트 도구모음 편집

기는 그래픽 도구로서 도구모음에 있는 테스트를 편리하게 선택할 수 있게 하여

준다 . 테스트 키트 도구 모음 (.tks) 의 형식에서 테스트 도구모음 정의 를 내보

내기 할 수 있고 , 모든 워크스테이션 서버 응용프로그램이 테스트의 같은 세트를


실행하기 위하여 이 파일들을 추가 개발 컴퓨터로 가져오기 할 수 있다 . 이 .tks

파일들은 테스트 정의 아카이브를 위하여 기준으로 제공된다 .

기본 테스트 사용자화하기 (Customizing Default Tests)그래픽 사용자 인터페이스는 커맨드라인을 사용자화 함으로서 , 워크스테이션 서

버 응용프로그램이 테스트를 실행하기 위하여 테스트 엔진 (Tux.exe) 으로 전송

한다 . 테스트의 매개변수를 수정 하기 위해서는 , 테스트 목록안에 테스트를 오

른쪽 마우스 버튼으로 클릭하고 , 수정 명령 옵션 (Edit Command Line option) 을

선택한다. 예를들면, 저장 장치 블럭 드라이버 벤치마크 테스트(Storage Device

Block Driver Benchmark Test) 는 장치의 모든 섹터에 데이터를 읽고 쓰기 함

으로서 저장 장치의 성능을 분석한다 . 이 의미는 저장 장치에 현존하는 모든 데

이터를 지워버릴 수 있다는 것을 의미한다 . 데이터를 읽어버리는 것을 방지하기

위해서는 , 저장 장치 블럭 드라이버 벤치마크 테스트는 기본 테스트를 건너뛴다

. 저장 장치 블럭 드라이버 벤치마크 테스트를 성공적으로 실행하기 위해서는 커

맨드라인 수정과 특수 매개변수인 -zorch 를 명시적으로 추가하여야 한다 .

지윈되는 커맨드라인 매개변수는 개개의 CETK 테스트 구현에 의존한다 . 테스

트는 여러개의 구성 매개변수를 필요로 하거나 지윈할 수 도 있는데 , 테스트를

위한 장치 드라이버를 인식하기 위한 색인 번호나 또는 테스트를 실행하기 위한

추가 등이다 .

참고 CETK 테스트를 위한 커맨드라인 매개변수

커맨드라인 매개변수와 같은 CETK 테스트의 모든 목록의 추가정보를 위해서는 , MICROSOFT MSDN 웹사이트의 http://msdn2.microsoft.com/en-us/library/ms893193.aspx , 윈도우 임베디드 CE 6.0 문서에 있는 “CETK 테스트”를 참조하라 .

수동으로 Clientside.exe 실행하기

만일 런타임 이미지에윈도우 임베디드 CE 테스트 키트 목록 항목을 포함 시켰거

나 , 워크스테이션과 서버와 함께 CETK 컴포넌트를 다운로드 하였거나 , 파일 뷰

어 윈격 도구를 사용하여 개발 워크스테이션에서 컴포넌트를 내보내기를 하거나 ,

Clientside.exe 를 타겟장치 상에서 시작하여 워크스테이션 서버에 수동으로 연결

을 설치한다 . 만일 , 타겟장치가 이 목적을 위하여 실행 대화상자를 제공하지 않

을 경우 , 플랫폼 빌더 IDE (Platform Builder IDE) 에서 대상 메뉴를 열고 , 프로

그램 실행을 선택한 후 , Clientside.exe 를 선택한 다음 실행을 선택한다 .

Clientside.exe 는 특정 워크 스테이션 서버 응용프로그램에 연결 하거나 , 설치

된 드라이버를 감지하고 , 자동으로 테스트를 실행하도록 다음과 같은 매개변수

를 지윈한다 .

http://msdn2.microsoft.com/en-us/library/ms893193.aspx

http://msdn2.microsoft.com/en-us/library/ms893193.aspx


Clientside.exe [/i=<Server IP Address> | /n=<Server Name>] [/p=<Server Port Number>] [/a]

[/s] [/d] [/x]

Wcetk.txt file 또는 HKEY_LOCAL_MACHINE/Software/Microsoft/CETT 레

지스트리 키에서 이 매개변수를 정의 할 수 있는 것을 아는 것이 중요한데 , 그럼

으로 명령을 매개변수없이 Clientside.exe 로 시작 할 수 잇다 . 이 경우 ,

Clientside.exe 는 루트 디렉터리에서 Wcetk.txt 를 검색한 후 , 타겟 장치상의 윈

도우 디렉터리에서 검색한 후 , 개발 워크스테이션상에서 디렉터리를 릴리스 한

다 . 만일 , Wcetk.txt 가 이 위치상에서 존재하지 않는다면 , CETT 레지스트리

키를 검색한다 . 표 4-5 는 Clientside.exe 매개변수를 요약한 것이다 .

표 4-5 Clientside.exe 시작 매개변수

Command

Line

Wcetk.txt CETT Registry Key Description

/n SERVERNAME ServerName (REG_SZ)

호스트 서버 이름 지정 . /i 를 동시에 사용 못 함 과 해상도를 위한 . 시스템 도메인 이름 (DNS) 필요

/i SERVERIP ServerIP (REG_SZ) 호스트 IP 주소 지정 /n/i 를 동시에 사용하지 못 함

/p PORTNUMBER PortNumber (REG_DWORD)

워크스테이션 서버 인테페이스로 구성 할 수 있는 서버 포트 지정 .

/a AUTORUN Autorun (REG_SZ) (1) 로 설정되면 , 연결이 설치된 후 장치는 자동으로 테스트를 시작한다

/s DEFAULTSUITE DefaultSuite (REG_SZ)

실행하기 위한 기본 테스트 도구모음의 이름을 지정

/x AUTOEXIT Autoexit (REG_SZ) (1) 로 설정되면 , 테스트가 완료되면 응용프로그램은 자동으로 종료된다 .

/d DRIVERDETECT DriverDetect (REG_SZ)

(0) 로 설정되면 장치의 드라이버 감지는 비활성화 된다 .


독립 모드에서 CETK 테스트 실행Clientside.exe 는 개발 워크스테이션에서 CETest.exe 로 연결되며 , 연결을 사

용할 수 없는 장치에서 유용하게 CETK 테스트를 연결없이 실행 할 수 있도록

하여준다 . 만일 , 런타임 이미지에윈도우 임베디드 CE 테스트 키트 카탈로그 항

목을 포함 시키려고 하면 , 로그 파일에서 테스트 결과를 추적 할 수 있는 Kato

로깅 엔진 (Kato.exe) 을 암시적으로 시작할 수 있도록 테스트 엔진 (Tux.exe)

을 시작한다 . 예를들면 , 마우스 테스트 (mousetest.dll) 를 실행하고 결과를

test_results.log 라는 파일에서 추적하기 위해서는 다음과 같은 커맨드라인을

사용 할 수있다 .

Tux.exe -o -d mousetest -f test_results.log

참고 Tux 커맨드 라인 매개변수

TUX.EXE 커맨드라인 매개변수를의 모든 목록을 위해서는 MICROSOFT MSDN 웹사이트 http://msdn2.microsoft.com/en-us/library/aa934656.aspx 의 윈도우 임베디드 CE 6.0 문서에 있는“TUX커맨드라인 매개변수” 섹션을 참조 한다 .

사용자화된 CETK 도구 테스트 솔루션 생성하기CETK 은 여러 테스트를 포함하고 있는데 , 기본 테스트는 테스팅에 필요한 모든

사항을 내포하고 있지는 않다 . 특별히 사용자화된 장치 드라이버를 BSP 에 추

가하려면 , 사용자화된 장치 드라이버를 위한 사용자 - 정의된 테스트를 구현하

는 옵션을 제공하기 위해서는 CETK 는 Tux 프레임워크에 의존한다 . 플랫폼

빌더는 몇 번의 마우스 클릭으로 골격 Tux 모듈을 생성하기위한 WCE TUX DLL

템플릿을 포함하고 있다 . 드라이버를 실행하기 위해서 로직 (logic) 을 구현 할

때 , 현재의 테스트 구현의 소스 코드를 컴토하여 보는 것이 용이하다 . CETK 는

소스코드를 포함하는데 , 윈도우 임베디드 CE 공유 소스 (Shared Source) 를 위

한 설정 마법사에서 윈도우 임베디드 CE 공유 소스의 일부분으로 설치 할 수있

다 . 기본값은 %_WINCEROOT%₩Private₩Test 이다 .

사용자화된 Tux 모듈 생성하기Tux 프레임워크에 반응하는 사용자화된 테스트를 생성 하려면 , 런타임 이미지

의 OS 설계에 하위프로젝트를 추가 함으로서 윈도우 임베디드 CE 하위프로젝

트를 시작하고 WCE TUX DLL 템플릿을 선택한다 . 이 것으로 말미암아 Tux

마법사는 드라이버가 요구하는 골격을 생성하는데 사용자화 할 수있다 .

골격 Tux 모듈을 사용자화 하기위해서는 다음과 같은 파일들을 편집하여야만

한다 .


■ 헤더 파일 Ft.h 한 개의 함수 표 헤더와 함수 표 입력을 포함한 TUX

Function Table (TFT) 를 정의한다 . 테스트 로직을 포함한 함수 표는 함

수의 테스트 ID 와 연결한다 .

■ 소스 코드 파일Test.cpp 테스트 함수를 포함한다. 골격 Tux모듈은사용자

화된 테스트를 Tux DLL 에 추가 할 수 있는 단일 TestProc 를 포함한다 .

사용자화된 드라이버를 로드하거나 실행하기 , Kato 를 통하여 로그 작업 ,

테스트가 완료 되었을 때 Tux 테스트 엔진에 적절한 상태 코드를 반환 하기

위해서 샘플 코드로 변경한다 .

CETK 테스트 응용프로그램에서 사용자화 테스트 정의하기 골격 Tux 모듈은 완전 작동되며 , 코드 수정없이도 솔루션을 컴파일 하거나 런타

임 이미지를 빌드 할 수 있다 . 타겟 장치에서 새 테스트 함수 ( 기능 ) 를 실행하

기위해서는 , CETK 워크스테이션 서버 응용프로그램에서 사용자 - 정의된 테스

트를 구성하여야 한다 . 이 목적을 위하여 , 테스트 메뉴에서 사용자 정의된 명령

을 클릭함으로서 시작할 수 있도록 CETK 는 사용자 - 정의된 테스트 마법사를

포함한다 . 그림 4-12 는 골격 Tux 모듈을 실행하기 위하여 사용자 - 정의된 테

스트 마법사를 구성하는 것을 보여준 것이다 .

그림 4-12 사용자 -정의된 테스트 마법사에서 사용자화된 테스트 구성하기

사용자화 테스트 디버깅하기Tux 테스트는 Tux DLLs 에서 코드와 로직 구현에 의존함으로 테스트 코드를 디

버그 할 필요가 있다 . 한 가지 문제점을 집고 넘어가야 할 것은 테스트 루틴에


서 중단점을 설정 할 수 있으나 , 코드 실행이 중단점을 멈추게 할 경우 , 워크스

테이션 서버 응용프로그램 (CETest.exe) 과 클라이언트 쪽 응용프로그램

(Clientside.exe) 사이의 연결을 잃어 버리게 된다 . 중단점 대신 디버그를 사용

하는 것을 고려 해볼 필요가 있는데 , 만일 , 디버깅 하는 동안 중단점을 꼭 사용

하여야 한다면 , 이 학습에서 언급한 바와 같이 타겟 장치상에서 독립모드

(Clientside.exe) 를 실행한다 . 오른쪽 마우스 버튼을 클릭한 다음 커맨드라인 편

집 (Edit Command Line ) 을 선택함으로 워크스테이션 서버 응용프로그램에서

필요한 커맨드라인을 표시할 수 있다 .

CETK 테스트 결과 분석하기CETK 는 골격 Tux 모듈에서 보여준것과 같이 , Kato 를 사용하여 테스트 결과

를 로그 하여야 한다 .

g_pKato->Log(LOG_COMMENT, TEXT("This test is not yet implemented."));

워크스테이션 서버 응용프로그램은 Clientside.exe 를 통하여 이 로그들을 자동

적으로 재개하며 , 개발 워크스테이션에 저장 할 수 있다 . 다른 도구를 사용하여

이 로그 파일들을 액세스 할 수 있다 . 예를들면 , 독립모드에서 CETK 을 사용한

다고 하면 , 파일 보기 윈격 도구를 사용하여 개발 워크스테이션에 로그파일을 가

져오기 할 수 있다 .

그렘 4-13 에서 서술한 것과 같이 CETK 는 C:₩Program Files₩Microsoft

Platform Builder₩6.00₩Cepb₩Wcetk 폴더에 위치한 가져오기 로그 파일을

편리하게 보기위한 일반 CETK 파서 (Cetkpar.exe) 를 포함한다 . 일반적으로 ,

이 파서는 워크스테이션 서버 응용프로그램에서 오른쪽 마우스 버튼을 클릭하고

결과 보기를 선택함으로서 시작 하거나 직접 Cetkpar.exe 를 실행하여 시작 할

수 있다 . PerfLog.dll 에 기반을 둔 특정한 성능 테스트는 쉼표로 구분된 값 (CSV)

의 형식으로 파스 할 수있으며 , 성능 테이타를 요약하기 위하여 스프레드시트에

연다 .

이 목적을 위하여 , CETK 는 한 개의 PerfToCsv 파서 도구를 포함하며 , 특수

분석 시나리오를 위하여 사용자화된 파서를 개발 할 수도 있다 . Kato 로그 파일

은 일반 문자 형식을 사용 한다 .


그림 4-13 CETK 테스트 결과 분석

학습 요약윈도우 임베디드 CE 테스트 키트는 확장 할 수 있는 도구로서 , 타겟 장치상에서

드라이버와 응용프로그램을 연결 모드와 독립모드에서 테스트 할 수 있게 하여

준다 . 만일 , 타겟장치가 KITL, ActiveSync, 또는 TCP/IP 연결을 지윈하지 않

을 경우 , 독립 모드에서 CETK 도구를 실행하는 것이 매우 용이하다 . 대개 , 일

반적으로 , 개발자는 타겟장치의 BSP 에 테스트 드라이버를 추가하기 위하여

CETK 를 사용한다 .

CETK 는 Tux 테스트 엔진에 의존하는데 , 이 것은 모든 테스트 DLLs 의 공통

후레임워크를 지윈한다 . Tux DLLs 은 실제의 테스팅 로직을 내포하며 , 타겟장

치에서 로드하거나 드라이버를 실행한다 . Tux DLLs 은 로그 파일에서 테스트

의 결과를 추적하기 위하여 Kato 와 인터페이스 하는데 , 사용자화된 파서나 스

프래드시트와 같은 다른 도구에서 진행하거나 , CETK 테스트 응용프로그램에서

직접 액세스 할 수 있다 .

학습 4: 부트 로더 (Boot Loader) 테스트하기 183

학습 4: 부트 로더 (Boot Loader) 테스트하기부트 로더의 일반 작업은 메모리에 커널이 로드한 후 , 장치가 전윈이 켜진 후에

OS 시작 루틴을 호출 하는 것이다 . 특별히윈도우 임베디드 CE 상에서 부트 로

더는 BSP(Board Support Package) 의 일부분일부분이며 , 핵심 하드웨어 플랫

폼 , 런타임 이미지 다운로드 , 커널 시작등을 초기화하는 것을 관리한다 . 최종

제품에 부트 로더를 포함하거나 런타임 이미지에 부트 스트랩을 하지 출시한다

해도 , 부트 로더는 개발 주기중 유용하게 쓰일 수 있다 . 또 다른 바로는 , 부트 로

더는 복잡한 런타임 이미지의 배포를 간단히 하는데 도움을 줄 수도 있다 . 부트

로더는 이더넷 , 시리얼 케이블 , DMA, 또는 USB 연결로 런타임 이미지를 다운

로드 할 수있도록 개발자의 컴퓨터를 연결함으로 개발시간을 절약 하게 하여주

는 편리한 기능이다 . 윈도우 임베디드 CE 6.0 을 위한 플랫폼 빌더에 포함된 소

스 코드를 기반으로 하여 새 하드웨어 기능을 지윈하기위한 사용화된 부트 로더

를 개발 할 수 있다 . 예를들면 , 부트 로더를 사용하여 런타임 이미지를 RAM 으

로 부터 플래시 메모리로 복사 할 수 있으며 , 이 방법은 또 다른 플래시그림 메

모리 프로그래머나 IEEE 1149.1- 호환 테스트 액세스 포트와 영역 - 스캔 기술

을 필요로하지 않는다 . 그러나 , 디버깅과 테스트 부트 로더는 복잡한 작업을 하

는데 , 커널이 로드되기 전에 실행되는 코드를 작업하기 때문이다 .

이 학습을 마친 후 , 다음과 같은 것을 실행 할 수 있다 .

■ CE 부트 로더 아키텍처 설명 .

■ 부트 로더를 위한 공용 디버깅 기술 나열 .

에상 학습 시간 : 15 분 .

CE 부트 로더 아키텍처 (Boot Loader Architecture)모호한 부트 로더에 관한 기능을 굳이 나열하자면 , 부트 로더는 직선 , 기억장치

의 불휘발성 (nonvolatile), CPU- 액세스할 수 있는 메모리에서 pre-boot 루틴

과 함께 작은 프로그램을 Bootstrap 하는 것이다 . 메모리 주소의 타겟 장치에서

부트 로더 이미지 설치는보드 제작사가 제공하는 JTAG 프로브에 의하여 설치되

어 있는 모니터 프로그램을 통하여 CPU 는 코드를 불러오기 시작하고 , 부트 로

더는 전윈을 켜거나 시스템을 재 설정 할때 실행 된다 . 일반적으로 부트 로더 작

업은 이 단계에서 Central Processing Unit (CPU) 를 초기화 , 메모리 제어기 ,

시스템 시계 , Universal Asynchronous Receiver/Transmitters (UARTs), 이

더넷 제어기 , 사용 가능한 다른 하드웨어 장치 , 런타임 이미지 다운로딩과 이것

을 바이너리 이미지 빌더 (BIB) 레이아웃에 의하여 RAM 에 런타임 이미지를 복

사 , 하는 것과 StartUp 함수 ( 기능 ) 로 커너 뛰는 것을하는 것을 포함 한다 . 마


지막 런타임 이미지는 기록은 이 기능 ( 함수 ) 의 시작 주소를 포함한다 . StartUp

함수는 커널 초기화 루틴을 호출 함으로서 부트 프로세스를 계속 진행한다 .

그림 4-14 에서 서술한 바와 같이 여러 부트 로더가 실행하는 작업 과 복잡한 다

른 작업을 이행 함에 도 불구하고 , 부트 로더 개발을 용이하게 하기 위하여 공통

적인 특성을 윈도우 임베디드 CE 가 정적인 라이브러리에서 커버한다 . 부트 로

더의 아키텍처에 관한 영향은 어떻게 부트 로더 코드를 디버그 하느냐에 달려있

다 . 부트 로더 개발에 관한 자세한 사항은 제 5 장 , “보드 지윈 팩키지 사용자

화 하기” 에서 찾아 볼 수 있다 .

그림 4-14 윈도우 임베디드 CE 부트 로더 아키텍처

윈도우 임베디드 CE 부트 로더는 다음과 같은 코드 부분과 라이브러리에 아키

텍처 기반을 두고 있다 .

■ BLCOMMON 빠른 실행을 위하여 플래시 메모리에서 RAM으로 부트 로더

를 복사하기 , 이미지파일 내용 디코딩하기 , checksums 를 확인하기 , 로드

진행을 추적하기 위한 기본 부트 로더를 구현 . BLCOMMON 는 지정된 하

드웨어 사용자화를 처리하기 위하여 잘 정의된 OEM 함수를 진행토록 호출

한다 .

■ OEM code 이 코드는 BLCOMMON 라이브러리를 지윈하기 위하여 , 하드

웨어 플랫폼을 구현하여야 한다 .

■ Eboot 이더넷 연결을 통해 런타임 이미지를 다운로드 할 수 있는

Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer

Protocol (TFTP), 과 User Datagram Protocol (UDP) 서비스를 제공한다.

■ Bootpart 부트 로더가 바이너리 ROM 이미지 파일 시스템 (BinFS) 분할을

생성하고 같은 저장 장치에서 다른 파일 시스템 분할을 할 수 있는 저장 분

할 루틴을 제공한다 . Bootpart 역시 부트 매개변수를 저장하기 위한 부트

분할을 생성할 수 있다 .

학습 4: 부트 로더 (Boot Loader) 테스트하기 185

■ Network drivers 기본 설치를 캡술화하여 여러 일반 네트워크 제어 장치

의 프리미티브 (primitives) 를 액세스할 수 있다 . 라이브러리를 위한 인터

페이스는 일반 인터페이스인데 , 그럼으로 , 부트 로더와 OS 는 인터페이스

를 사용 할 수 있다 . 부트 로더는 런타임 이미지를 다운로드 하기 위하여 인

터페이스를 사용하고 OS 는 인터페이스를 사용하여 플랫폼 빌더에 KITL 연

결을 구현한다 .

부트 로더를 위한 디버깅 기술부트 로더는 일반적으로 두 개의 구분된 부분으로 구성되어 있다 . 처음 부분은

어셈블리 언어로 되어있고 C 언어로 쓰여있는 두 번째 부분으로 건너뛰기 전에

시스템을 설치한다 . 만일 , 4-14 에서 서술한 바와 같이 BLCOMMON- 에 기반

을 둔 아키텍처를 사용한다면 , 어셈블리 코드를 디버그 할 필요는 없다 . 만일 장

치가 UART 를 장착하고 있으면 , C 코드에서리테일 MSG 매크로를 사용하여

테이타를 시리얼 출력 인터페이스를 사용하여 사용자가 표시 할 수 있도록 전송

할 수 있다 .

경우에 따라서 어셈블리 또는 C 코드를 디버그 하기위해서는 , 다음과 같은 서로

다른 디버깅 기술이 사용 가능하다 .

■ Assembly code 처음 시작 코드를 위한 일반 디버깅 기술은 LEDs 에 의존

하는데 , 시리얼 통신 인터페이스를 위한 7- 세그먼트 LEDs 와 UARTs 디

버깅 보드와 같은 것에 의존 하는데 , 왜냐하면 상대적으로 간단하게 일반 목

적 입력 / 출력 (General Purpose Input/Output (GPIO)) 를 액세스 할 수 있

고 , 한 개의 입력 / 출력 줄의 상태를 등록 하거나 수정 할 수 있기때문이다 .

■ C Code C-코드 수준에서 디버깅은 훨씬 쉬운데, 왜냐하면, 사용자는 고급

통신 인터페이스와 디버깅 매크로를 액세스 할 수 있기때문이다 .

■ Assembly and C code 만일 하드웨어 디버그 (JTAG probe) 가 사용 가능

되어있으면 , 플랫폼 빌더를 사용하여 eXDI 드라이버와 접속함으로서 부트

로더를 디버그 할 수 있다 .

시험 팁

인증 시험에 합격하기 위해서는 , 부트로더 , 커널 , 장치 드라이버 , 응용프로그램을 디버그하는 여러가지 기술들을 알아야한다 .


학습 요약부트 로더를 디버깅 하는 것은 매우 복잡한 작업이므로 , 하드웨어 플랫폼에 관하

여 깊은 이해가 필요하다 . 만일 , 하드웨어 디버그가 사용이 가능하다면 , 하드

웨어지윈 디버깅을 위하여 eXDI 와 함께 플랫폼 빌더를 사용 할 수 있다 . 그렇

지 않으면 , C 코드에서 시리얼 통신 인터페이스를 통해 디버깅 어셈블리 코드와

C 스타일 매크로의 디버그 메시지를 출력하기 위하여 LED 보드를 사용하는 것

을 고려해 보는 것도 좋을 것이다 .

학습 4: KITL, Debug Zones, 와 CETK 도구를 사용하여 시스템 디버깅과 테스팅하기 187

학습 4: KITL, Debug Zones, 와 CETK 도구를 사용하여 시스템 디버깅과 테스팅하기

이 학습에서 , Device Emulator BSP 상에 있는 OS 디자인에 디버그 콘솔 응용

프로그램을 하위프로젝트로 추가한다 . 디버깅을 사용하기 위해서는 , 런타임 이

미지에 KdStub 와 KITL 를 포함 시키고 , 해당 타겟 장치 연결 옵션을 설정한다 .

디버그 영역을 지윈하기 위한 구현을 위해 콘솔 응용프로그램의 소스 코드를 수

정하고 , Pegasus 레지스트리 키에서 유용하게 실행 할 수 있는 디버그 영역을

지정하고 , 비주얼 스튜디오 의 출력 창에 서 디버그 메시지를 검토하기 위하여

커널 디버거를로 타겟 장치에 연결한다 . 후 반에는 , CETK 를 사용하여 런타임

이미지에 포함되어 있는 마우스 드라이버를 테스트 한다 . 비주얼 스튜디오 에

서 기본 OS 디자인을 생성하기 위해서는 , 학습 1 에 요약되어 있는 “OS 디자인

생성 , 구성 , 빌딩” 의 프로세스를 따라한다 .

참고 상세한 단계별 지침

이 학습에서 보여준 진행을 성공적으로 습득하기 위해서는 이 책의 부록 “학습 4 를 위한 상세한단계별 지침” 문서를 참조하라 .

� KITL 활성화와 디버그 영역 사용하기

1. 학습 1에서비주얼 스튜디오 에서 생성한 OS design project를 연 후, OS 디

자인 속성을 편집하기 위하여 OSDesign 이름을 마우스의 오른쪽 버튼으로

클릭하고 Properties 를 선택한다 . 구성된 Properties 를 선택한 후 옵션을

빌드한다 . 런타임 이미지를 위한 Enable KITL 확인란을 선택한다 .

2. OS 디자인 속성 페이지대화 상자에서 커널 디버거 기능을 활성화 하고 , 변

경을 적용하고 대화 상자를 닫는다 .

3. 현재의 디버그 빌드 구성 작업에서 이전의 단계에서 유효화한 커널 디버거

와 KITL 컴포넌트가 빌드 이미지에 포함 되어있는지 확인한다 .

4. 빌드 메뉴에서 고급 빌드 명령 (Advanced Build Commands) 아래있는 현

재 BSP 재 빌드 (Rebuild Current BSP) 와 하위프로젝트를 선택하여 OS

디자인을 빌드한다 ( 만일 다음 단계에서 오류가 발생 할 경우 Clean Sysgen

를 실행한다 ).

5. 대상 메뉴를 열고 타겟장치 연결 옵션 대화상자를 표시하기 위한 연결 옵션

을 클릭한다 . 다음과 같은 설정을 한 후 확인을 클릭한다 .


6. 하위프로젝트를 OS 디자인에 추가 한 후 WCE 컨솔 응용프로그램 템플릿

(WCE Console Application template) 을 선택한다 . 프로젝트를

TestDbgZones 로 명명한 후 하위프로젝트 마법사에 있는” A Typical

Hello World Application” 옵션을 선택한다 .

7. 하위프로젝트에 새로운 헤더 파일 DbgZone.h 를 추가한 후 다음과 같은 영

역을 정의한다 .

#include <DBGAPI.H>

#define DEBUGMASK(n) (0x00000001<<n)

#define MASK_INIT DEBUGMASK(0)

#define MASK_DEINIT DEBUGMASK(1)

#define MASK_ON DEBUGMASK(2)

#define MASK_ZONE3 DEBUGMASK(3)










#define MASK_FAILURE DEBUGMASK(13)

#define MASK_WARNING DEBUGMASK(14)

#define MASK_ERROR DEBUGMASK(15)

#define ZONE_INIT DEBUGZONE(0)

#define ZONE_DEINIT DEBUGZONE(1)

#define ZONE_ON DEBUGZONE(2)

#define ZONE_3 DEBUGZONE(3)










#define ZONE_FAILURE DEBUGZONE(13)

매개변수 구성 설정

Download Device Emulator (DMA)

Transport Device Emulator (DMA)

Debugger KdStub


#define ZONE_WARNING DEBUGZONE(14)

#define ZONE_ERROR DEBUGZONE(15)

8. TestDbgZones.c 파일의 include 에 DbgZone.h 헤더 구문을 추가 한다 .

#include "DbgZone.h"

9. 다음과 같이 _tmain 함수위의 디버그 영역을 위한 dpCurSettings 변수를

정의한다 .

DBGPARAM dpCurSettings =

{

TEXT("TestDbgZone"),

{

TEXT("Init"), TEXT("Deinit"), TEXT("On"), TEXT("n/a"),

TEXT("n/a"), TEXT("n/a"), TEXT("n/a"), TEXT("n/a"),

TEXT("n/a"), TEXT("n/a"), TEXT("n/a"), TEXT("n/a"),

TEXT("n/a"), TEXT("Failure"), TEXT("Warning"), TEXT("Error")

},

MASK_INIT | MASK_ON | MASK_ERROR

};

10. _tmain 함수의 첫 줄에 모듈의 디버그 영역을 등록한다 .

DEBUGREGISTER(NULL);

11. 리테일 MSG 와 DEBUGMSG 매크로를 사용하여 다음과 같이 디버그 영역

과 연결 하고 디버그 메시지를 표시한다 .

DEBUGMSG(ZONE_INIT,

(TEXT("Message : ZONE_INIT")));

³ÆÝÞ¿œMSG(ZONE_FAILURE || ZONE_WARNING,

(TEXT("Message : ZONE_FAILURE || ZONE_WARNING")));

DEBUGMSG(ZONE_DEINIT && ZONE_ON,

(TEXT("Message : ZONE_DEINIT && ZONE_ON")));

12. 응용프로그램을 빌드하고 , 타겟 장치에 연결한 다음 , 타겟 제어 창을 사용하

여 응용프로그램을 시작한다 .

13. 디버그 출력 창에서는 첫 디버그 메시지만 표시된다는 것을 명심 하여야한

다 .

4294890680 PID:3c50002 TID:3c60002 Message : ZONE_INIT

14. 남아있는 디버그 영역을 기본값으로 활성화하기 위하여 레지스트리 편집기

(Regedit.exe) 를 연다 .

15. HKEY_CURRENT_USER₩Pegasus₩Zones 키를 열고 REG_DWORD 값

을 생성하여 TestDbgZone(dpCurSettings 변수에서 모듈의 이름을 정의 )

를 호출한다 .


16. 32 비트 DWORD 값의 낮은 16 비트와 일치하는 16 개의 명명된 영역의 값

을 0xFFFF 값으로 설정하여 활성화한다 . ( 그림 re 4-15 참조 ).

17. 비주얼 스튜디오에서 , 응용프로그램을 재 실행하면 다음과 같은 출력을 볼

수 있다 .

4294911331 PID:2270006 TID:2280006 Message : ZONE_INIT

4294911336 PID:2270006 TID:2280006 Message : ZONE_FAILURE || ZONE_WARNING

4294911336 PID:2270006 TID:2280006 Message : ZONE_DEINIT && ZONE_ON

18. 비주얼 스튜디오의 출력 창에서 결과를 확인하거나 , 다른 디버그 영역을 활

성화 하거나 비활성화 하기 위하여 레지스트리에서 TestDbgZone 값을 변

경한다 .

그림 4-15 HKEY_CURRENT_USER₩Pegasus₩Zones: "TestDbgZone"=dword:FFFF

참고 플랫폼 빌더에서 디버그 영역을 활성화와 비활성화 하기

플랫품 빌더에서 TestDbgZone 모듈을 위하여 디버그 영역을 제어 할 수는 없는데 왜냐하면 , 이 모듈을 위한 응용프로그램 진행은 유효한 영역을 열거나 수정하기전에종료되기 때문이다 . 유일하게 디버그 영역을 관리 할 수 있는 방법은 그래픽 응용프로그램이나 DLL 을 위하여 플랫폼 빌더에 모듈을 로드하는 것이다 .


� CETK 를 사용하여 마우스 드라이버 테스트 실행하기

1. 개발 컴퓨터상에서 시작 메뉴로 부터 Windows CE 테스트 키트 응용프로그

램을 연다 . ( 윈도우 임베디드 CE 6.0 메뉴를 연 후윈도우 임베디드 CE 테

스트 키트를 클릭한다 ).

2. 윈도우 임베디드 CE 테스트 키트 창에서 , 연결 메뉴를 열고 타겟장치에 연

결을 설치하기 위하여 클라이언트 시작 (Start Client ) 을 클릭한다 .

3. 연결을 클릭한 후 연결 관리자 창에서 장치를 선택한다 .

4. 그림 4-16 에서 보는 바와 같이 장치에 워크스테이션 서버 응용프로그램이

성공적으로 연결 되는지 확인 , 필요한 CETK 바이너리를 배포 , 사용가능 한

장치 드라이버 감지 , 계층적 트리에서 모든 컴포넌트의 목록을 표시하는지

확인한다 .

5. Windows CE 테스트 목록 노드를 마우스의 오른쪽 버튼으로 클릭한 후 모

든 테스트 해제를 클릭한다 .

6. 목록에서 개개의 노드를 열고 마우스 테스트 확인란을 선택한다 .

7. 테스트 메뉴를 열고 시작 / 멈춤 테스트를 클릭 함으로서 마우스 테스트를 실

행한다 .

8. 타겟 장치상에서 필요한 마우스 동작을 선택한다 .

9. 테스트가 종료되었으면 테스트 입력을 마우스의 오른쪽 버튼을 클릭하고 결

과 보기를 선택함으로서 테스트의 보고서를 액세스 할 수 있다 .

10. CETK 파서에서 결과를 검토함으로서 , 성공을 알림 , 건너뛰기 , 테스트 프로

시저를 검토 할 수 있다 .

그림 4-16 윈도우 임베디드 CE 테스트 키트 창의 장치 목록

192 이 장의 복습

이 장의 복습윈도우 임베디드 CE 를 위한 플랫품 빌더는 디버깅을 쉽게 이해 할 수 있는 세트

와 도구를 제품을 릴리스 하기전에 최종 시스템 구성 확인과 에러를 유발 시키는

윈인을 분석하고 제거할 수 있는 테스팅 도구를 포함하고 있다 . 디버깅 도구는

비주얼 스튜디오 와 융합되어 KITL 연결을 통하여 타겟장치와 통신한다 . 다른

방법으로는 , 메모리 덤프 (memory dump) 를 생성하여 CE Dump File Reader

를 사용하여 오프라인 모드에서 시스템을 디버그 할 수 있고 , 특정한 사후 디버

깅을 할때 매우 유용하다디버깅 환경은 확장 할 수 있는데 , 그 의미는 eXDI 드라

이버가 표준 커널 디버거의 한계를 뛰어 넘어 하드웨어 지윈 디버깅을 실행하는

것이다 .

커널 디버거는 커널 컴포넌트와 응용프로그램을위한 혼합된 디버거이다 . 만일

KdStub 와 KITL 을 활성화 하여 타겟장치에 연결한다면 , 디버깅은 자동으로 시

작된다 . 사용자는 타겟 제어 창을 사용하여 디버깅과 CEDebugX 명령들을 기반

으로 하는 고급 시스템 테스트를 실행하는 응용프로그램을 시작 할 수 있다 . 그

러나 , 명심 하여야 할 것은 이 레벨로 인하여 중단 처리기 또는 OAL 모듈에서 중

단점을 설정 할 수 없거나 , 커널은 단일 - 스레드 모드로 작동하고 , 만일 코드 실

행이 멈춤으로 되면 , 개발 워크스테이션과의 통신을 멈춘다 . 중단 처리기를 디

버그하기 위해서는 , 하드웨어 디버거 또는 디버그 메시지들을 사용한다 . 디버그

메시지 기능은 런타임 이미지를 재 빌드하지 않고 정보 출력을 제어 할 수있도록

디버그 영역을 지윈한다 . 디버그 메시지를 사용하여 부트 로더에서 C- 코드 부

분을 역시 디버그 할 수 있으며 , 어셈블리 코드 부분은 반드시 하드웨어 디버거

나 LED 패널을 사용하여야 한다

CETK 테스트 응용프로그램을 기반으로 한 시스템 테스팅을 중앙 처리화 하기

윈한다면 KITL 을 필요로 하는데 , 그럼에도 불구하고 CETK 테스트는 독립 모

드에서도 실행이 가능하다 . 만일 타겟장치를 위한 고급 BSP 를 개발하려고 한

다면 , CETK 를 사용하여 사용자화된 Tux DLLs 에서 자동 또는 반 - 자동 컴포

넌트 테스트를 실행할 수 있다 . 플랫폼 빌더는 특정한 테스트에 필요한 확장을

할 수 있는 골격 Tux 모듈 을 생성 할 수있는 WCE TUX Dynamic-Link Library

템플릿을 포함한다 . 사용자는 CETK 테스트 응용프로그램에서 사용자화된 Tux

DLL 을 구성 할 수 있고 , 각기 테스트를 실행하거나 큰 테스트 모음의 일부분으

로 실 행 할 수 있다 . 왜냐하면 , 모든 CETK 테스트는 동일한 로깅 엔진과 로그

파일 형식을 사용하기 때문인데 , 사용자는 같은 파서 (Parser) 도구를 사용하여

기본값과 사용자 - 정의된 테스트를 분석할 수 있다 .

이 장의 복습 193

주요 용어이 주요 용어가 무슨 뚯인지 아십니까 - 이 책의 끝 부분에 있는 단어장에서 용

어를 찾아봄으로써 답안을 검토 할 수 있다 .

■ 디버그 영역 (Debug Zones )

■ KITL

■ 하드웨어 디버거 (Hardware debugger)

■ dpCurSettings

■ DebugX

■ 타겟 제어 (Target Control)

■ Tux

■ Kato

추천 연습이 과에서 보여준 시험 요소들을 성공적으로 마스터하기 위해서 다음과 같은 작

업을 하여보자 .

메모리 누수 감지하기메모리 블럭을 할당하고 해제하지 않음으로 메모리 누수를 야기시키는 컨솔 응

용프로그램을 위하여 하위프로젝트를 OS 디자인에 추가한다 . 이 과에서 사용된

툴들을 사용하여 문제를 발견하고 정정한다 .

사용자화된 CETK 테스트WCE TUX Dynamic-Link Library 를 위하여 OS 디자인에 하위프로젝트를 추

가한다 . 윈도우 임베디드 CE 테스트 키트에 Tux DLL 을 빌드하고 이 것을 등록

한다 . CETK 를 실행하고 테스트의 결과를 확인한다 . Tux DLL 에서 중단점을

설정하고 독립 실행에서 CETK 테스트를 실행함으로써 코드를 디버그 한다 .

준비 키트( Preparation Kit)download.microsoft.com/download/0/B/9/0B98A0AE-C7AF... · 윈도우...

Documents

Transcript of 준비 키트( Preparation Kit)download.microsoft.com/download/0/B/9/0B98A0AE-C7AF... · 윈도우...