MDSTECH

SRAM과 로컬 메모리에는 ECC Protection 기능이 있습니다.

Power-On 후 SRAM과 해당 ECC 비트는 랜덤한 값을 유지합니다.

따라서 값의 조합에 따라 ECC 블록(일반적으로 64비트 또는 32비트)이 bus error로 표시되거나 표시되지 않을 수 있습니다.

Application이 플래시로 프로그래밍 되면 부트코드에서 SRAM을 초기화 합니다.

SRAM에서 Application이 동작하는 경우에는(예: 초기 테스트나 플래시 프로그래밍을 위해) 다음 명령을 사용하여 디버거를 통해 SRAM을 초기화해야 합니다.

Data.Set EA:0x40000000--0x4000BFFF %Quad 0x0000000000000000

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

Nexus 프로브를 사용한 에너지 측정시에 active termination을 off 하는 것이 좋습니다.

Analyzer.disable(Nexus trace probe hardware 비활성화)와 NEXUS.OFF(Nexus Cell off)사이에는 큰 차이가 없습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

디버거에서 SYStem.Up을 실행할 수 없고 대신 전원 오류가 감지되면,

두 개의 디버거(e.g. JTAG 디버그 케이블과, NEXUS 프로브)가 같이 연결되어 있는지 확인해야 합니다.

이는 허용되지 않는 구성으로, JTAG 동글이나 NEXUS 프로브를 디버깅에 사용할 수 없게 만듭니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

MPC5XXX 프로세서들은 censorship feature기능이 구현되어 있습니다.

Censorship 기능이 활성화되면 디버거의 JTAG 접근이 차단되어 디버깅이나 트레이싱이 불가능합니다.

프로세서 내부 JTAG로직을 통해서 MPC5XX 프로세서의 consorship 유무를 감지할 수 없습니다.

Ceonsorship이 활성화되어 있다면 JTAGID 읽기는 가능하지만, 그 이후의 JTAG을 이용한 프로세서 접근이 모두 실패합니다.

TRACE32디버거에서는 “Debug Port Fail”이 발생하며, B::Area 영역에서 다음과 같은 오류가 나타납니다.

l JTAGID=0x______1D

l Error: received invalid OSR (0x000)

l is the device censored?

프로세서가 의도적(사용자 또는 프로세서 자체적으로)으로 검열된 경우, 다음 명령어를 순차적으로 입력하여 JTAG 접근을 재시도 할 수 있습니다:

l SYStem.DETECT CPU

l SYStem.Option.KEYCODE 0xFEEDFACECAFEBEEF

l SYStem.Up

주의: 

• 비밀번호(키코드)를 모르거나 잘못된 경우(예: shadow row를 실수로 지운 이후), 프로세서는 영구적으로 잠깁니다.

플래시 내의 응용 프로그램이 프로세서 해제 기능을 제공하지 않는 한(예: CAN을 통해), 복구할 수 없습니다.

• 일부 프로세서들은 SYStem.Option.KEYCODE 의 상위 및 하위 32비트 부분을 교환해야 합니다.

(예: 0xFEEDFACECAFEBEEF 대신 0xCAFEBEEFFEEDFACE)

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다

"Qorivva MPC5xxx/SPC5xx Debugger and NEXUS Trace" 문서(C:T32pdfdebugger_mpc5500.pdf 파일) 내의

'Tracing VLE or mixed FLE/VLE applications' 섹션을 참고하시기 바랍니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

Qorivva MPC5xxx/SPC5xx Debugger and NEXUS Trace 메뉴얼(debugger_mpc5500.pdf)의

"Memory Coherency During run-time Memory Access" 챕터를 확인해보세요

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

디버거의 기본 설정을 사용할 경우, 타깃 시스템의 성능에 영향을 미치지 않습니다.

단, 특정 조건에서는 디버거를 사용하면 타킷 시스템의 성능에 영향을 미칠 수 있습니다:

- SYStem.Option.STALL 옵션을 활성화하면 프로세서의 NEXUS 메시지 FIFO가 가득 찼을 때 코어가 멈추게 됩니다.

- 실행 시간 메모리 접근 옵션을 활성화하면 프로세서가 실행 중일 때 디버거가 메모리 접근을 시도할 수 있습니다.

이 동작은 프로세서의 메모리 접근과 동시에 발생하여 약간의 지연을 초래할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

TRACE32 PowerTools는 NEXUS 어뎁터(LA-7630 NEXUS AutoFocus)를 사용하여 MDO16을 지원합니다.

Mictor38 연결시 주의할 점

NEXUS용 표준 Mictor38 커넥터는 12개의 MDO 신호(MDO0..11)만 정의합니다.

MDO12..15 신호는 이후에 추가되어 남은 핀에 할당되었습니다.

손상을 방지하기 위해 LA-7631(converter LA-7630/Mictor76 to Mictor38)은 기본적으로 이 신호들을 연결하지 않습니다.

MDO16동작을 가능하게 하려면, LA-7631의 상단에 있는 J100..J103을 0옴 저항으로 연결해야 합니다.

어댑터에 0 옴 저항이 장착된 경우, MDO16을 지원하지 않는 대상에 5V 이상의 전압이 연결되지 않아야 합니다.

추가로, Glenair51 커넥터(LA-7632)는 MDO16을 지원하지 않습니다.

LA-7630 관련 정보 : https://www.lauterbach.com/products/LA-7630

LA-7631 관련 정보 : https://www.lauterbach.com/products/LA-7631

LA-7632 관련 정보 : https://www.lauterbach.com/products/LA-7632

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

XPC56XX EVB 마더보드와 프로세서 미니 모듈을 사용할 때,

JTAG 커넥터, 트레이스 커넥터, 마더보드의 핀 배열 등 디버그와 트레이스 신호가 연결되는 여러 지점이 있습니다.

이때, 이 지점이 종단 처리(termination) 되어 있지 않으면 반사된 신호의 간섭으로 디버거 연결에 문제가 생길 수 있습니다.

특히 EVB 마더보드로 가는 TCK 신호가 문제를 일으킬 수 있습니다.

'configuration error' 또는 'debug port fail' 등의 오류 메시지와 함께 디버거 연결에 실패하면,

TCK 신호가 마더보드로 가지 않게 하거나, 종단 처리(220~470 Ohm 저항으로 GND에 연결)하면 문제를 해결할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

이 문제의 원인은 디버거와 EBI 사용 사이에 다중화된 두 신호인 EVTI와 EVTO에 있습니다.

(* EVTI/EVTO: NEXUS Event Input/Output)

MPC5510 시리즈의 경우, 이러한 신호의 기능은 NPC_PCR 레지스터의 EVT_EN 비트로 제어되며, 이는 디버거에 의해 제어됩니다.

디버거는 기본적으로 핀 기능을 EVTI/EVTO로 설정합니다.

신호를 EBI(R/!W 및 !TA) 용도로 사용하려면 TrOnchip 창에서 EVTEN 설정을 사용하세요:

TrOnchip.EVTEN ON ; 신호가 EVTI/EVTO 기능을 가집니다. EBI 기능 비활성화됨(기본값)
TrOnchip.EVTEN OFF ; 신호가 EBI 또는 GPIO 용도로 사용 가능

중요 참고 사항 :

• NEXUS 어댑터 LA-7610을 사용하는 경우:
  LA-7610은 EVTI를 영구적으로 구동하므로, EVTI를 디버그/트레이스 커넥터에서 물리적으로 분리해야 합니다.
  
  
• NEXUS 어댑터 LA-7630을 사용하는 경우:
  TrOnchip.EVTEN이 OFF로 설정되면 EVTI 핀은 TRISTATE가 됩니다.
  문제를 방지하기 위해 EVTI/EVTO를 디버그 커넥터에서 분리하는 것을 권장합니다.
  
  
• EBI 용도로 신호를 사용하는 경우:
  EVTI/EVTO를 디버그 커넥터에서 분리하는 것이 권장됩니다.
  디버거가 연결되지 않은 경우, 종단되지 않은 신호는 EBI 문제를 일으킬 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

MPC5500 계열의 충돌 우선순위 관리 때문에, 낮은 우선순위의 메시지는 동시에 발생하는 높은 우선순위의 메시지에 의해 취소될 수 있습니다.

자세한 내용은 칩 문서를 참조하십시오.

모든 메시지에는 다음과 같은 우선순위가 있습니다:

1. WPM - 2. OTM - 3. BTM - 4. DTM

WPM(Watchpoint Message) 또는 OTM(Ownership Trace Message)과 동시에 발생한 BTM(Branch Trace Message)은 누락되고,

BTM이 손실 되었다는 오류 메시지가 전송됩니다.

누락된 BTM 다음 분기문은 'branch w/ sync.' 메시지를 큐에 넣습니다.

이 메시지 안의 카운트 값은 마지막으로 성공한 BTM 메시지 이후에 실행된 순차적인 명령어 수를 반영합니다.

이 수에는 충돌로 인해 메시지가 생성되지 않은 분기문을 포함합니다.

WPM, OTM 또는 BTM과 동시에 발생한 DTM(Data Trace Message)은 누락됩니다.

이후의 읽기/쓰기 동작은 'read/write w/ sync.' 메시지를 큐에 넣습니다.

다른 궁금한 사항이 있으시다면 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

NEXUS 포트가 어떤 이유로든 필요하지 않거나 Nexus 프로브가 JTAG 동글의 대체물로만 사용되는 경우, Nexus 클라이언트를 비활성화할 수 있습니다.

그러면 NEXUS 관련 핀에서의 모든 NEXUS 활동이 꺼집니다.

이 동작을 설정하려면 NEXUS.OFF 명령어를 사용해야 합니다.

그러나 시스템 시작 후 이 명령어를 사용할 경우 주의해야 합니다.

올바른 CPU가 감지되거나 설정되기 전에 (SYStem.Up) Nexus 클라이언트를 비활성화하면, 해당 CPU가 인식된 후 자동으로 Nexus 클라이언트가 다시 활성화됩니다.

이러한 동작을 피하려면 시작 스크립트에서 SYStem.Up 명령어 전에 SYStem.DETECT.CPU 명령어를 먼저 사용해야 합니다.

NEXUS.OFF 명령어가 알 수 없는 명령어로 나타나면 소프트웨어 업데이트를 요청하십시오

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

TRACE32는 chip external watchdog timer를 컨트롤하기 위한 몇 가지 방법들이 있습니다.

1. GPIO제어, 시리얼 통신 등으로 watchdog을 비활성화 할 수 있다면,

T32 연결시에 Data.STARTUP 또는 Data.STANDBY 명령어로 watchdog을 비활성화 할 수 있습니다.

2. GPIO 토글링 등의 방식으로watchdog을 사용해야 한다면, Data.TIMER 명령어로 정지된 코어에 watchdog을 수행할 수 있습니다.

3. 몇몇 디버그 케이블과 NEXUS 어뎁터들은 명시된 핀들을 통해 chip external watchdog 기능을 제공합니다.

이 핀들은 SYStem.CONFIG.EXTWDTDIS 명령어로 제어합니다.

해당 핀은 정적 레벨이나 코어 상태와 함께 변하는 동적 레벨 중에서 watchdog 기능을 구현할 수 있습니다.

아래 표는 디버그 하드웨어에서 지원하는 watchdog 비활성화 핀에 대해서 알려줍니다.

이 핀은 타깃 전원이 들어와 있고, 디버그 세션이 활성화될 때에만 동작합니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

Cortex-M

Armv8/v9 Cortex-A/R

Armv7 Cortex-A/R

Greeh Hills Software 컴파일러에서 디버그 정보를 생성하고 싶다면, 버전에 따라 다음 옵션을 적용하여야 합니다.

C-Code : -g -dual_debug -dwarf2

C++-Code : -g -dual_debug -dwarf2 -no_ignore_debug_references

UI에서 모든 옵션을 선택할 수 있는 것은 아니며, 컴파일러의 구성 파일에 수동으로 추가해야 합니다.

TRACE32 에서는 아래와 같이 /GHS 옵션을 사용하여 디버그 정보를 로드할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

타깃이 Break Request에 반응하지 않는 문제의 원인은 다음과 같을 수 있습니다.

1. secure 모드인 타깃에서 디버깅을 시도할 경우

이런 경우에 우측 하단 상태바에 "running (secure)"와 같이 "메시지(secure)" 형태로 표시됩니다.

2. Processor stall 인 경우 (아래 내용 참조)

3. 프로세서가 저전력 모드인 경우

4. SMP 환경에서 일부 코어 접근이 불가능한 경우

System.Down 상태에서 CORE.ASSIGN 1 or CORE.ASSIGN 2 후 재시도

5. 코어에 전원 공급이 되지 않았거나 리셋 상태일 경우

만약 우측 하단 상태바에 running(reset) 메시지가 표시된다면 전원 공급 장치가 충분한 파워를 전달하지 못하는 상태일 수 있습니다.

Processor Stall

타깃이 반응하지 않는 상태를 의미하며, 타겟이 정의되지 않은 주소에 접근하여 bus stall이 발생되는 상황을 예로 들 수 있습니다.

ETM Trace

문제 상황이 재현된다면, 원인 분석을 위해 아래 단계를 수행할 수 있습니다.

1. trace 기능 창을 통해 trace (onchip / offchip) 셋팅

2. Trace.Arm 실행

3. 문제 현상 재현

4. Trace.OFF 실행

5. Trace.List 창의 내용을 끝에서부터 확인

만약 문제 상황을 재현할 수 없다면 아래 단계만 수행할 수 있습니다. (간헐적 문제)

1. Trace.Arm 실행

2. Trace.OFF 실행

3. Trace.List 창의 내용을 끝에서부터 확인

참고로 CPU Crash 또는 Stall 인 경우, trace를 디코딩하기 위한 메모리에 접근이 불가능할 수 있습니다.

이 경우, 어플리케이션을 가상메모리인 VM: (e.g. Data.Load.Elf MyFile VM:0) 에 로드하고 Trace.ACCESS VM를 설정하여 Trace.List 에서 결과를 확인해야 합니다.

Snooper를 통한 PC(Program Counter) 샘플링

Snooper를 사용하여 타깃이 실행중인 주소를 확인할 수 있습니다.

SNOOPer.Mode PC

SNOOPer.Arm

; 몇 초간 대기 후 진행합니다.

SNOOPer.OFF

SNOOPer.List

이후 SNOOPer.List 창을 확인했을 때, PC 값이 변경되고 있다면 Processor Stall 은 아닙니다.

PC 값이 단일 주소로 고정되어 있다면 두 가지로 구분할 수 있습니다.

1. 해당 주소가 idle loop 주소와 동일한 경우(정상 동작)

2. 1번에 해당하지 않은 경우, 해당 주소는 Processor Stall이 발생한 시점의 부근이 될 수 있습니다.

SNOOPer의 기능은 샘플링 방식이기 때문에 정확한 지점이 아닐 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

TRACE32에서 ROM table은 다음과 같은 명령어로 스캔할 수 있습니다.

SYStem.DETECT DAP

하지만, TRACE32는 ROM table에만 의존하지 않습니다.

TRACE32에서 해당 프로세서를 지원하는 경우, 아래 명령으로 정확한 CPU를 선택하는 것만으로 충분합니다.

SYStem.CPU < cpu >

그렇지 않은 경우, SYStem.CONIFG 명령어를 사용하여 스크립트로 CoreSight 설정을 해야 합니다.

이 경우, TRACE32 SW 패키지에 포함된 app_arm_coresight.pdf 문서를 참조하십시오.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

Arm용 TRACE32 데모 폴더 통합 : ~~/demo/arm & ~~/demo/arm64

TRACE32 Arm 실행 파일 통합을 보완하는 단계로, TRACE32의 Arm 데모 디렉토리가 통합되었습니다.

64비트 Arm 칩(Armv8 및 Armv9)에 속하는 데모 파일의 이전 디렉토리인 ~~/demo/arm64는 이제 ~~/demo/arm으로 통합되었습니다.

따라서 ~~/demo/arm64 디렉토리는 제거되었습니다.

~~/demo/arm64 디렉토리의 제거로 인해, 이 디렉토리의 파일을 참조하는 사용자 정의 스크립트가 다시 호환되도록 조정이 필요합니다.

보드별 데모, 예제 및 기타 도움말 스크립트 외에도, TRACE32의 아키텍처별 데모 디렉토리에는 플래시 프로그래밍 및 OS 인식에 필요한 파일도 포함되어 있습니다.

따라서 TRACE32의 플래시 프로그래밍 및 OS 인식 기능을 사용하는 사용자에게 영향을 미칠 것으로 예상됩니다.

자세한 내용은 하단의 섹션 'How to Adjust File References'을 확인하십시오.

기존 Arm demo 디렉토리는 TRACE32 업데이트 또는 설치시에 더 이상 사용할 수 없게 됩니다.

문제를 해결하기 위해, 새로운 demo 디렉토리가 포함된 TRACE32 소프트웨어 업데이트에 대한 정보를 확인하십시오.

사용 가능 시점

Interim/Nightly 릴리스:

Arm 아키텍처용 통합 TRACE32 데모 디렉터리의 배포는 소프트웨어 버전 N.2021.08.000138391와 함께 2021년 8월 13일에 시작되었습니다.

DVD 릴리스:

Arm 아키텍처용 통합 TRACE32 데모 디렉터리가 포함된 첫 번째 DVD 릴리스는 2021년 9월입니다.

주요 변경 사항

• ~~/demo/arm에는 32비트 및 64비트 Arm 기반 칩에 대해 이전에 제공되었던 모든 데모 파일이 포함됩니다.

• 64비트 Arm 칩용 ~~/demo/arm64 디렉터리는 사용 중지(deprecated)되었으며 제거되고 있습니다. 그 이전의 모든 내용은 ~~/demo/arm에 통합되었습니다.

• PRACTICE 함수 OS.PresentDemoDirectory()는 이제 항상 Arm용 TRACE32와 함께 ~~/demo/arm을 반환합니다.

디버거와의 연결을 확인할 수 있는 DSCR(Debug Status and Control Register) 이 있습니다.

실제로 디버거가 코어에 연결되면 DSCR의 14번 비트(DSCR.HDen(Halting debug-mode enable bit))이 설정됩니다. 이 비트는 리셋 시 초기화됩니다.

Cortex-M:

스탑 모드 디버깅의 경우 디버거는 일반적으로 DHCSR 내부에 C_DEBUGEN 플래그(비트 0)를 설정합니다.

스탑 모드 디버깅은 일반적으로 TRACE32 장비를 사용하여 Arm 코어를 디버깅하는 표준 방법입니다.

DHCSR은 주소 0xE000EDF0에 있는 각 Cortex-M 코어의 SCS 블록 내부에 있는 디버그 레지스터입니다.

이 레지스터는 애플리케이션에서도 읽을 수 있어야 합니다.

다만 사용 시 플래그는 SYStem.Mode Up/Go/Attach를 사용하여 연결할 때 즉시 설정되며 SYStem.Down에서도 설정이 유지된다는 점을 유의하시기 바랍니다.

추가로 필요한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

JTAG 신호 중, TDO 응답이 TRACE32의 예상과 다를 때 "debug port fail" 오류가 발생합니다.

아래에 설명된 단계를 따라 순차적으로 JTAG 연결을 확인합니다.

"debug port time-out" 및 "subcore communication time-out" 오류 메시지에도 적용됩니다.

---------------------------------------------------------------------------------------

Start-up 스크립트 실행 / CPU 선택

칩/보드에 대한 Start-up 스크립트 유무 확인

해당 칩/보드에 대한 Start-up 스크립트가 있는지 먼저 확인해봅니다.

TRACE32 SW 설치 후 demo 폴더 내부에서 찾을 수 있으며 스크립트가 있을 경우 해당 파일을 사용합니다.

특정 스크립트 내부에 있는 주석 또는 설명(description), readme.txt(있을 경우)에 있는 전제 조건을 확인합니다.

Start-up 스크립트를 찾지 못한 경우

최신 TRACE32 SW로 업데이트 하거나 MDS테크로 관련 사항을 문의합니다.

Demo 폴더 내부에 있는 예제 중에서 가장 유사한 환경에 대해 제공하는 설정 파일을 이용하는 방법도 있습니다.

CPU 선택 확인

사용하려는 칩에 대한 올바른 CPU가 선택되었는지 확인합니다.

칩에 대한 CPU가 없는 경우 최신 SW 업데이트 또는 MDS테크로 문의하여 해당 프로세서가 TRACE32에서 지원되는지 확인합니다.

다음 확인 사항

SYStem.Up 명령 후 "debug port fail" 오류가 발생한 경우

SYStem.Mode Attach 로 칩과 TRACE32 연결 후 Break를 했을 때 동일한 오류가 발생하는지 확인합니다.

오류가 발생하지 않는다면, SYStem.Up 문제는 리셋 옵션과 관련이 있을 가능성이 있습니다.

무한 루프 반복, 응답 대기, lock-up 코드로 분기 등으로 대상이 복구 불가능한 상태일 수 있습니다. 타깃 전원을 끄고 재인가 후 다시 시도합니다.

SMP 사용 환경

첫 번째 코어(CORE.ASSIGN 1)만 할당한 후 연결이 되는지 확인합니다.

일부 칩의 경우 첫 번째 코어가 부트 코어가 아닐 수도 있습니다. 이런 경우 두 번째 코어(CORE.ASSIGN 2) 혹은 다른 코어를 사용하여 연결을 시도하십시오.

(big.LITTLE 시스템 환경에서 주로 발생할 수 있습니다.)

사용된 코어로만 연결이 가능하다면 다른 코어는 코드적으로 활성화해야 합니다.

낮은 JTAG 주파수로 연결 시도

SYStem.JtagClock 100KHz 등 낮은 주파수로 연결이 가능하다면 점차 클럭을 높여 최적화합니다.

ARM7, ARM9 또는 ARM11이 사용된 경우, SYStem.JtagClock RTCK로 연결을 시도해 볼 수 있습니다.

올바른 Debug Port가 선택되었는지 확인

JTAG/SWD/cJTAG 중 올바른 디버그 포트가 선택되었는지 확인하십시오 (B::SYStem.CONFIG DEBUGPORTTYPE 명령 사용)

Daisy Chain 명령어 실행 결과 확인(JTAG/cJTAG 연결만 지원)

SYStem.down 상태에서 SYStem.DETECT DaisyChain 명령을 실행하고 그 결과를 AREA 창에서 확인합니다.

Daisy Chain detection이 실패하면 타깃의 전원을 다시 켜고 SYStem.Option EnRest OFF 옵션을 사용하여 다시 시도합니다.

Daisy Chain detection 성공

Daisy Chain detection이 성공하면 PRE- / POST- 설정이 AREA 창에 출력됩니다.

Detection 후 SYStem.CONFIG /jtag에서 “ARM JTAG-DP DAP”의 AREA 창의 출력 값과 동일한지 확인합니다.

AREA 창의 DAP PRE- POST 세팅값을 확인합니다.

Daisy Chain detection 실패

Daisy Chain detection 값이 출력되지 않는 경우, 오류가 반환되거나 “TDO stays constantly LOW/HIGH” 메시지가 AREA 창에 출력됩니다.

확인사항

칩/보드의 점퍼 또는 스위치 세팅이 올바르게 설정되어 있는지 확인합니다. 타깃 회로도 또는 메뉴얼에서 확인할 수 있습니다.

타깃 회로도(JTAG 포트 포함)를 확인하고 물리적인 핀(pin) 연결 상태를 확인합니다. TRACE32 케이블의 디버그 헤더 번호와 타깃/보드의 디버그 헤더 번호가 일치하게 연결되었는지 확인합니다.

JTAG 핀 신호 상태 확인

* nTRST가 GND에 연결되지 않아야 합니다.

신호가 LOW에 연결되어 있다면, 디버거가 TRST에 연결되어 이를 HIGH로 인가할 수 있는지 확인해야 합니다.

특히 두 가지 연결 타입(nTRST와 nTRST pulldonw)을 허용하는 커넥터(MIPI20D, MIPI34, MIPI60)의 경우, 어댑터를 사용할 때 둘 중 하나의 잘못된 신호만 연결될 수 있습니다.

* TMS/TDI/TCK에 대한 직렬 저항 연결은 권장하지 않습니다. TDO에 대해서는 22 또는 47 Ohm의 직렬 저항만 허용될 수 있습니다.

* JTAG 이 연결된 GPIO 핀 MUX 구성을 확인하고 올바른 모드가 선택되어 있는지 확인합니다.

* 칩/보드에 인가된 전압 레벨 확인

- Power supply 또는 전원 어뎁터의 용량을 확인합니다.

- 별도의 Power supply를 이용하여 인가 전원 소스를 변경해봅니다.

* 워치독을 사용중이라면 비활성화 해야 합니다. (칩/보드 메뉴얼 확인)

* JTAG 상태 확인 후 어떠한 반응이 없다면 칩/보드 회로도 확인이 필요합니다.

- SYStem.Up / SYStem.Mode Attach 로 상태를 변경할 때 오실로스코프를 이용하여 TDI/TDO/TMS/TCK 신호를 하드웨어 적으로 확인합니다.

- E.g. 스텁으로 인해 발생하는 반사 신호(Signal reflections) 는 TRACE32 가 JTAG 신호(TCK )를 감지할 때 다중 클럭으로 감지할 수 있습니다.

DAP 접근 시도

JTAG Detection 이 완료되었을 경우에만 DAP로 연결 가능합니다.

* CPU 선택

* access_dap.cmx 스크립트를 실행합니다. (B::DODECRYPT "debug_port_fail" access_dap.cmx)

(해당 파일이 필요하면 TRACE32@mdstech.co.kr 로 문의 주십시오.)

* AREA 창에 출력된 결과를 확인합니다.

DAP 연결이 완료되었다면 아래의 “core base 로 연결” 을 진행합니다.

Core debug base 접근 시도

JTAG Detection 과 DAP 연결이 완료되었을 경우에만 이어서 진행합니다.

타깃 전원을 다시 연결하고 아래의 스크립트 명령어(*.cmm)를 실행합니다.

SYStem.Down

SYStem.Option.EnReset OFF

SYStem.Mode Prepare

IF ADDRESS.OFFSET(COREBASE())!=0

(

PRIVATE &lsr

IF (Data.Long(COREBASE()+0xFB4)&0x3)==0x3

Data.Set (COREBASE()+0xFB0) %Long 0xC5ACCE55

Data.dump (COREBASE()+0xF00)++0xFF ;

)

ELSE

PRINT %ERROR "It seems the core base is not configured, see SYStem.CONFIG.COREDEBUG.Base"

성공:

위의 스크립트 명령어가 에러 없이 실행되었다면

Data.dump 윈도우에 ID-Registers 값이 표시됩니다.

* ????_???? 로 표시되는 값이 있다면 access fail 이 발생한 영역입니다.

실패:

확인 사항

* 칩 내부 코어가 리셋 상태에 있거나, core power disabled, no clock, secure 모드에 있을 수 있습니다.

* 칩 내부 코어가 전원 절약 모드(sleep mode)에 있을 수 있습니다.

* 와치독이 활성화되어 타깃 부팅 후 액세스가 불가능할 수 있습니다. 제조사 메뉴얼 확인이 필요합니다.

* SYStem.CONFIG 관련 명령어를 실행하는 스크립트에서 CoreSight 설정을 하는 경우, Core base address 가 잘못되었을 수 있습니다

* CoreSight 및 디버그 관련 base address를 확인할 수 있는 제조사 메뉴얼 확인이 필요합니다.

추가로 필요한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

SYStem.DETECT 명령은 ARM에서 사용한 CPU를 감지하는 용도가 아닌,

JTAG 체인에 있는 DAP(Debug Access Port) 을 감지하기 위해 사용합니다.

* SYStem.DETECT 명령어 사용 이후

CPU 이름을 설정하지 않았지만,

SYStem.DETECT 기능을 통해 Texas Instruments IDCODE:0x1B95A02F 라는 값을 확인할 수 있습니다.

IDCODE가 확인되었다는 것은 JTAG 체인에 있는 DAP의 IDCODE를 확인한 것 입니다.

따라서 JTAG 인터페이스의 연결 상태는 정상이고, DAP 까지 연결이 되었다는 것을 확인할 수 있습니다.

추가로 CPU 이름에 디버깅하고자 하는 프로세서 명이 없으면,

최신 TRACE32 SW로 업데이트하여 시험해 보거나 저희에게 문의 부탁 드립니다.

다른 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

TRACE32는 디버그 커넥터(20pin 커넥터의 15번 pin, 10pin MIPI 커넥터의 10번 pin)에 연결된 nSRST핀을 통해 타깃을 초기화할 수 있습니다.

SYStem.Up 명령은 SYStem.Option.EnReset이 ON으로 설정된 경우에만 리셋 라인을 통해 타깃을 초기화합니다.

System 창(메뉴 CPU > System Settings...)에서 이 옵션이 활성화되어 있는지 확인해 보십시오.

또한 디버거 리셋핀이 칩 리셋(리셋 버튼과 같은)에 제대로 연결되어 있는지 확인해 보십시오.

SYStem.Up 시 Low로 떨어지는 리셋 신호가 프로세서 전체를 초기화하지 하지 않을 수 있습니다.

이러한 경우 SYStem.Up 명령으로 타깃이 Reset Context에서 시작되지 않아 부팅 문제가 발생할 수 있습니다.

Reset 버튼과 nSRST 핀이 보드의 다른 지점에 연결되어 있는지 보드 회로도를 확인해 보십시오.

Reset 버튼과 nSRST를 다르게 처리하는 로직이 있는 경우도 있습니다.

따라서 리셋 버튼과 동일한 동작을 위해 nSRST를 분리하고 와이어를 사용하여 Reset 버튼으로 다시 연결하는 방안도 검토해 보십시오.

Reset 레지스터 확인

사용중인 SoC가 레지스터 값 설정을 통한 고유의 Reset 메커니즘이 있는지 확인해보세요.(적절한 레지스터 값을 설정해야 core reset이 동작하는 경우)

그렇다면 SYStem.Option.RESetRegister 명령과 함께 사용할 수 있습니다.

Reset 스크립트 작성

단일 레지스터 값 설정으로 Reset을 수행하는 경우가 아닌 여러 레지스터에 값을 설정해야 하는 경우, cmm 실행으로 Reset 시퀀스를 수행할 수 있습니다.

예를 들어 SYStem.Mode.Prepare 상태에서 AHB/AXI를 통해 Reset 관련 레지스터에 접근할 수 있으며, Reset 후 디버거가 SYStem.Mode.Attach로 연결하도록 구성할 수 있습니다.

Attach명령은 타깃을 초기화하지 않으므로, 프로세서를 초기 상태로 유지하려면 Reset vector에 무한 루프를 넣어 보십시오.

AHB/AXI를 통해 CPU 메모리에 액세스할 수 있는 경우 Prepare 모드에서 이 작업을 수행할 수 있습니다.

이 경우 아래 스크립트 예제에 표시한 대로 Data.Assemble 명령을 사용합니다.

또한 다음 템플릿 스크립트를 사용하면 Reset Vector에서 CPU를 멈출 수 있습니다(Armv8에만 해당).

추가로 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

Arm의 공식 권장 사항에 따르면 최적 대역폭은 아래와 같습니다.

- 최적 대역폭 = 2bit * Core Frequency

예를 들어,

- Core Frequency = 500MHz

- Trace Clock이 80MHz = 160MHz DDR(Double Data Rate)

와 같이 동작하는 타깃인 경우, Trace Line 수는 다음과 같이 계산됩니다:

- 최적 대역폭 / 1 라인 대역폭 = 2 * 500MHz / 160 = 6.25 Trace Line

- 결론적으로 TPIU.PortSize 8 로 셋팅하면 충분합니다.

- 단, 두 개의 코어가 있으면 두 배의 대역폭이 필요하게 됩니다.

⇾ 12.5 Trace Line이 필요하므로 TPIU.PortSize 16로 셋팅이 요구됩니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다.

해당 에러 메시지는 TRACE32에서 타깃에 연결을 시도할 때 리셋 신호가 감지되었음을 의미합니다.

아래의 체크 리스트 항목들을 수행해 보십시오.

체크리스트:

• 오실로스코프나 전압계를 사용하여 디버그 헤더의 nReset 라인을 확인해보십시오.
• 디버그 케이블을 분리하고 타깃 전원을 끈 상태에서 다시 연결한 뒤 타깃 전원을 켜고 문제가 지속되는지 확인하십시오.
  디버그 케이블은 타깃 전원이 꺼진 상태에서 연결/분리하는 것이 좋습니다.
• SYStem.Option ResetDetection NONE 명령어를 수행한 뒤에 연결을 시도해 보십시오.
• 이 에러는 타깃에 충분한 전력 공급이 되고 있지 않을 경우에도 발생할 수 있습니다.

SYStem.Mode.Up 등의 명령을 통해 TRACE32와 타깃 연결은 가능하나,

프로그램 실행(Go)후 "Debug port fail" 또는 이와 유사한 에러가 발생하는 경우가 있습니다.

가능한 에러 발생 원인:

* 디버그 모듈 또는 JTAG 이 타깃 소프트웨어에 의해 비 활성화 됨

* 코어가 절전 모드로 전환

* 타깃 어플리케이션의 충돌

* 디버거에 의한 잘못된 접근 (e.g., 잘못된 주소에 대한 software breakpoint 설정)

가능한 해결 방법:

* Breakpoint 를 제거하고 run-time 메모리 접근이 가능한 모든 창을 닫아, 문제가 디버거 access와 관련이 있는지 확인합니다.

- SYStem.LOG.List 에서 이 에러와 관련된 주소 확인

- MAP.DenyAccess 를 통해 디버거가 잘못된 access를 방지할 수 있는지 확인

* 에러의 원인을 찾기 위해 연결이 끊어질 때 까지 타깃 어플리케이션을 디버깅 합니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

TRACE32로 'SYStem.Mode.Up' 또는 'SYStem.Mode.Attach' 명령으로 연결을 시도할 때, 'target power fail' 오류가 발생할 수 있습니다.

해당 오류 메시지는 아래와 같은 reference 전압 핀에서 전원이 감지되지 않았음을 의미합니다.

● Pin 1 (VTREF) for the ARM-20 connector:

● Pin 1 (VREF DEBUG) for the MIPI-10/20/34 connectors

● Pin 14 (JTAG-VTREF) for the Mictor-38 connector (if used for debugging)

● Pin 5 (VTREF) for the TI-14 and TI-20 Compact connectors

이외에 다양한 커넥터 핀 매핑에 대한 자세한 내용은 ARM JTAG 인터페이스 사양을 참고하시기 바랍니다.

에러 해결을 위해 아래의 체크 사항들을 확인해 볼 수 있습니다.

● 타깃에 전원이 공급되는지 확인하십시오.

● 특히 어댑터를 사용하는 경우 디버그 케이블이 타깃에 제대로 연결되어 있는지 확인하십시오.

● 디버그 케이블이 올바른 방법으로 연결되어 있는지, 타깃 보드에서 여러 커넥터를 사용할 경우 올바른 디버그 커넥터에 연결되어 있는지 확인하십시오.

● Reference 전압 핀의 전력을 측정해보십시오.

● 타깃 회로도를 확인하십시오.

- Reference 전압 핀이 JTAG 헤더에 올바르게 연결되어 있나요?

- GND 핀이 올바르게 있나요?

● 다른 디버그 케이블을 통해 교차하여 확인하십시오.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

Onchip Trace 데이터를 잃지 않고 타깃에 Attach하는 방법은 다음과 같습니다.

Onchip.DISable

Onchip.Attach

SYStem.Mode. Attach

Break

ETM, ETF 등 Onchip Trace 관련 사항은 부트로더 등 타깃 SW에 의해 미리 설정되어 있어야 하며,

TRACE32 연결에 의해 초기화 되지 않도록 주의해야 합니다.

(ETM: Embedded Trace Macrocell,

ETF: Embedded Trace FIFO)

유지된 Trace 데이터는 Trace.List 명령어를 통해서 확인할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

Memory Management Unit 을 활성화 하여 가상 주소에서 프로세서가 동작하는 경우,

물리주소에 직접적으로 on-chip breakpoint를 설정할 수는 없습니다.

on-chip 브레이크포인트는 코어에서 사용하는 주소에 설정하기에, 내가 원하는 물리주소와 매핑된 모든 가상주소를 찾아 브레이크포인트를 설정해야 합니다.

예를 들면, 내가 물리주소 0x378E_0000에 브레이크포인트를 걸고 싶다면, 그에 해당하는 가상주소를 찾습니다.

(가상주소를 찾는 명령어는 mmu.info 입니다).

스크린샷 1 을 통해 확인해보면 내가 원하는 물리주소에 해당하는 가상주소는 0xffffffc0378E0000이므로 스크린샷 2와 같이 브레이크포인트를 설정하면 됩니다.

< 스크린샷 1 >

< 스크린샷 2 >

브레이크포인트를 설정한 후 주소 매핑이 생성/변경되는 경우 위의 방법이 작동하지 않을 수 있음을 주의해야 합니다.

추가로 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.

TRACE32의 Data.dump 또는 List.auto 창을 통해 DRAM의 메모리 값을 접근할 때, 지속적으로 값이 바뀌는 경우가 있습니다.

예상되는 원인으로는,

- DRAM 컨트롤러를 최적으로 설정하지 않은 경우, 특정 외부 이벤트에서 문제가 발생할 정도로 타이밍이 촉박할 수 있습니다.

- DRAM 납땜이 불량인 경우 핀 접촉 문제일 수 있습니다. 이러한 경우 칩 온도에 따라 현상이 달라질 수 있습니다.

- 또 다른 가능성으로 메모리 버스가 한계를 초과하여 동작하기 때문일 수 있습니다.

디버거 메모리 액세스로 인해 메모리 깜박임이 발생할 수 있는 드문 경우도 있지만, 이러한 경우 일부 메모리 셀 뿐만 아니라 전체 메모리가 깜박입니다:

• Core clock and JTAG clock not synchronous. 에러는 코어 클럭과 JTAG 클럭이 동기화되지 않습니다.
  해결 방법은 JTAG 클럭(예: SYStem.JtagClock 50Khz)을 줄이거나 SYStem.JtagClock RTCK를 사용하는 것입니다.
• 디버거 메모리 액세스는 버스트 액세스를 사용합니다.
  하지만 일부 칩은 이러한 액세스를 허용/지원하지 않습니다. SYStem.Option MULTIPLEFIX ON 명령을 사용하여 버스트 액세스를 비활성화할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다.

감사합니다.

기본적으로, JTAG 디버거는 타깃 러닝중에 CPU를 통해 메모리에 접근할 수 없습니다.

하지만, HW설계가 구현된 프로세서의 경우 AHB 또는 AXI를 이용한 우회적 접근이 가능합니다.

(AHB: Advanced High-Performance Bus

AXI: Advanced eXtensible Interface)

AHB/AXI 버스는 일반적으로 캐시를 우회한다는 점을 고려해야 합니다.

접근하려는 주소의 메모리 값이 캐시에서만 업데이트되고,

실제 외부 메모리에서는 업데이트되지 않는 경우(Write-Back CACHE), 현재 상태는 디버거에 표시되지 않습니다.

실시간 메모리 액세스를 활성화하려면 다음 명령을 사용하십시오.

B::SYStem.MemAccess.DAP

Data.dump에는 E: 액세스 클래스를 사용하고 변수를 표시할 때는 %E 옵션을 사용하십시오.

B::Data.dump E:0x10000000

B::Var.View %E MyVar

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.

감사합니다.