MDSTECH

자세한 내용은 Lauterbach RISC-V 디버거 매뉴얼의 "Quick Start for Debug Module Configuration" 챕터를 참고 부탁드리겠습니다.

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

감사합니다.

자세한 내용은 Lauterbach RISC-V Debugger 매뉴얼의

"Troubleshooting" -> "Communication between Debugger and Processor cannot be established" 장을 참고하십시오.

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

감사합니다.

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 디버그 사양을 참조해야 합니다.
대부분의 표준 RISC-V 칩에서는 디버그 모듈이 RV32 코어만 처리하는 경우 최소 data0이 필요하지만 디버그 모듈이 하나 이상의 RV64 코어를 처리하는 경우 최소 data0 및 data1이 필요합니다.

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 이 가능합니다.
디버그 모듈에 연결된 RISC-V 코어가 여러 개 있고 'hasel'이 지원되지 않는 경우, 디버거는 모든 코어를 동시에 start/stop 할 수 없으며 연속적으로만 start/stop 할 수 있습니다.
디버그 모듈에 연결된 RISC-V 코어가 하나만 있는 경우 hasel bitfield는 불필요 합니다.

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 를 통한 메모리 읽기 / 쓰기 등 광범위하게 사용할 수 있습니다.
TRACE32디버그 드라이버는 선택적 기능을 지원하지 않는 디자인에서도 사용할 수 있습니다.

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 있음)는 현재 사용 가능한 대부분의 기능에 충분한 최적화값입니다.
한 가지 예외 사항으로 program buffer를 scratch memory로 사용하는 것입니다(아래 내용참조).
향후 기능적으로 향상된 드라이버에 대해 더 큰 program buffer가 필요할 수 있습니다.

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 로 문의 주시기 바랍니다.

감사합니다

RISC-V 디버그 표준은 트리거 세트를 보유하는 모듈을 정의합니다.

각 트리거는 여러 유형(예: 'mcontrol2' 또는 'mcontrol6') 중 하나에 대해 개별적으로 구성할 수 있으며, 트리거 유형에 따라 다양한 옵션으로 구성할 수 있습니다.

디버그 사양은 타 기종 트리거 기능을 갖춘 시스템 설계를 허용하므로 모든 트리거가 동일한 트리거 유형과 동일한 트리거 유형 구성 옵션을 지원할 필요는 없습니다.

다음은 버전 R.2022.02 이상인 RISC-V 디버거와 호환되기 위한 트리거 유형 'mcontrol2' 및 'mcontrol6' 에 대한 요구 사항입니다.

• RISC-V 디버거는 트리거 유형 mcontrol2와 mcontrol6을 모두 지원하지만 디버그 세션에서는 이러한 유형 중 하나만 사용할 수 있습니다.
• 더 많은 트리거가 사용하고 있는 트리거 유형을 자동으로 선택하며, 예를 들어 코어가 4개의 mcontrol2 트리거와 5개의 mcontrol6 트리거를 지원하는 경우 디버거는 mcontrol6 옵션을 사용합니다.

다음은 버전 R.2019.09 이하의 RISC-V 디버거와 호환되기 위한 트리거 유형 'mcontrol2' 및 'mcontrol6' 에 대한 요구 사항입니다.

• 트리거 유형 mcontrol2만 지원됩니다. (mcontrol6 미지원)
• 디버거는 'mcontrol' 유형을 지원하는 가장 큰 연속된 트리거 블록만 사용합니다.
  (예 : 트리거 인덱스 1, 4, 5, 6, 9만 'mcontrol' 유형을 지원하는 경우 인덱스 4, 5, 6의 연속된 블록만 사용합니다.)
• 각 mcontrol 트리거에는 다양한 선택적 구성 옵션(execute, store, load, chain, ...)이 있습니다.
  디버거는 현재 인접한 mcontrol 블록의 모든 트리거에서 지원되는 구성 옵션만 사용합니다(위 참조).
  예외로 해당 블록의 마지막 트리거를 제외한 모든 트리거에서 지원되는 경우 사용되는 'chain' 옵션이 있습니다.

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 버전에 따라 변경될 수도 있습니다.

• 코어 재 실행 : 디버거가 코어를 재 실행하기 전에, 프로그램 버퍼를 통해 "FENCE" 및 "FENCE.I" 명령어를 모두 실행합니다.
• 코어를 통한 메모리 읽기 : 디버거가 코어의 관점에서 메모리를 읽기 전에(프로그램 버퍼 또는 '메모리 접근' 명령어를 통해), 프로그램 버퍼를 통해 "FENCE" 명령어를 실행합니다.
• 코어를 통한 메모리 쓰기 : 디버거가 코어의 관점에서 메모리를 쓴 후(프로그램 버퍼 또는 '메모리 접근' 명령어를 통해), 프로그램 버퍼를 통해 "FENCE" 명령어를 실행합니다.

위의 디버거 동작은 하드웨어의 디버그 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 로 문의 주시기 바랍니다.

감사합니다.

RISC-V ISA 규격은 "ISA 확장"을 정의하며, 이는 기본 ISA를 특정 추가 명령으로 보완할 수 있습니다.

ISA 규격은 표준 ISA 확장 이외에도 핵심 설계자가 자신의 non-standard/custom RISC-V ISA 확장을 정의할 수 있는 방법을 표준화합니다.

TRACE32에서 사용자 지정 비표준 RISC-VISA 확장을 지원하는 방법에는 다음과 같은 두 가지 옵션이 있습니다:

1. Direct intergration
경우에 따라 TRACE32에 특정 사용자 지정 RISC-V ISA 확장에 대한 지원을 직접 추가할 수 있습니다.

이는 주로 disassemble 및 instruction set 시뮬레이터 또는 trace 지원에 영향을 미칩니다.

그런 다음 SYSTem.CPU 명령을 통해 해당 CPU 항목을 선택하는 등의 사용자 지정 확장에 대한 지원을 활성화할 수 있습니다.

소프트웨어에 대한 direct integration을 제공할 수 있는 경우와 어떤 상황에서 제공할 수 있는지에 대해 논의가 필요합니다.

2. APU API를 통한 disassembler 플러그인
TRACE32는 ISA 확장자의 비표준 RISC-V 명령에 의해 disassemble 기능을 확장하기 위해 custom "disassemble plugin"(*.dll 또는 *.so와 같은 공유 라이브러리를 통해)을 로드할 수 있는 API를 제공합니다.

이 API는 API for Auxiliary Processing Unit, 보조 처리 장치를 위한 API(APU API)라고 불립니다.

자세한 내용은 APU API(https://repo.lauterbach.com/pdf/api_apu.pdf)에서 확인할 수 있습니다

위 plugin을 사용하면 다음과 같은 이점이 있습니다.
- 사용자는 이미 chip 및 toolchain 개발 초기 단계에 있는 ISA 확장을 테스트할 수 있으며 변경 사항을 제어할 수 있습니다.
- Lauterbach 또는 MDS테크와의 라이선스 계약은 필요하지 않습니다.
- Lauterbach 또는 다른 당사자에 대한 ISA 확장에 대한 자세한 내용을 밝힐 필요는 없습니다.

APU API는 custom instruction과 함께 instruction trace decording을 지원하기 위해 특정 점프 플래그로 프로그램 흐름 제어 명령어를 표시하고 점프 대상 주소를 정의할 수 있도록 합니다. 아래에 언급된 제한 사항을 참조하십시오.

RISC-VAPU API disassemble 플러그인 사용의 제한 사항에 유의하십시오.
- APU API는 TRACE32 instruction set 시뮬레이터에서 지원되지 않습니다.

TRACE32는 시뮬레이터용 API를 제공하지만 이 API는 주변 동작(API for TRACE32 명령 집합 시뮬레이터)만 시뮬레이션할 수 있고 전체 코어의 동작은 허용하지 않습니다.

- 프로그램 흐름 제어 동작이 더 복잡한 사용자 지정 명령이 있는 경우(예를 들어 새 사용자 지정 분기 명령을 추가하는 경우) trace 지원이 APU API의 일반 인터페이스에 의해 적용될 수 있는지 여부와 방법에 대해 논의가 필요합니다.

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

감사합니다.

RISC-V는 32비트(RV32), 64비트(RV64), 128비트(RV128) 기본 ISA를 사용합니다.

TRACE32는 일반적으로 RV32와 RV64 기본 ISA를 사용하는 코어 아키텍처를 지원합니다.

하지만 RV128 ISA 코어는 현재 지원되지 않습니다.

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

감사합니다.

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 로 문의 주시기 바랍니다.

감사합니다.

디버거는 디버그 모듈의 디버그 레지스터에 액세스할 필요가 없습니다.

제대로 작동하려면 여러 핵심 레지스터(제어 및 상태 레지스터, CSR)도 액세스 가능/구현되어야 합니다.

다음 요약은 디버깅 컨텍스트에 있는 CSR을 나열하고 필요한지 여부를 언급합니다.

Core Debug Registers

• Debug Control and Status (dcsr)
  ① 필수 레지스터입니다. 이 레지스터가 없으면, 디버그 지원이 불가능합니다.
• Debug PC (dpc)
  ① 필수 레지스터입니다. 이 레지스터가 없으면, 디버그 지원이 불가능합니다.
  
• Debug Scratch Register 0/1 (dscratch0/1)
  ① 선택적 레지스터입니다. Lauterbach 디버거는 현재 이 레지스터들을 사용하지 않습니다.
  

Debug/Trace Registers

• Debug/Trace trigger register select (tselect):
  

  ① [debug spec v0.13.x]: 트리거가 구현되었는지와 상관없이 필수입니다.
  ② [debug spec v0.14x and later]: 트리거가 구현된 경우 필수, 그렇지 않은 경우 선택 사항입니다.
  
• First Debug/Trace trigger data register (tdata1):
  ① [debug spec v0.13.x]: 트리거가 구현되었는지와 상관없이 필수입니다.
  ② [debug spec v0.14x and later]: 트리거가 구현된 경우 필수, 그렇지 않은 경우 선택 사항입니다.
  
• Second Debug/Trace trigger data register (tdata2):
  ① 트리거가 구현된 경우 필수, 그렇지 않은 경우 선택 사항입니다.
• Third Debug/Trace trigger data register (tdata3):
  ① 선택적 레지스터(디버거 관점에서)입니다. 현재 디버거는 tdata3이 사용되지 않는 match control 트리거만 지원합니다.
  그러나 나중에 다른 트리거 유형에 사용될 수 있습니다.
• Trigger Extra (textra32/textra64):
  선택적 레지스터(디버거 관점에서)입니다.
  이 트리거의 기능이 mcontrol2 또는 mcontrol6에 필요한 경우에만 필요합니다.
• Trigger Info (tinfo):
  ① 트리거가 구현되고 "trigger type bitfield"(tdata1->type)가 쓰기 가능한 경우 필수입니다.
  그렇지 않으면 선택 사항입니다.
  

• Machine ISA Register (misa):
  ① 이 레지스터는 디버거가 디버깅 중인 코어의 기능을 결정하는 데 도움이 됩니다.
  

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

감사합니다.

TRACE32는 RISC-V 공식 디버거 사양을 기반으로 한 디자인을 지원하고 있습니다.

공식적으로 승인된 첫 번째 디버그 사양은 v0.13 버전이었습니다.

따라서 TRACE32는 v0.14, v1.0 등 v0.13.x 이후 모든 버전을 지원합니다.

그러나 첫 번째 승인된 v0.13 이전의 비공식 초안 버전(예: v0.11)은 지원하지 않습니다.

하지만, TRACE32는 RISC-V 공식 디버그 사양외에 다양한 RISC-V 하드웨어 또한 지원하고 있습니다.

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

감사합니다.

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

이 레지스터의 특정 코어에 대한 비트가

• 1로 설정되어 있다면, SYStem.Option.FREEZE 설정을 통해 코어가 debug halt 상태에 있는 동안 타이머를 실행하거나 중지시킬 수 있습니다.
• 0으로 설정되어 있다면, 타이머는 SYStem.Option.FREEZE 설정에 관계없이 항상 debug halt 상태에서 중지합니다.

"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 로 문의 주시기 바랍니다.

감사합니다.

JTAG를 통한 디버깅을 사용하려면 e500 코어용 리눅스 커널(PQ3/MPC85XX/QorIQ P10XX/P2020) 패치가 필요합니다.

그리고 arch/powerpc/include/asm/reg_book.h에 정의된 MSR_KERNL 매크로는 MSR_DE 비트를 포함하도록 수정이 필요합니다.

#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)

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

감사합니다.

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로 문의 주시기 바랍니다.

감사합니다.