Trouble shooting

Source code 가 보이지 않을때(소스 경로 변경)

ELF 파일을 로드 후 아래와 같이 소스코드가 보이지 않고 빗금으로 표기된 경우가 자주 확인 할 수 있었을 것입니다. 이런 경우는 Build한 Host machine에서 Debugging하지 않고 다른 Host에서 Network으로 연결하여 Debugging하거나 Build한 Host machine이라 하더라도 폴더를 옮긴 경우 발생할 수 있습니다.

1) 우선 아래 그림과 같이 빗금에 커서를 두고 우클릭한 후 View Info.를 클릭합니다.

2) Build 당시 Source Path 정보를 확인할 수 있습니다.

소스 경로를 변경하는 방법

sYmbol.SourcePath.Translate [A] [B]

소스 경로 일부 [A]를 [B]로 바꿉니다

Ex) sYmbol.SourcePATH.Translate "/data/user/wanghwan/u-boot" "\\210.221.215.153\wanghwan\u-boot"

위의 명령을 이용한 경우 아래와 같이 소스 path가 변경되어 소스코드를 찾아올 수 있게 됩니다.

ELF File 로딩 시 경로 변경하는 방법

Data.LOAD.Elf [ImgFile] /strippart [string|value] /path [dir]

/STRIPPART “심볼 파일경로의 제거 할 경로파트 | 경로파트 개수”

/PATH “실제 파일경로의 추가 할 경로파트”

Ex) Data.LOAD.Elf C:\T32\AdvancedEdu\u-boot\u-boot /nocode /STRIPPART

“/data/user/wanghwan/” /PATH “\\210.221.215.153\wanghwan/”

or

Data.LOAD.Elf C:\T32\AdvancedEdu\u-boot\u-boot /nocode /STRIPPART 4.

/PATH “\\210.221.215.153\wanghwan/”

or 만약 \\210.221.215.153\wanghwan/ 가 Network Drive “Z:\”로 연결되었다면

Data.LOAD.Elf C:\T32\AdvancedEdu\u-boot\u-boot /nocode /STRIPPART 4. /PATH “Z:\”

sYmbol Path를 추가(add)하는 방법

아래 명령으로 Source Path를 추가하게 되면 ELF에서 명기된 Path에서 Source파일을 찾지 못할 경우 추가된 Path로부터 소스코드를 찾아 보여주게 됩니다.

sYmbol.SourcePATH + [dir]

하위 디렉토리를 포함하지 않은 특정 폴더만 소스 경로로 추가합니다. 단, 소스파일 이름이 같을 경우 먼저 지정된 파일을 사용합니다

sYmbol.SourcePATH.SetRecurseDir [dir]

지정한 폴더와 하위폴더들을 자동으로 소스 경로로 지정합니다. 단, 소스파일 이름이 같을 경우 먼저 지정된 파일을 사용합니다

Ex) sYmbol.SourcePATH.SetRecurseDir C:\T32\AdvancedEdu\u-boot

TRACE32 attach 가 안 될때

1) 기존에 잘 사용하던 보드의 JTAG 연결이 갑자기 안 될 경우

TRACE32와 타깃보드가 제대로 연결되어 있는지 확인해 봅니다
TRACE32, 보드, 컨버터 등을 바꾸어 봅니다
JTAG clock을 낮추어 봅니다
“sys.u”대신 “sys.m.attach à break”를 시도해 봅니다
PowerView내의 열려있는 창(Data.List 등)을 닫고 연결을 시도해 봅니다
사용하던 cmm에 변경된 것이 있는지 확인해봅니다

2) 처음 테스트 해 보는 타깃일 경우 추가 확인사항

PowerView 를 업데이트 해 봅니다
테스트 환경에 맞는 cmm을 사용해 봅니다
GND를 포함하여 JTAG 시그널이 제대로 연결되어있는지 확인해 봅니다
별도의 JTAG연장케이블을 사용한다면, 길이를 줄여봅니다

3) Diag 테스트를 통해 JTAG Chain값을 읽어 보기

“diag 0x16001” 또는 “diag 3400” 명령을 통해 JTAG chain 값을 읽어 볼 수 있습니다
JTAG chain값을 잘 읽을 수 있다면, “TRACE32 ~ 프로세서“간의 경로는 문제 없다고 판단해도 됩니다

Ex) “diag 0x16001”이 잘 안 되는 경우

이 경우는 TRACE32와 SoC간 JTAG interface가 문제가 있는 경우이므로 Hardware 담당자에게 문의하여야 합니다.

Ex) “diag 16001”이 잘되는 경우

이 경우 TRACE32와 SoC간 JTAG interface에 문제가 없는 경우입니다. 따라서 SYStem.Option 설정이나CoreSight 관련 설정 그리고 Secure JTAG과 같은 원인에 의해 연결이 안되는 경우일 수 있습니다.

Ex) “diag 3400”이 잘 되는 경우

이 경우도 TRACE32와 SoC간 JTAG interface에 문제가 없는 경우입니다. 따라서 SYStem.Option 설정이나CoreSight 관련 설정 그리고 Secure JTAG과 같은 원인에 의해 연결이 안되는 경우일 수 있습니다.

4) JTAG 연결 시도 시 에러메시지를 보고 문제를 예상해 볼 수 있습니다

“target power fail”

: Target이 꺼져있거나 JTAG 케이블이 연결되지 않은 경우, TRACE32로 공급되는 reference voltage가 공급되지 않는 경우 발생합니다

“target processor in reset”

: Target 프로세서가 리셋 상태일 때 발생합니다

“emulation debug port fail“

: JTAG 접근에 문제가 있거나, JTAG clock이 너무 높은 경우 주로 발생합니다

“emulation debug port time-out”

: JTAG 경로보다는, 메모리접근에 문제가 있는 경우 주로 발생합니다

리셋 타이밍에 관련된 경우, 대부분 “SYStem.Mode.Attach à break”로 피해갈 수
있습니다

Breakpoint 설정 시 Break되지 않는 현상 대처법

BreakPoint설정이 되었고 설정한 함수가 실행되는 것이 확실함에도 불구하고 Target이 정지하지 않는 경우가 있습니다. 이 경우 여러 원인이 있을 수 있으나 다음 항목을 체크하기 바랍니다.

소스코드 매칭을 위한 ELF 파일이 Target에서 동작하는 binary와 같은 버전인지
실행 중 Address Relocation을 실행하는 지
Dynamic loading에 의해 설정해 놓은 SW BreakPoint를 지운 것은 아닌지
Target Code에서 Debug Logic의 BreakPoint Register의 값을 바꾸는지

step 실행시 갑자기 다른 code 가 수행될때 원인 및 대처법

Assembly 또는 C source level Debugging시 Step 기능을 실행할 경우 갑자기 다른 코드로 Step되는경우가 있습니다. 이 경우는 대부분은 Exception에 의한 코드 실행 때문에 발생하는 경우입니다. Debugging시 보통 Target은 정지상태를 빈번하게 만드는데 SoC Peripheral 설계시 대부분은 Core의 상태와 별개로 설계(Asynchronous)되기 때문에 발생되는 경우입니다.

이 경우 CPU 메뉴 >> System Setting… 항목을 클릭하고 IMASKASM/IMASKHLL가 체크되어 있는 지 확인하기 바랍니다. 해당 옶션는 Assembly/C code level Step시 Interrupt를 Masking하는 옵션입니다.

특정 함수의 symbol 이 보이지 않는 원인 및 대처법

ELF 파일을 로드했음에도 불구하고 아래 그림과 같이 Source코드가 보이지 않고 Label만 존재하는 경우가 종종 있습니다. 이 경우에는 Build시 Compile옵션에 관한 문제입니다. GCC의 경우 –g 옵션을 확인하고 만약 다른 Compiler를 사용한 경우라면 Debug Option을 찾아 설정 후 재 build하고 다운로드 하기 바랍니다.

Debugger의 Memory Access 속성 설정

열려있는 윈도우 데이터 Update 주기 변경하기(SETUP.UpdateRATE)

TRACE32는 기본적으로 열어 놓은 윈도우의 내용을 10번 Update합니다. 만약 Update 주기 변경이 필요한 경우 해당 명령을 사용하면 되겠습니다.

주로 PXP/Veloce/ZEBU와 같은 Emulator 개발환경이나 NCsim과 RTL Simulation 개발환경과 같은 느린 Target에서 Debugging시 빈번한 Update는 많은 시간을 요구하기 때문에 TRACE32 UI응답에 영향을 미칠 수 있습니다. 이런 경우 Update 주기를 변경하면 좀더 빠른 UI 응답을 얻을 수 있습니다.

SETUP.UpdateRATE [시간|초당회수]

Ex) SETUP.UpdateRATE 20. ; 초당 20번 Update

SETUP.UpdateRATE 50ms ; 50ms 마다 한번씩 Update

CPU core 상태 체크 주기 변경하기(SYStem.POLLING.SLOW)

Emulator/Simulation과 같은 느린 Target에서의 개발환경에서는 CPU 상태를 Polling하는 주기가 빈번한 경우 TRACE32 UI 응답이 느린 경우가 발생 할수 있습니다. 이런 경우 Polling rate를 조절하여 응답을 개선할 수 있습니다.

SYStem.POLLING.[DEFault|FAST|SLOW]

Ex) SYStem.POLLING.SLOW ; Target Processor 상태 Polling주기를 늘림

특정 메모리 공간 TRACE32 접근 속성 변경하기(MAP.DenyAccess)

MAP.DenyAccess [Address Range]

Ex) MAP.DenyAccess 0x1000000++0xFFF ; 지정된 영역의 TRACE32 Access를 무시하도록 설정

특정 메모리 dump창을 연 경우 TRACE32는 지정된 Address로부터 데이터를 읽어 보여주기를 시도합니다. 이때 해당 영역에 물리적으로 문제가 있다면 BUS-lock 상태를 초래하게 될 것이고 이와 같이 실수로 인해 디버깅하는데 불편함을 겪을 수 있습니다. 해당 영역의 메모리 Dump 창을 열더라도 TRACE32로 하여금 지정된 영역에 대하여 접근을 금지하도록 할 수 있게 합니다.

특정 메모리 공간 TRACE32 접근 속성 변경하기(MAP.UpdateOnce)

TRACE32는 열린 메모리창의 값들을 [SETUP.UpdateRATE]에 의해 설정된 횟수만큼 주기적으로 Update 합니다. Emulator 또는 RTL simulator target과 같은 느린 시스템에서는 반복적인 Update가 속도 대비 많을 일들을 하게되면 TRACE32 UI 응답 특성이 매우 느려질수 있습니다. 이 때 반복적인 Update가 필요 없는 메모리와 같은 특정 구간에 대해 STEP이나 BREAK 이벤트 발생 시에만 Update하도록 하여 Target으로부터 데이터 접근양을 줄이도록 합니다.

MAP.UpdateOnce [Address Range]

Ex) MAP.UpdateOnce 0x10000000++0xFFFF ; 한번만 Update할 구간 설정

특정 메모리 공간 TRACE32 접근 속성 변경하기(MAP.NoUpdateOnce)

MAP.UpdateOnce 구간 중 특정 영역을 해당 속성을 해제하고자 할 때 사용하는 명령입니다.

MAP.NoUpdateOnce [Address Range]

Ex) MAP.UpdateOnce 0x10000000++0xFFFF ; UpdateOnce구간 설정

MAP.NoUpdateOnce 0x10001000++0xFF ; UpdateOnce구간 해제

특정 메모리 공간의 데이터 영역에 Big Endian속성 주기(MAP.BE)

Code영역은 Little Endian을 사용하지만 데이터 영역에 대해 Big Endian 속성을 주어 Big Endian으로 보이도

록 하는 명령입니다. CortexM series에서 주로 사용합니다.

MAP.BE [Address Range]

Ex) MAP.BE 0x00000000++0xFFFFFFFF ; 해당 영역중 데이터 영역에 대해 Big.Endian으로 관리하도록

1) 명령 전

2) MAP.BE 0x00000000++0xFFFFFFFF 명령 후

특정 메모리 공간 TRACE32 접근 속성관련 설정된 정보들 보기(MAP.List)

위의 MAP 명령들에 대한 설정이 있는 경우 해당 설정들에 대한 정보를 보여 줍니다.

MAP.List

아래 그림은 MAP.List 때 보여주는 명령 후 결과 예입니다.

특정 메모리 공간 TRACE32 접근 속성 변경하기(SYStem.Option.SOFTLONG)

TRACE32는 일반적으로 Soft BreakPoint 설정 시 BreakPoint 명령어 Length에 따라 해당 bus width로 메모리에 접근하여 Breakpoint 명령을 삽입합니다. 그러나 어떤 경우에는 Hardware 제약 때문에 반드시 정해진 width로 접근해햐 하는 경우가 있는데 SYStem.Option.SOFTLONG 명령은 BreakPoint명령어 Length에 상관없이 항상 32bit 단위로 Access하도록 합니다.

SYStem.Option.SOFTLONG [ON|OFF]

Ex) SYStem.Option.SOFTLONG ON ; breakpoint설정을 위해 반드시 32bit length로 Access함

JTAG 혹은 TRACE 시그널을 점퍼로 연결할 때 노이즈를 줄여 봅시다

배경지식 및 문제발생

TRACE32를 사용하다 보면, 타깃 특성상 JTAG 혹은 TRACE 핀을 점퍼 선을 통해 연결해야 하는 경우가 있습니다.

점퍼를 통해 TRACE32와 타깃보드를 연결하는 경우, PCB의 커넥터에 직접 연결하는 경우보다 신호의 왜곡이 많을 수 있고, TRACE32 사용의 첫 문턱인 “sys.u”을 넘지 못하고 좌절하는 경우도 발생합니다. 혹은 평소에는 JTAG이 잘 연결되어 있다가, ETM TRACE를 받기 시작하면, JTAG연결이 끊기는 경우도 있습니다. 그럴 경우 아래와 같이 우리 주변에서 사용되고 있는 케이블에서 노이즈를 줄일 수 있는 힌트를 얻어볼 수 있겠습니다.

Q1. 왜 TRACE32커넥터에는 GND핀이 이리도 많을까?

< ARM 20핀 JTAG 커넥터 > < MIPI 10핀 JTAG 커넥터 > < MIPI 20핀 TRACE 커넥터 >

Q2. 왜 시중에 판매되는 케이블들은 서로 꼬아져 있을까?

< 오디오 케이블 > < LAN 케이블 > < HDMI 케이블 >

Q3. 노트북 파워 아답타 끄트머리의 볼록한 저것은 무엇일까?

< A사 노트북 파워 > < B사 노트북 파워 >

접지선을 통해 신호간의 간섭을 상쇄해 봅시다

"Q1. 왜 TRACE32커넥터에는 GND핀이 이리도 많을까?" 에 대한 답변이 되겠습니다.

TRACE32와 타깃보드를 점퍼로 연결하는 경우, 접지선 하나로 모든 GND를 대신하는 것이 일반적입니다. 경험적으로 큰 문제는 없었습니다만, Lauterbach는 시그널 수 만큼 GND 핀을 연결하는 것을 권장하고 있습니다.

그 이유는, 나란히 배치된 선을 따라 흐르는 두 시그널은 서로간에 간섭을 일으킵니다. 그 크기는 경우에 따라 다르지만, 일반적으로 선 간격이 좁을수록, 선을 따라 흐르는 신호가 고속일수록 그 영향이 큽니다. 그럴 경우, 두 선 사이에 접지선을 배치하여 상호간의 영향을 없앨 수 있습니다. 이를 위해 TRACE32와 타깃보드간에 연결되는 플랫케이블(Debug Module, CombiProbe 등)은 “시그널-GND-시그널-GND-…”의 반복되는 순서로 선 배치가 되어 있습니다.

결과적으로 GND선을 하나만 연결하지 말고, 여러 개를 연결하여 접지 효과를 볼 수 있습니다.

동일한 맥락으로, PCB설계에서 레이어 적층 순서에 대한 아래의 사진도 참조해 보시기 바랍니다.

선을 서로 꼬아 간섭을 상쇄해 봅시다

"Q2. 왜 시중에 판매되는 케이블들은 서로 꼬아져 있을까?" 에 대한 답변이자, 위의 “접지선을 통해 신호간의 간섭을 상쇄해 봅시다” 에서 연결되는 내용입니다.

실제로 TRACE32와 타깃보드의 JTAG 시그널을 점퍼로 연결하는 경우, 플랫케이블을 사용하기보다는 점퍼선 몇 가닥을 사용하는 경우가 많습니다. 이런 경우 신호 사이사이에 접지선을 넣어 간섭을 상쇄하는 것이 불가능해지는데요, 그럴 때는 아쉬운 대로 GND선 하나와 시그널 하나를 쌍으로 꼬아주는 노이즈를 감쇄시키는 방법을 사용해 볼 수 있겠습니다.

그 원리와 이론적인 배경은 아래의 사진을 참조하면 좋겠습니다.

굳이 비슷한 것을 찾자면, 아래의 2번 “스파이럴 실드”와 유사한 방법이 되겠습니다. 실제로 TRACE32 기술지원에서 이 방법을 적용하여 문제를 해결한 사례가 있었습니다.

< 케이블 실드의 원리 > < 전자 실드 케이블의 종류 >

주) 스파이럴 실드 :
동선 몇 개를 테이프 상에 밀착하여 나열하고, 신호선의 주위를 칭칭 감은 실드 구조로, “가로감기 실드” 라고도 한다.
실드 효과를 높이기 위해 역방향으로 또 한 겹을 감은 “더블 스파이럴 실드” 를 사용하기도 한다

페라이트(훼라이트)코어를 사용해 봅시다

"Q3. 노트북 파워 아답타 끄트머리의 볼록한 저것은 무엇일까?" 에 대한 답변이 되겠습니다.

페라이트코어는 “니켈-아연” 혹은 “망간-아연”을 원료로 가운데가 빈 원기둥모양의 제품입니다. 여러 가지 크기의 제품이 있으며, 케이블을 페라이트코어로 통과시킴으로써 노이즈 감쇄효과를 얻을 수 있습니다.

< 다양한 크기의 페라이트코어 > < 페라이트코어 사용 방법 >

아직까지 TRACE32 기술지원에 적용하여 확실한 개선을 보지는 못했지만, 개인 차량의 원격 시동기가 블랙박스의 노이즈로 인해 제대로 동작하지 않아 달게 되었는데 효과가 있었습니다.

웹브라우저에서 “페라이트코어” 혹은 “훼라이트코어”로 검색해 보시면, 오디오, DMB, 무선조종모형 등 다양한 분야에서 노이즈 감쇄를 위해 페라이트코어를 사용한 다양한 글을 찾으실 수 있습니다.

다만, 주의할 것은 항상 페라이트코어가 노이즈를 감쇄시켜주는 것은 아니니, 실제 적용 후 개선사항이 있는지 확인해 보아야 하겠습니다.

적용사례

GND선 추가 + 신호선 꼬기

고객사의 Cortex-M3 타깃에 적용했던 방법입니다. JTAG 동작에는 별 문제가 없지만, ETM TRACE를 시작하면 노이즈로 인해 JTAG 연결도 끊어지는 문제가 있었습니다.

GND선이 원래는 하나밖에 없었지만, 3개로 추가하였고, 플랫케이블을 분리하여 꼬아주어 신호간의 간섭을 상쇄시켜 ETM TRACE가 문제없이 되었던 케이스 입니다.

GND선과 신호 선을 쌍으로 꼬기

고객사의 Cortex-M3 타깃에 적용했던 방법입니다. 위의 경우와 마찬가지로 ETM TRACE를 받거나 AC모터가 동작하면 JTAG연결이 끊어지는 문제가 있었습니다.

앞의 방법 중 “GND선과 시그널선을 쌍으로 꼬기” 방법을 적용하여 문제를 해결하였습니다.

결론

아날로그 세상은 워낙 오묘하여 눈에 보이지 않는 영향으로 그 테스트 결과가 달라지는 경우가 있습니다.

TRACE32와 타깃보드를 점퍼로 연결하는 경우 JTAG연결이 잘 되지 않는다면, 아래와 같은 사항을 확인해 보시기 바랍니다.

- JTAG clock 속도를 낮추어 봅니다

- 점퍼선의 길이를 가능한 짧게 합니다

- GND선을 시그널 수 만큼 확보하고, GND선과 시그널을 쌍으로 꼬아 노이즈를 감쇄시킵니다.

- 경우에 따라 페라이트코어(훼라이트코어)를 사용하여 노이즈를 줄일 수 있습니다

Trouble Shooting

목차