Customer Support
Your Key to Embedded Innovations
[Setup/update] "Plugged debug cable is not suitable for CPU"라는 오류 메시지가 표시되는 이유는 무엇입니까? | |||||||||||||||||
일반적으로 PowerDeubg에 연결된 디버그 케이블이 TRACE32 어플리케이션을 지원하지 않는 경우 "Plugged debug cable is not suitable for CPU" 에러 메시지가 표시됩니다. e.g. "PowerPC-4xx" 디버그 케이블은 "TRACE32 for Arm (t32marm.exe)"에 적합하지 않습니다. 올바른 TRACE32 어플리케이션을 시작하거나 올바른 디버그 케이블을 PowerDebug에 연결하십시오. 특별한 경우로, R.2018.02 이전의 TRACE32 버전을 사용하고, 해당 버전에서 지원하지 않는 새 디버그 케이블을 사용하는 경우에도 "Plugged debug cable is not suitable for CPU" 라는 에러 메시지가 표시됩니다.
http://www.lauterbach.com/7373 에서 적합한 TRACE32 버전을 다운로드 할 수 있습니다. 다른 궁금한 사항은 'TRACE32@mdstech.co.kr' 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Setup/update] 어떤 전원 공급 장치를 E40(PowerDebug) / X50(PowerTrace) 모듈에 사용해야 하나요? | |||||||||||||||||
TRACE32 하드웨어를 구매하시면 다음 중 하나의 전원 공급 장치를 받게 됩니다: • 1.
Wall
Mount Power Supply(7.5V/2.4A): USB 인터페이스가 있는 E40(PowerDebug)
모듈과 MicroTrace(uTrace)에 제공됩니다. 직류전원장치(7.5V2A):
USB 인터페이스가 있는 E40(PowerDebug)
모듈과 MicroTrace(uTrace)에 제공됩니다. 2.
Desktop
Power Supply(8.0V/8.12A):
X50(Debug PRO), PowerTrace III(PowerTrace II Lite) 및 PowerTrace Serial과 함께 제공됩니다. 반드시 제공된 전원 공급 장치만 사용하십시오. 자세한
내용은 TRACE32 설치 가이드에서 확인할 수 있습니다. 전원 공급 장치의 데이터 시트는 Lauterbach 웹사이트(www.lauterbach.com)에서 "Wall Mount Power Supply" 또는
"Desktop Power Supply"를 검색하여 다운로드할 수 있습니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오. 감사합니다 |
|||||||||||||||||
[Setup/update] 소프트웨어 업데이트 후 파일 버전 충돌이 발생하는 이유는 무엇입니까? | |||||||||||||||||
* TRACE32 소프트웨어가 여러 프로세서 아키텍처에 대해 동일한 TRACE32 시스템 디렉토리에 설치되었지만, 모든 아키텍처에 대해 소프트웨어 업데이트가 수행되지 않은 경우. * TRACE32 소프트웨어 설치 없이 업데이트 패키지를 사용하는 경우. 에는 파일 충돌이 발생할 수 있습니다. 원본 config 파일을 복사하여 사용하는 경우, config 파일에서 시스템 디렉토리를 반드시 수정하십시오.
그렇지 않으면 실행 파일의 버전이 나머지 TRACE32 파일들과 일치하지 않을 수 있습니다. 이 문제는 내부 하위 디렉토리 구조가 변경된 2010년 11월 이후의 소프트웨어 버전으로 업데이트할 때 발생할 수 있습니다. 2010년 11월 이후의 소프트웨어 버전에서는 TRACE32 실행 파일이 bin<운영 체제 유형> 예: binwindows64 하위 디렉토리 내에 위치해 있습니다. 따라서, 새로운 디렉토리 구조를 사용하는 것을 권장하며, 설치 디렉토리에서 직접 TRACE32 실행 파일을 호출하는 바로 가기를 수정하는 것을 권장합니다 (예: C:\T32)." 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오. 감사합니다. |
|||||||||||||||||
[Setup/update] 2개의 디버그 모듈로 2개의 JTAG 커넥터를 통해 2개의 칩을 동시에 멈추는 방법 | |||||||||||||||||
sYnch 창을 사용하면 동기화가 소프트웨어에 의해 약 ms 지연으로 수행됩니다. 그렇지 않으면 칩이 BDGREQ 및 DBGACK 신호를 지원하는 경우 하드웨어 기반 동기화를 얻을 수 있습니다. 이 경우 PODBUS를 통해 두 디버그 모듈을 연결하고 TrBus.Out Break ON 및 TrBus.Set Break ON 명령을 각 PowerView 인스턴스에 사용할 수 있습니다. 그러나 동기화 시작(Go)에서는 이러한 유형의 동기화가 지원되지 않습니다. 이러한 명령어에 대한 자세한 내용은 General Commands Reference Guide를 참조하십시오. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오. 감사합니다. |
|||||||||||||||||
[Setup/update] 하나의 케이블에 있는 여러개의 라이선스를 어떻게 관리하나요? | |||||||||||||||||
보유하고 계신 케이블 안에 있는 라이선스에 대한 유지보수를 진행하셔야 합니다. 케이블 안에는 최대 각기 다른 다섯 개의 아키텍쳐에 대한 라이선스를 가지고 있을 수 있습니다. 이 다섯 가지의 독립적인 라이선스는 각 각 유지보수를 진행하셔야 합니다. 추가로 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 바랍니다. 감사합니다. |
|||||||||||||||||
[Setup/update] SW 업데이트 또는 최신 SW를 실행시켰을때 demo mode로 전환되는 이유 | |||||||||||||||||
TRACE32는 시작할 때마다 license 유지보수를 확인합니다 ( 유지보수 기한은 "Help - About TRACE32" 를 클릭하신 후 생성되는 아래와 같은 창에서 License 부분을 통해 확인하실 수 있습니다) 유지보수 기한이 지난 경우, demo mode로 전환되며 사용시간에 제한이 생깁니다. License 유지보수 기한을 연장하고 싶은 경우, QnA 게시판을 통해 연락해주시기를 바랍니다. 다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Setup/update] 이미 사용중인 PowerDebug 에 강제로 연결하는 방법은 무엇입니까? | |||||||||||||||||
"TRACE32 device already in use"라는 메시지가 포함된 Dialog box 가 표시되면, 다음 중 하나가 발생한 것입니다: 1. TRACE32 SW를 실행시켰지만, 다른 TRACE32 GUI 가 여전히 PowerDebug에 독점적으로 연결되어 있습니다. 2. TRACE32 PowerView 가 이전에 제대로 종료되지 않았습니다. (e.g. kill 또는 crash) 3. AMP 멀티 코어 시나리오에 따른 2번째 TRACE32 SW를 실행시켰지만, 두 번째 GUI 가 CORE=2로 구성되지 않았거나 첫 번째 GUI 가 CORE=1로 구성되지 않았습니다. PowerDebug를 재설정하여 TRACE32를 강제로 연결하고자 한다면, TRACE32 구성 파일(일반적으로 "config.t32")의 PBI= 섹션에 CONNECTIONMODE=AUTOCONNECT 문을 사용합니다. USB 연결의 예:
TRACE32 가 새로운 TRACE32 세션을 자동으로 닫으려면 TRACE32 구성 파일의 PBI= 섹션에 CONNECTIONMODE=AUTOABORT 문을 사용합니다.
TRACE32는 추가적으로 AUTORETRY 와 QUERYCONNECT 연결 모드를 지원합니다. 다음은 모든 연결 모드에 대한 설명입니다.
모드에 대한 정보는 TRACE32 설치 가이드를 참조하십시오. t32start.exe 를 사용하여 TRACE32 PowerView UI 를 시작하는 경우, USB 설정 또는 이더넷 설정에서 연결 모드를 변경하여 연결 모드를 설정 할 수 있습니다. 자세한 내용은 T32Start 를 참조하십시오. 다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Setup/update] Windows에서 자동 설치를 구현하는 방법 | |||||||||||||||||
1. TRACE32 소프트웨어 설치를 간편하게 배포하기 위해 네트워크 마운트/드라이브를 사용하고, TRACE32 DVD의 내용을 서버의 특정 디렉토리에 배치합니다. xcopy D:*.* N:TRACE32DVD_201011 /E /V /L // drive와 directory 이름에 대한 예시입니다 2. 명령어 셸 창에서 다음 지침을 사용하여 TRACE32 설치를 한 번 기록합니다. N: TRACE32 설치 과정을 완료하면, 기록이 setup.iss 파일에 저장됩니다. 3. 다른 PC에서 무인 TRACE32 설치를 다음 명령어로 시작합니다. setup.exe /s /f1"N:TRACE32DVD_201011binsetup64setup.iss" // /s는 silence installation mode 입니다 만약 InstallShield가 네트워크 드라이브에 기록 파일과 함께 제대로 작동하지 않는 경우, 기본 경로인 C:rulsetup.iss를 대신 사용하십시오. 다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Setup/update] FATAL ERROR from PODBUS-driver: TRACE32 USB device not connected | |||||||||||||||||
해당 에러 메시지는 PowerView 소프트웨어와 PowerDebug 장비가 USB를 통해 연결이 되지 않았을 때 나타납니다.
장치 이름은 기본적으로 디버그 모듈의 일련 번호입니다. 다른 궁금한 사항은 'TRACE32@mdstech.co.kr'로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Setup/update] 디버그 케이블을 사용 시, 결함(defect)을 발생시키지 않고 사용하는 권장 방법은 무엇입니까? | |||||||||||||||||
디버거를 타깃에 연결하거나 타깃에서 분리할 때는 항상 타겟의 전원이 꺼져 있을 때만 수행하는 것이 좋습니다. 따라서 권장되는 연결 및 제거 순서는 다음과 같습니다 1. 디버거와 타깃의 전원이 모두 꺼져 있는 상태 2. 디버거 전원 켜기 3. TRACE32 Powerview 시작 4. 디버거를 타깃에 연결 5. 타깃 전원 켜기 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다 |
|||||||||||||||||
[Setup/update] TRACE32 소프트웨어를 어떻게 설치하거나 제거할 수 있을까요? | |||||||||||||||||
설치는 MDS테크에서 제공하는 TRACE32 설치 가이드를 참조하세요. TRACE32를 제거하려면 시스템 디렉토리를 수동으로 삭제합니다(예: Windows의 경우 C:T32, Linux의 경우 /opt/t32). Windows의 경우 Windows 설정 또는 제어판에서 프로그램 제거를 추가로 실행해야 합니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V] [HW-Designer] 현재 RISC-V 디버그 모듈을 SoC에 통합하는 방법은 어떤 것들이 지원되나요? | |||||||||||||||||
자세한 내용은 Lauterbach RISC-V 디버거 매뉴얼의 "Quick Start for Debug Module Configuration" 챕터를 참고 부탁드리겠습니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V] SYStem.Up / SYStem.Attach 후 fatal error 발생 | |||||||||||||||||
자세한 내용은 Lauterbach RISC-V Debugger 매뉴얼의 "Troubleshooting" -> "Communication between Debugger and Processor cannot be established" 장을 참고하십시오. 다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V] [HW-Designer] “optional” 디버그 IP에서 TRACE32 디버깅을 위한 필요한 기능 | |||||||||||||||||
RISC-V 디버그 feature의 일부 사양은 일반적인 사양을 따라가지만
특정 기능이나 구현 유무를 선택할 수 있도록 “optional” 로 분류되어 있습니다. 디버그 모듈(DM)의 여러가지 디버그 레지스터 사용을 위한 레지스터
비트 필드(bitfield) 또는 전체 기능 사용 유무는 “optional”
로 선언되어 있습니다. 다음은 디버그 레지스터 및 “optional”
레지스터 비트 필드를 설명하고 해당 디버그 레지스터가 디버깅에 필요한지 여부를 설명합니다. 주의: 이 목록은 향후 언제든지 변경될 수
있습니다. 레지스터나 비트 필드가 이 목록에 없으면 글 작성자가 추가하는 것을 잊었거나 디버그 사양에서
선택 사항(optional)이 아닌, 이미 포함된 것으로
간주하여 항목을 나열하지 않을 수 있습니다. l
Abstract Data 0 - 11 (data0 - data11): n 필요한 dataX 레지스터의 개수는 RISC-V 디버그 모듈에 연결된 모든 코어의 base ISA(RV32,
RV64 등)와 같은 요인에 따라 달라집니다. 또한 RISC-V 디버그 모듈에서 구현된 기능, 특히 구현된 Abstract command에 따라 달라집니다. 자세한 내용은 RISC-V 디버그 사양을 참조해야 합니다. n Scratch memory: u
특정 상황에서 디버거는 'data' 디버그 레지스터를 "scratch menory"로
사용해야 합니다. 자세한 내용은 아래의 'hartinfo'를
참조하십시오. u
Scratch
memory가 필요한 경우, 최소
데이터 레지스터 양은 위에서 언급한 개수보다 더 필요할 수 있습니다(scratch memory가 사용되는
실제 시나리오에 따라 다름). 이 경우 현재 권장 사항은 최소 4개의
데이터 레지스터(RV32 또는 RV64에 관계없이)이지만 시나리오에 따라 실제 필요한 크기가 더 클 수 있습니다. l
Debug Module Control (dmcontrol): n hasel bitfield: 멀티코어 디버깅에 권장되며, 하드웨어를 통해 여러 RISC-V 코어의 동기화된 start 및 stop 이 가능합니다. l
Hart Info (hartinfo): n 'data' debug register (e.g. scratch
memory) n 특정 상황에서 TRACE32 디버거는 " scratch memory " (i.e. 디버그 작업에 사용할 수 있는 메모리)를 사용해야 합니다. 예를 들어 RV32 코어(XLEN=32비트)의 double-precision floating point registers (FLEN=64비트)에 접근할 때가 그렇습니다. 'data' debug
register가 hart의 메모리 맵에 shadowed
되어 있으면 scratch memory 로 사용할 수 있습니다. n 'data' debug register를 scratch memory로 사용해야 하는 경우, 'hartinfo' debug register가 존재하고 그에 따라
'dataaccess', 'datasize' 및 'dataaddr' 필드가 설정되어야 합니다. n 'data' debug register를 scratch memory로 사용하지 않고, program buffer를 scratch memory로 사용할
수 있습니다. 자세한 사항은 아래 프로그램 버퍼에 대한 내용을 참조하십시오. n 위에서 언급한 사용 케이스 외에도 RISC-V 디버거에
다른 사용 케이스들이 추가될 수 있으며, 해당 기능을 위해 hartinfo
레지스터가 구현되어야 할 수 있습니다. l
Abstract
Command autoexec
(abstractauto): Abstract
Command autoexec 레지스터는 optional로
선언되어 선택 사항이지만 디버거 입장에서는 구현하는 것이 좋습니다. 'autoexecdata[0]' 비트를
사용하면 여러 개의 연속적인 abstract command를 실행할 때 성능이 향상되는 효과를 볼 수
있습니다. 예를 들어 프로그램 버퍼 또는 abstract
command 를 통한 메모리 읽기 / 쓰기 등 광범위하게 사용할 수 있습니다. l Program buffer 0 - 15(progbuf0 - progbuf15): 디버그 상세 사양에서 program buffer 사이즈는 0 ~ 16까지 사용할 수 있습니다. 크기가 0이면 program buffer가 전혀 없음을 의미합니다. 일반적으로 유효한 RISC-V 디버그 IP를 구현하는 두 가지 주요 방법이 있습니다 (두 가지 모두 RISC-V 디버그 사양에 자세히 설명되어 있음). n Abstract Command Based
Approach: 디버거의 모든 주요 작업 및 타깃과의 상호
작용은 abstract command를 통해 수행됩니다. 이
경우 program buffer가 필요하지 않으므로 program
buffer 크기는 0이 될 수 있습니다. n 현재까지 승인된 디버그 사양 v0.13.x/0.14.x/1.0.x에서는 특정 abstract command
유형이 지원되는지 여부와 abstract command 지원 여부를 탐지/검색하는 적절한 메커니즘이 제공되지 않고 있습니다. 이러한 영향성은 TRACE32 가 abstract memory를 지원할 때 제한된
버전에 대해서만 사용 가능 하다는 의미이며 TRACE32 디버거가 시스템 'access memory' 관련 abstract command를 찾아내는데
영향을 미칠 수 있습니다. 자세한 내용은 공식 RISC-V 디버그
workgroup의 discussion 내용을 참조하십시오. Abstract command 관련 시스템 명령어를 찾아내는 것과 관련된 제약 사항으로 인해, system discovery 문제가 해결될 때까지 "Execution
Based" 접근 방식을 우회적으로 사용하는 것이 좋습니다. 이러한 이유로 TRACE32 디버거만 유일하게 'access memory' 관련 abstract command를
지원하는 이유입니다. 'aamsize', 'aampostincrement' 및 'write' bitfield의 가능한 모든 옵션과 조합이 타깃 하드웨어에서 지원되는 경우 TRACE32 디버거를 도입할 수 있습니다. Abstract command를
memory access 시 기본 명령어(default)로 지정하려면 SYStem.MemAccessStop
AAM 를 사용하면 됩니다. n Flexibility: Abstract
command기반의
디버깅 적용 검토 u 디버거에 Program buffer가 없으면 실행할 수 있는 작업과 관련하여 유연성이 크게 떨어집니다(비교를 위해 아래 execution based 접근 방식 참조). n Cache coherency (abstract command 기반): 일반적으로 ‘access memory’ 관련 abstract command의 RISC-V 디버그 사양은 CPU의 명령어 또는 데이터 캐시에 대해
작동하는 표준화된 메커니즘을 제공하지 않습니다.
Program buffer 가 없는 경우 디버거는 자체적으로 캐시 일관성을
보장할 수 없으므로 하드웨어는 자체적으로 캐시 일관성을 자동으로 보장해야 합니다(예: 디버거가 각각의 access memory 관련 abstract commad를 시작할 때 캐시 플러시 flush를 실행 - 필요한 경우). n Execution Based Approach: 디버거의 주요 작업 및 상호 작용은 부분적으로 program buffer실행에
영향을 받습니다. n
이 경우
TRACE32디버거는 현재 다양한 시나리오에서 program
buffer를 사용하며, 향후 추가적인 시나리오가 추가되거나 버그 수정 또는 개선으로 인해
기존 시나리오 및 동작이 변경될 수 있습니다. 따라서 현재 사용중인
program buffer의 크기가 향후 모든 기능에 충분할 수 있는지 특정할 수 없기 때문에 최적화된 (작은) program buffer크기를 "권장(추천)” 하기는
불가능합니다. 또한 필요한 program buffer의 크기는 '내재된 ebreak' 기능이 구현되었는지 여부(dmstatus.impebreak)에 따라 다릅니다. 디버그 드라이버(2023-05-31)의 현재 구현을 기준으로 프로그램 버퍼 크기
3(implicit ebreak 없음) 또는 2(implicit
ebreak 있음)는 현재
사용 가능한 대부분의 기능에 충분한 최적화값입니다. n 요약. 시스템 설계자가 드라이버의 향후 업데이트를 위해 안전성 유지하려는 경우와, 칩 영역이 그다지 중요하지 않은 경우 program buffer의 크기를 16으로 지정할 것을 권장합니다. 앞서 나열된 상황에 대해 현재 사용중인 최소화된 크기로도 충분합니다. 또한 드라이버가 위에서 언급한 최소 크기보다 큰 크기를 요구하는 기능을 추가할 경우, program buffer 크기가 작은 하드웨어를 위해 기능이 축소된 "fallback" 옵션을 항상 제공할 것입니다. 그러나 program buffer 크기가 위에서 언급한 요구 사항보다 작은 하드웨어는 "execution based approach" 방식을 사용할 경우, TRACE32 디버그 드라이버와 호환되지 않을 수 있습니다. n Scratch
memory: u 특정 상황에서 TRACE32 디버거는 "scratch memory" (디버그 작업에 사용할 수 있는 메모리)를 사용해야 합니다. 예를 들어,
RV32 코어(XLEN=32bit)의 double-precision floating point registers (FLEN=64bit)에 접근할 때가 그렇습니다. program buffer data debug registers (progbuf0,
progbuf1, ...)가 hart 의 메모리 맵에 shadowed 되어있고 hart 에 의해 write할 수 있는 경우,
program buffer를 scratch memory로 사용할 수 있습니다. u 이 경우, 디버거는 hart의 관점에서 program buffer의 주소를 결정하기 위해
program buffer에서 'auipc' 명령어를 실행합니다. u Program buffer를 scratch memory로
사용해야 하는 경우, 최소한으로 요구되는 program buffer 크기는
앞서 언급한 크기보다 클 수 있습니다. 현재 이 경우의 권장 사항은 최소 4개의 program buffer register이지만, 실제로 필요한 크기는 사용 시나리오에 따라 더 클 수 있습니다. u Program buffer를 scratch memory로
사용하는 대안으로 'data' debug register를 scratch
memory로 사용할 수 있습니다. 'Abstract Data' register와 'hartinfo' register에 대한 추가 설명은 위의 내용을 참조하십시오. n Flexibility: Execution
based command기반의 디버깅 적용 검토
u Program buffer에 접근할 수 있으면 디버거는 abstract command의
특정 작업에 제한되지 않고 실행할 수 있는 작업의 유연성(flexibility)이 크게 증가합니다.
n
Cache coherency (execution based command 기반): 일반적으로 RISC-V 디버그
사양은 CPU의 명령어 또는 데이터 캐시에 대해 작동하는 표준화된 메커니즘을 제공하지 않습니다. 그러나 program buffer가 존재하면 디버거가 "FENCE" 및/또는 "FENCE.I" 명령어를 실행할 수 있습니다. 이를
통해 디버거는 특정 디버거 작업 전후에 이러한 명령어를 실행하여 캐시 일관성을 보장할 수 있습니다. n
권장 사항: 디버거 관점에서, Execution based
command 접근 방식을 구현할 것을 권장합니다. 이 방식은 디버거에게 훨씬 더 많은 유연성(flexibility)을 제공합니다. l System Bus Address (sbaddress0/1/2) + System Bus Data
(sbdata0/1/2/3): 이러한 선택적 레지스터는 시스템 버스를 통해 메모리에 접근하려는 경우에만 필요합니다(RISC-V 디버거의 'SB:' 접근 클래스 참조). 디버거는 시스템 버스 접근 없이도 작동할 수 있습니다. 시스템
버스 접근이 필요한지 여부는 사용자의 개별 요구 사항과 대상 아키텍처에 따라 다릅니다. l Halt
summary registers: n haltsum0/1/2/3: 현재 디버거에서 사용되지 않습니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다 |
|||||||||||||||||
[Core architecture] [RISC-V][HW-Designer] 'mcontrol' 온칩 트리거가 지원되는 조합 | |||||||||||||||||
RISC-V 디버그 표준은 트리거 세트를 보유하는 모듈을 정의합니다. 각 트리거는 여러 유형(예: 'mcontrol2' 또는 'mcontrol6') 중 하나에 대해 개별적으로 구성할 수 있으며, 트리거 유형에 따라 다양한 옵션으로 구성할 수 있습니다. 디버그 사양은 타 기종 트리거 기능을 갖춘 시스템 설계를 허용하므로 모든 트리거가 동일한 트리거 유형과 동일한 트리거 유형 구성 옵션을 지원할 필요는 없습니다. 다음은 버전 R.2022.02 이상인 RISC-V 디버거와 호환되기 위한 트리거 유형 'mcontrol2' 및 'mcontrol6' 에 대한 요구 사항입니다.
다음은 버전 R.2019.09 이하의 RISC-V 디버거와 호환되기 위한 트리거 유형 'mcontrol2' 및 'mcontrol6' 에 대한 요구 사항입니다.
다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V] [HW-Designer] TRACE32 에서 Instruction/data 캐시 처리 | |||||||||||||||||
RISC-V 에서 Instruction / Data 캐시 안타깝게도 RISC-V 디버그 사양은 Instruction 또는 Data 캐시를 처리하는 명시적이고 표준화된 방법을 정의하지 않습니다. 하지만, 일부 시나리오에서는 Debugger 또는 Debug IP가 캐시 플러시와 같은 특정 캐시 작업을 실행할 수 있어야 합니다. Example #1: Instruction 캐시가 있는 단일 RISC-V 코어를 가진 SoC 를 예로 들겠습니다. 코어의 instruction 메모리에는 RISC-V 명령어 "A" 가 포함되어 있습니다. RISC-V 코어는 "A"를 실행하기 전에 일부 명령어를 중단합니다. 코어는 아직 "A"를 실행하지 않았지만, 이미 "A"를 instructoin 캐시와 파이프라인에 로드 했습니다. 이제 디버거는 software breakpoint 를 "A"에 설정하는데, 이는 임시로 "A" 를 "EBREAK" 명령어로 대체한다는 것을 의미합니다. 그 이후, debugger는 코어를 다시 시작 시킵니다. 코어가 원래 캐시된 "A" 명령어 대신 새로운 "EBREAK" 명령을 실행하도록 하기 위해서는, debugger 가 CPU를 다시 시작하기 전, instruction 캐시와 파이프라인을 플러시 해야 합니다. Example #2: Data 캐시가 있는 다중의 RISC-V 코어를 가진 SoC 를 예로 들겠습니다. 각각의 코어가 정지됩니다. 각각의 코어는 이미 주소 "B"의 메모리 데이터 "X" 를 해당 data 캐시에 캐시했습니다. 이제 debugger 는 직접 시스템 버스 접근을 사용해 주소 "B"의 데이터 메모리에 새로운 데이터 "Y"를 씁니다. Debugger 가 코어를 다시 시작시킬 때, 각 코어의 data 캐시에 더 이상 오래된 데이터 "X" 가 포함되어 있지 않은지 확인해야 합니다. 따라서 debugger 는 코어를 다시 시작하기 전, 또는 코어 중 하나의 관점에서 메모리 content 를 읽기 전에 각 코어의 data 캐시를 플러시 해야 합니다.
FENCE/FENCE.I 를 통한 캐시 처리 방법 위의 예제 시나리오와 다른 시나리오를 해결하기 위해서, debugger 는 "FENCE" 또는 "FENCE.I" 명령어의 프로그램 버퍼 실행을 사용합니다. RISC-V ISA 사양에 따르면, 이러한 명령어는 각각의 칩에 적용 가능하고, 해당 시나리오에서 필요한 경우 캐시 및 파이프라인 플러시가 발생하도록 보장해야 합니다. 다음 항목들은 디버거가 보통 FENCE 및 FENCE.I 명령어를 사용하는 예제 시나리오를 보여줍니다. 물론, 해당 동작이 항상 적용되는 것은 아니며, 향후 debugger 버전에 따라 변경될 수도 있습니다.
위의 디버거 동작은 하드웨어의 디버그 IP가 충분한 크기의 프로그램 버퍼를 가지고 있고, 해당 코어가 FENCE 및 FENCE.I 명령어를 지원하는 경우에만 가능합니다. 이러한 경우, 디버거는 해당 코어에 캐시가 있는지 여부와 관계없이 설명된 단계를 실행합니다. 그러나 하드웨어의 디버그 IP에 프로그램 버퍼가 없거나, 프로그램 버퍼의 크기가 충분하지 않거나, FENCE/FENCE.I를 지원하지 않는 경우, 디버거는 디버그 IP가 모든 관련 시나리오를 자동으로 처리할 것이라고 가정해야 합니다. "Base Cache Management Operation" (CMO) ISA 확장을 통한 캐시 핸들링 선택적인 '기본 캐시 관리 작업'(CMO) ISA 확장(Zicbom, Zicboz, Zicbop)은 RISC-V 코어의 캐시에 대해 표준화된 작동 메커니즘을 정의합니다. 이 ISA확장에 대한 정보는 https://github.com/riscv/riscv-CMOs 에서 찾을 수 있습니다. 현재 Lauterbach 의 RISC-V 디버거의 disassembler는 이 확장을 지원합니다. 그러나 디버거는 아직 이 확장 명령어를 사용하여 캐시 플러시를 실행하지 않습니다. (위에서 언급된 시나리오를 다루기 위해) 하지만 앞으로는 이를 고려할 예정입니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V] non-standard/custom RISC-V ISA 확장을 지원합니까? | |||||||||||||||||
RISC-V ISA 규격은 "ISA 확장"을 정의하며, 이는 기본 ISA를 특정 추가 명령으로 보완할 수 있습니다. ISA 규격은 표준 ISA 확장 이외에도 핵심 설계자가 자신의 non-standard/custom RISC-V ISA 확장을 정의할 수 있는 방법을 표준화합니다. 이는 주로 disassemble 및 instruction set 시뮬레이터 또는 trace 지원에 영향을 미칩니다. 그런 다음 SYSTem.CPU 명령을 통해 해당 CPU 항목을 선택하는 등의 사용자 지정 확장에 대한 지원을 활성화할 수 있습니다. 소프트웨어에 대한 direct integration을 제공할 수 있는 경우와 어떤 상황에서 제공할 수 있는지에 대해 논의가 필요합니다. 이 API는 API for Auxiliary Processing Unit, 보조 처리 장치를 위한 API(APU API)라고 불립니다. 자세한 내용은 APU API(https://repo.lauterbach.com/pdf/api_apu.pdf)에서 확인할 수 있습니다
TRACE32는 시뮬레이터용 API를 제공하지만 이 API는 주변 동작(API for TRACE32 명령 집합 시뮬레이터)만 시뮬레이션할 수 있고 전체 코어의 동작은 허용하지 않습니다. - 프로그램 흐름 제어 동작이 더 복잡한 사용자 지정 명령이 있는 경우(예를 들어 새 사용자 지정 분기 명령을 추가하는 경우) trace 지원이 APU API의 일반 인터페이스에 의해 적용될 수 있는지 여부와 방법에 대해 논의가 필요합니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.
감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V]TRACE32 에서 지원하고 있는 RISC-V ISA 는 어떻게 되나요? | |||||||||||||||||
RISC-V는 32비트(RV32), 64비트(RV64), 128비트(RV128) 기본 ISA를 사용합니다. TRACE32는 일반적으로 RV32와 RV64 기본 ISA를 사용하는 코어 아키텍처를 지원합니다. 하지만 RV128 ISA 코어는 현재 지원되지 않습니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V] 어떤 표준 RISC-V ISA extension 지원되나요? | |||||||||||||||||
RISC-V ISA 스펙은 특정 표준 ISA (instruction set architecture) extension을 정의하고, 기본 ISA 세트를 추가 명령어로 보완할 수 있습니다(예를들면 atomic 명령어를 위한 "A" extension). TRACE32는 RISC-V ISA 스펙에서 정의된 모든 표준 ISA extension을 지원합니다. 'F"와 같은 특수 extension(floating point extensions)의 경우, TRACE32는 추가 floating point registers의 내용을 표시하고 값을 수정할 수 있습니다. TRACE32는 RISC-V의 표준 ISA 확장의 모든 조합을 지원합니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V][HW-Designer] TRACE32에는 어떠한 코어 레지스터(CSRs)가 필요합니까? | |||||||||||||||||
디버거는 디버그 모듈의 디버그 레지스터에 액세스할 필요가 없습니다. 제대로 작동하려면 여러 핵심 레지스터(제어 및 상태 레지스터, CSR)도 액세스 가능/구현되어야 합니다. 다음 요약은 디버깅 컨텍스트에 있는 CSR을 나열하고 필요한지 여부를 언급합니다. Core Debug Registers
Debug/Trace Registers
Machine-Level Control and Status Registers (Machine-Level CSRs)
이 레지스터는 코어의 기본 ISA를 결정하는 데 도움이 됩니다. 또한, 디버거가 부동소수점("F"/"D")과 같은 지원되는 ISA 확장을 결정하는 데도 도움이 되며, 이를 통해 디버거가 추가적인 부동소수점 레지스터에 접근하고 표시할 수 있게 됩니다. 이 레지스터가 구현되지 않은 경우, 디버거는 위의 정보를 결정하기 위해 신뢰성이 낮은 시행착오 방법을 사용해야 합니다. 일부 경우에는 해당 정보를 자동으로 감지하는 것이 불가능할 수도 있습니다. 따라서 디버거가 신뢰할 수 있고 최소한의 침입 방식으로 작동할 수 있도록 이 레지스터를 구현하는 것을 강력히 권장합니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [RISC-V] [HW-Designer] TRACE32 RISC-V 디버거가 지원 가능한 버전 | |||||||||||||||||
TRACE32는 RISC-V 공식 디버거 사양을 기반으로 한 디자인을 지원하고 있습니다. 공식적으로 승인된 첫 번째 디버그 사양은 v0.13 버전이었습니다. 따라서 TRACE32는 v0.14, v1.0 등 v0.13.x 이후 모든 버전을 지원합니다. 그러나 첫 번째 승인된 v0.13 이전의 비공식 초안 버전(예: v0.11)은 지원하지 않습니다.
다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다.
감사합니다. |
|||||||||||||||||
[Core architecture] [PowerArchitecture] SYStem.Option.FREEZE 옵션이 타이머/카운터에 미치는 영향 | |||||||||||||||||
SYStem.Option.FREEZE 설정은 디버그 관련 레지스터를 사용하여 타깃이 debug halt 상태에 진입할 때 타이머/카운터 동작에 영향을 줍니다. QorIQ CPU는 일반적으로 RCPM에 CTBHLTCR 또는 TTBHLTCR 레지스터를 제공합니다. * RCPM: Run Control and Power Management * CTBHLTCR: Core Time Base Halt Control Register * TTBHLTCR: Thread Time Base Halt Control Register 이 레지스터의 특정 코어에 대한 비트가
다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [PowerArchitecture] "emulation pod configuration error" | |||||||||||||||||
"emulation pod configuration error" 의 경우 몇 가지 원인이 있습니다. 1. SYStem 창에서 선택한 CPU와 타깃 프로세서가 다른 경우 - 선택한 CPU와 타깃 CPU가 동일한지 확인해야 합니다. - SYStem.DETECT CPU 를 통해 타깃 CPU를 확인할 수 있습니다. (SYStem.DETECT CPU 명령어는 PowerPC 아키텍쳐에서만 사용 가능) 2. 디버깅 하고자 하는 CPU 가 현재 사용하고 있는 TRACE32 S/W(PowerView) 에서 지원하지 않는 경우 - 최신 TRACE32 S/W를 통해 지원 여부를 확인할 수 있습니다. 오류 발생 시 자세한 메시지는 B::AREA 창에 출력 됩니다. (View - Message Area 풀다운 메뉴를 통해 실행) 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [MPC85xx] 리눅스를 사용하는 e500코어 기반 프로세서의 breakpoint 오동작 | |||||||||||||||||
JTAG를 통한 디버깅을 사용하려면 e500 코어용 리눅스 커널(PQ3/MPC85XX/QorIQ P10XX/P2020) 패치가 필요합니다. 그리고 arch/powerpc/include/asm/reg_book.h에 정의된 MSR_KERNL 매크로는 MSR_DE 비트를 포함하도록 수정이 필요합니다. 추가로 필요한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [MPC5xxx] 내부 SRAM 또는 로컬 메모리에 대한 "bus error"(물음표 표시) | |||||||||||||||||
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 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [MPC5xxx] 에너지 측정 시 넥서스 프로브의 영향 | |||||||||||||||||
Nexus 프로브를 사용한 에너지 측정시에 active termination을 off 하는 것이 좋습니다. Analyzer.disable(Nexus trace probe hardware 비활성화)와 NEXUS.OFF(Nexus Cell off)사이에는 큰 차이가 없습니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다 |
|||||||||||||||||
[Core architecture] [MPC5xxx] 타깃 전원 핀의 전원이 올바른데도 불구하고 전원 오류 메시지가 나타나는 이유는 무엇인가요? | |||||||||||||||||
디버거에서 SYStem.Up을 실행할 수 없고 대신 전원 오류가 감지되면, 두 개의 디버거(e.g. JTAG 디버그 케이블과, NEXUS 프로브)가 같이 연결되어 있는지 확인해야 합니다. 이는 허용되지 않는 구성으로, JTAG 동글이나 NEXUS 프로브를 디버깅에 사용할 수 없게 만듭니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [MPC5xxx] Censored device 로 인한 디버거 접근 불가 | |||||||||||||||||
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 로 문의 주시기 바랍니다. 감사합니다 |
|||||||||||||||||
[Core architecture] [MPC5xxx] List 창에서 유효하지 않은 어셈블리 명령어라고 하거나 Trace FLOWERROR 가 발생합니다. | |||||||||||||||||
"Qorivva MPC5xxx/SPC5xx Debugger and NEXUS Trace" 문서(C:T32pdfdebugger_mpc5500.pdf 파일) 내의 'Tracing VLE or mixed FLE/VLE applications' 섹션을 참고하시기 바랍니다. 다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다. 감사합니다. |
|||||||||||||||||
[Core architecture] [MPC5xxx] 변수가 잘못된 값을 표시하거나 런타임중 수정할 수 없는 경우 | |||||||||||||||||
Qorivva MPC5xxx/SPC5xx Debugger and NEXUS Trace 메뉴얼(debugger_mpc5500.pdf)의 "Memory Coherency During run-time Memory Access" 챕터를 확인해보세요 다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주시기 바랍니다. 감사합니다. |