MDSTECH

문제 증상:

• TASK.DTask, TASK.Process 등 일부 또는 모든 "Awareness 창"에서 에러가 발생하거나 화면에 해시 패턴("///////")이 나타납니다.
• Linux 부팅 후 대상(target)이 중지되었을 때 현재 작업(task)이 표시되지 않으며, "(task error)" 또는 "(other)" 메시지가 출력됩니다.
• List 창에 space-id가 0xFFFF가 표시됩니다.

문제 해결 방법

1. 커널 구성 확인

이 문제는 다음과 같은 커널 구성 문제로 인해 발생할 수 있습니다:

• "디버그 정보를 포함하여 커널 컴파일" 설정이 누락된 경우 (CONFIG_DEBUG_INFO).
• "디버깅 정보 축소" 설정이 활성화된 경우 (CONFIG_DEBUG_REDUCED).

C:T32pdftraining_rtos_linux.pdf 문서의 "Kernel Configuration" 섹션을 참고하여 설정을 확인하세요.

2. 번역 설정(Translation) 비활성화

번역 설정이 문제의 원인일 수 있습니다.

• 해결 방법:
  TRANSlation.OFF 명령을 사용하여 번역을 비활성화한 후 결과가 개선되는지 확인하세요.
• 자동 감지 스크립트:
  Arm 및 Arm64 환경을 위한 자동 감지 스크립트가 제공됩니다.
  경로:

  demoarm64kernellinuxboardgeneric-templatedetect_translation.cmm  
  demoarmkernellinuxboardgeneric-templatedetect_translation.cmm

• 스크립트 헤더를 주의 깊게 읽으세요.

스크립트 실행 중 에러가 발생하면, 기술지원 메일을 보내주세요.

3. 로드된 vmlinux와 실행 중인 커널 바이너리의 일치 여부 확인

확인 절차:
1. 터미널에서 다음 명령을 실행하여 대상 Linux 배너 정보를 가져옵니다:

   cat /proc/version
   

2. 디버거 가상 메모리에 vmlinux 파일을 로드합니다:

   Data.LOAD.Elf vmlinux AVM:0 /NoSymbol

3. 로드된

   vmlinux의 linux_banner 정보를 덤프합니다:

   Data AVM:linux_banner /NoHex /NoOrient
   

4. 두 문자열을 timestamp와 함께 비교합니다.

4. 주의사항

"C:T32_202409pdftraining_rtos_linux.pdf" 문서를 참조하여 자세한 정보를 확인하시거나 TRACE32@mdstech.co.kr로 문의주세요.

감사합니다.

타깃을 제어할 수 있는 플래시 프로그래밍 알고리즘음 CPU 자체적으로 수행됩니다.

플래시 알고리즘 실행이 중단되는 경우 "FLASH algorithm did not execute completely" 라는 메시지가 표시됩니다.

이러한 이유에는 여러 가지 원인이 있을 수 있습니다.

와치독이 활성화되어 있는 경우, 플래시 알고리즘이 그로 인해서 중단될 수 있습니다.

TRACE32에서 제공하는 데모 스크립트 중에서 워치독을 비활성화 할 수 있는 명령어가 포함되어 있는 경우가 있으니 참고하시기 바랍니다.

명령어를 찾지 못할 경우에는 사용하는 프로세서/보드의 설명서를 참고하시어 와치독을 제어해주시기 바랍니다.

활성화된 데이터 캐시 또한 이러한 에러를 발생시키는 원인이 될 수 있습니다. 

활성화되어 있는 경우에는 플래시 프로그래밍 스크립트에서 데이터 캐시를 OFF 해주시기 바랍니다.

로드된 이미지 파일에 플래시 알고리즘이 로드된 부분과 동일한 메모리 섹션이 포함되어 있을 수 있습니다.

Data.LOAD.auto <object file> /NoCODE 명령어를 사용한 다음 sYmbol.List.MAP 명령어를 사용하여 이미지 파일의 메모리 맵을 확인할 수 있습니다.

이러한 경우 Data.LOAD 명령에서 Flash 다운로드를 진행할 메모리 범위를 지정하여 이미지 파일을 다운로드할 때, 플래시 알고리즘이 로드된 범위를 제외할 수 있습니다.

잘못된 Flash clock이나 버스 구성으로 인한 것일 수 있습니다.

잘못된 플래시 바이너리로 인한 것일 수 있습니다.

지워진 상태인 내부 FLASH 영역을 읽으면 무작위로 데이터가 깜빡거리기도 합니다.

이는 일반적으로 내부 FLASH가 ECC에 종속되어있기 때문입니다. 따라서 FLASH와 FLASH ECC 영역이 지워지면, ECC값인 0xFF와 지워진 FLASH 0xFF 값이 일치하지 않아 bit error correction 결과가 발생합니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주십시오.

감사합니다.

해당 warning 은 B::Data.LOAD 명령어 실행 후 타깃 플래시 프로그래밍이 진행중일 때 발생합니다.

사용자가 등록한 elf 파일 또는 바이너리 이미지가 온전히 플래시 메모리에 작성되지 않았을 때 발생합니다.

B::FLASH.List 또는 sYmbol.List.MAP 윈도우에서 플래시 메모리가 작성되지 않은 부분을 확인할 수 있으며 값을 버려집니다.

NOP protection으로 인해 해당 warning 이 발생합니다.

참고 사항:

l  Sensitive FLASH sector의 경우 사용자가 의도하지 않은 플래시 write 동작을 사전 방지하기 위해 NOP sector로 지정하는 경우도 있습니다.

l  B::FLASH.CHANGETYPE 명령어를 이용하면 Sensitive sector 에 대해 사용자가 강제적으로 state를 변경할 수 있습니다.

l  명령어와 관련된 자세한 설명은 norflash.pdf 에서 확인할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다

PRACTICE 명령어는 대소문자를 구분하지 않습니다. 

각 명령어는 긴 형태와 짧은 형태가 있으며, 중요한 문자는 항상 대문자로 표시됩니다.

ex) SYStem.Up 명령어의 짧은 형태는 SYS.U입니다.

 이 명령어는 SYStem.Up, system.up, sys.up, system.u 등의 다양한 형태로 실행할 수 있습니다. TRACE32 명령줄에 해당 명령어를 긴 형태나 짧은 형태로 입력한 후, 스페이스바를 누르고 F1 키를 누르면 해당 명령어를 포함한 PDF 문서가 자동으로 열립니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다.

TRACE32는 current task를 감지하고 current task의 스택포인터를 해당 태스크의 라인에 표시합니다.

만약 current task가 TASK.StacK에 나타나지 않았거나, current task가 어떤 스택과도 연결할 수 없을 경우, 

TRACE32는 스택 포인터를 (other)이라고 표시합니다.

• FLASH.Program / FLASH.AUTO 명령어 대신 FLASH.ReProgram 명령어 그룹 사용하기.
• 가능하다면 /DualPort 옵션 사용하기. Onchip/NOR FLASH Programming User’s Guide 문서의 "DualPort FLASH Programming" 을 확인하세요.
• FLASH 프로그래밍 시 모든 TRACE32 memory dump 창 닫기.
• 가능하다면 JTAG clock 높이기.
• 가능하다면 tool based method 방식 대신 target controlled FLASH programming method 방식 사용하기.

자세한 내용은 Onchip/NOR FLASH Programming User’s Guide 문서를 참조하십시오.

다른 궁금한 사항은 trace32@mdstech.co.kr로 문의주십시오.

감사합니다.

보통, 프로그램되거나 삭제 중인 FLASH 메모리에 대해 추측적인 Read 접근은 허용되지 않습니다. Read 접근은 정의되지 않은 결과를 초래할 수 있습니다. 따라서 삭제 중에는 이러한 섹션을 덤프하지 않는 것이 좋습니다.

다른 궁금한 사항은 trace32@mdstech.co.kr로 문의주십시오.

감사합니다.

Raw Memory 쓰기

PRACTICE 스크립트에서 메모리 위치(또는 메모리 매핑 레지스터에 쓰기)를 작성하는 것은 다음 명령과 함께 작동합니다
Data.Set <address> %<format> <value>

프로세서 on-chip 디버깅 구현에서 지원되지 않으므로, CPU 레지스터를 읽고 쓰는 것에 맞춰 프로그램 실행을 중지할 수 없습니다.

프로그램 실행 또는 메모리 액세스(read/write)에 breakpoint를 설정할 수 있을 뿐입니다.

CPU레지스터의 값을 코드실행이나 메모리 읽기/쓰기의 조건으로 포함하여 breakpoint를 설정할 수 있습니다

Break.Set myFunc /Program /CONDition Register(R0)==0

TRACE32는 myFunc 함수가 실행될 때마다 프로그램 실행을 중지하고, R0 값이 0인지 확인합니다.

조건이 거짓이면 프로그램 실행이 재개됩니다.

다른 궁금한 사항은 trace32@mdstech.co.kr로 문의주십시오.

감사합니다.

어셈블리 함수는 컴파일러에 의해, 종종 단일 주소 레이블로 표현됩니다.

이러한 단일 주소를 가지는 어셈블리 함수의 경우 함수 런타임 분석이나 함수 커버리지 창에 포함되지 않을 수 있습니다.

이러한 경우 sYmbol.Bodify.AddressToRange 와 sYmbol.Modify.RangeToFunction 명령어를 함께 사용하여 함수로 인식하게 할 수 있습니다.

예시 :

sYmbol.Modify.AddressToRange _divsi3

sYmbol.Modify.RangeToFunction _divsi3

sYmbol.Modify.AddressToRange 명령은 단일 주소 레이블을 주소 범위가 있는 심볼로 확장합니다.

주소 범위는 심볼 주소에서 시작하여 다음 심볼 주소에서 1을 뺀 주소에서 끝납니다.

sYmbol.Modify.RangeToFunction 명령은 확장된 범위를 함수로 변환합니다.

다른 궁금한 사항은 trace32@mdstech.co.kr로 문의주십시오.

감사합니다.

가능합니다.

Dialog 블록의 시작 부분에 문자 "&"를 추가해야 하며, 그렇지 않으면 Macro가 해당 블록 내에서 확장되지 않습니다.

예시 :

DIALOG.view
(&+
...
)

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다.

다음은 TRACE32 window를 파일로 출력할 때 사용할 수 있는 명령어들입니다:

B::PRinTer.FILE 및 B::WinPrint 명령을 사용하여 TRACE32 window의 내용을 파일로 출력할 수 있습니다.

B::PRinTer.FILE 명령어

• /Append 옵션을 사용하면 기존 파일에 데이터를 추가할 수 있습니다.

• /Append 옵션이 없을 경우, 해당 파일이 이미 존재한다면 파일 내용은 덮어 씌워집니다.

사용 예시:

• B:: PRinTer.FILE output.txt /Append
• B:: WinPrint.Trace.List
• B:: WinPrint.Data.dump 0--0xfff
  
  
• B:: PRinTer.FILE file01.html XHTML
• B:: WinPrint.List.Mix func7--func17

더 많은 사용 예시는 TRACE32 설치 폴더 > pdf > Ide_func.pdf 에서 확인할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다

사용자가 원하는 작업에 따라 적합한 명령어를 사용할 수 있습니다.

외부 프로그램 또는 배치 파일을 실행하려면 아래 명령 중 하나를 사용할 수 있습니다.

(blocking: 명령어 결과가 있을 때까지 현재 작업을 대기. Non-blocking: 명령어 결과 없더라도 진행)

OS.Area <cmdline> : AREA 창에 command 결과가 출력(blocking 방식). 명령 프롬프트 대신 PowerView 의 B::Area 를 이용

OS.Window <cmdline>: PowerView 내 "OS.Window" 창에 출력됨 (blocking 방식). 명령 프롬프트 대신 PowerView 의 OS.Window 를 이용

OS.screen <cmdline>:

· Windows에서는 쉘 없이 명령이 직접 실행되며, 콘솔 애플리케이션의 출력이 임시 명령 창에 표시됨.

· Linux에서는 TRACE32 GUI를 시작한 쉘에 출력이 표시됨 (Nonblocking 방식)

OS.Hidden < cmdline >: 출력이 표시되지 않음 (블로킹 방식)

OS.Command < cmdline >: 시스템 쉘에서 출력되며, 리다이렉션을 허용함.

· Windows에서는 Non-blocking 방식.

· Linux에서는 Blocking 방식이지만 앰퍼샌드(&)를 추가하면 Non-blocking 방식으로 실행 가능.

더 많은 OS 관련 함수는 TRACE32 설치 폴더 > pdf > Ide_func.pdf 에서 확인할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다

ELF 파일은 다음과 같은 소스 정보를 포함하고 있습니다.

• ELF program header는 다음 정보를 포함하고 있습니다.
• 논리 주소와 물리 주소
• 메모리 크기와 파일 크기
• ELF section header는 다음 정보를 포함하고 있습니다.
• 크기가 포함된 주소

Data.LOAD.ELF 명령어의 옵션을 사용하여, 코드 다운로드 시 사용할 주소 및 크기 정보를 설정 할 수 있습니다.

• /CODEPROG는 program table에서 강제로 로딩 합니다.
• /CODESEC는 section table에서 코드를 로드 합니다.
  이 옵션은 링커가 버그가 포함된 program table을 생성할 경우 유용합니다.
• /CODEZERO는 메모리 크기가 파일 크기보다 클 경우, 타깃 메모리를 0으로 채웁니다.
  program header가 ELF 파일보다 더 많은 메모리가 필요하다고 나타내는 경우 (p_memsz > p_filesz) 이 옵션으로 추가 메모리를 0으로 설정할 수 있습니다.
  이는, 일반적으로 타깃 어플리케이션의 start-up 코드에 의해 수행되지만, /CODEZERO 옵션을 사용하면 디버거가 이 메모리를 0으로 채웁니다.
• /LOGLOAD는 프로그램 테이블의 논리주소(p_vaddr)를 사용하여 코드를 로드합니다.(물리 주소 대신)
• /PHYSLOAD는 프로그램 테이블의 물리주소(p_paddr)를 사용하여 코드를 로드합니다.(논리 주소 대신)
• /CODESEC 및 /PHYSLOAD는 section table에서 코드를 로드하고 program table에서 변환합니다.

매크로는 일반적으로 ELF 파일에 있는 DWARF 디버그 정보의 일부가 아닙니다.

따라서 디버거는 해당 값을 알 수 없지만, TRACE32에서 매크로를 선언할 수 있습니다.

sYmbol.CREATE.MACRO MACRO_1 < contents >
sYmbol.CREATE.MACRO MACRO_2 < contents >
sYmbol.CREATE.Done

다음을 사용하여 수동으로 만든 매크로 목록을 표시할 수 있습니다.

sYmbol.List.MACRO

때로는 컴파일러가 매크로 정보를 ELF 파일에 내보낼 수도 있습니다.

이는 GCC 컴파일러의 경우 -g3 옵션을 사용하여 ".debug_macinfo" 섹션에 매크로 정보를 내보냅니다.

Data.LOAD.Elf 명령을 사용하여 이러한 ELF 파일을 로드하는 경우 /MACRO 옵션을 사용하여 매크로 정보를 TRACE32로 가져옵니다.

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

감사합니다.

ON 또는 GLOBALON 명령어를 사용하여 스크립트를 실행할 수 있습니다.

ON은 테스트 케이스를 제어하는 ​​스크립트가 실행중인 경우에 적합합니다.

GLOBALON은 이벤트를 다시 비활성화할 때까지 이벤트에 대한 액션을 원하는 경우에 적합합니다.

명령어 사용법은 다음과 같습니다. ON|GLOBALON < event > < action >

지원되는 이벤트 및 동작에 대한 자세한 내용은

"General Commands Reference Guide O" 및 "General Commands Reference Guide G" 메뉴얼에서

각각 ON 및 GLOBALON 명령에 대한 설명을 참고하세요.

이벤트 핸들러를 비활성화하려면 ON|GLOBALON < event > inherit 를 사용하세요.

예:

1. 프로그램 실행이 멈추면 지정한 스크립트를 실행합니다.

GLOBALON PBREAK DO myscript.cmm

2. 프로그램 실행중 에러가 발생하면 스크립트 실행을 계속합니다.

ON ERROR CONTinue

3. 타겟 전원이 들어오면 powerup_handler 함수를 실행합니다.

ON POWERUP GOSUB powerup_handler

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

감사합니다.

TRACE32에서는 새로운 타입을 수동으로 추가할 수 없습니다.

해결책으로, 소스 파일 내에서 타입을 선언한 후 컴파일하고, 결과로 나온 ELF 파일을 TRACE32에 로드하는 방법이 있습니다.

예시:

1. C 파일에서 타입을 선언합니다:

typedef struct {
int a;
int b;
int d;
} myStruct_t;
volatile myStruct_t *dummy;

2. C 파일을 컴파일합니다.

gcc typedef.c -g -o typedef.elf -nostartfiles -nodefaultlibs

3. ELF 파일을 /NoCODE 및 /NoCLEAR 옵션을 사용해 TRACE32에 로드합니다:

Data.LOAD.Elf typedef.elf /NoClear /NoCODE

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다.

이 오류는 해당 breakpoint가 빈번하게 실행될 때 발생합니다.

/RESUME 옵션은 스크립트 실행 후 프로그램 실행을 다시 시작하지만, 스크립트 실행이 끝날 때까지 기다리지 않습니다.

두 번째 breakpoint가 HIT되면 첫 번째 스크립트가 여전히 실행 중인 상태에서 두 번째 스크립트가 시작됩니다.

breakpoint가 자주 실행되면 병렬로 실행되는 스크립트 수가 특정 최대치를 초과하고, 이로 인해 "PRACTICE Stack Overflow" 오류가 발생할 수 있습니다.

이를 해결하려면 다음 해결책 중 하나를 사용할 수 있습니다:

● /RESUME 옵션을 제거하고 스크립트의 끝에 Go 명령을 삽입하세요.
이 경우 스크립트가 끝난 후에 실행이 다시 시작됩니다.
하지만 breakpoint가 자주 실행되면 여전히 "PRACTICE Stack Overflow" 오류가 발생할 수 있습니다.

● DO 명령어를 개별 PRACTICE 명령어로 교체하세요. 예를 들어,

Break.Set < address > /CMD "DO script.cmm" /RESUME

대신,

Break.Set < address > /CMD "" /CMD "" ... /RESUME

● 스크립트 내에서 DO 명령어를 JUMPTO로 교체하세요. 예를 들어:

Break.Set < address > /CMD "JUMPTO do_it"

STOP

do_it:

...

Go

STOP

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

감사합니다.

아래와 같은 명령어를 통해 breakpoint를 setting하거나 아래 스크린샷과 같이 설정하면 가능합니다.

break.set /program /CMD "Do myscript.cmm"

호출된 cmm script의 끝에 "go" 명령어를 추가하여 타겟의 실행을 계속할 수 있습니다.

break.set 명령어는 /resume 옵션도 허용하며,

/resume 옵션을 추가 혹은 허용할 경우 do myscript.cmm 명령어가 실행된 후 프로그램 실행을 재개합니다.

주의사항으로,

스크립트를 실행하는데 시간이 오래걸린다면, practice 스크립트가 완료될 때까지 기다리지 않으므로, 사용하지 않는게 좋습니다.

추가로 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다.

모든 함수는 일반적인 경우 return이라고 불리는 의사 변수(pseudo-variable)를 가지고 있습니다.

이는 sYmbol.Browse.Var \\*\*\< myfunc >\* 창에서 확인할 수 있습니다. (myfunc 은 함수 이름)

PRACTICE 함수에서 Var.VALUE( < variable > ) 명령을 사용하면 모든 변수의 값을 확인할 수 있습니다.

이를 통해 myfunc() 함수의 반환 값을 얻을 수 있습니다.

GO sYmbol.EXIT(myfunc) // myfunc의 return 문으로 이동

Break.set 명령어에는 /VarCONDition 옵션이 있으며,

이 옵션을 사용하면 설정된 breakpoint에 도달한 후 CPU 가 중지된 상태로 유지되는 조건을 지정할 수 있습니다.

(breakpoint를 설정하기 위한 다이얼로그에서 "advanced" 항목을 클릭하면, "Condition" 필드를 찾을 수 있습니다.)

Example : 함수 MyFunc에 변수 x==10 및 y==11 옵션으로 breakpoint를 설정합니다.

Break.Set MyFunc /VarCONDition (x==10 && y==11)

결과적으로, MyFunc 함수가 실행될 때마다 CPU 가 중지되지만, 조건 "x==10 && y==11"를 만족하지 않으면, 재 실행됩니다.

PRACTICE 언어로 Break.Set 명령어에 /VarCONDition 옵션 대신 /CONDition을 사용하여 조건을 지정할 수도 있습니다.

이는 Break.Set 창의 CONDition 필드의 HLL 체크박스를 체크 해제하는 것에 해당합니다.

Example : 첫 번째 예제의 동일한 조건으로 다음과 같이 사용할 수 있습니다.

Break.Set MyFunc /CONDition (Var.Value(x)==10. && Var.Value(y)==11.)

참고 : 

PRACTICE의 기본 기수 모드는 16진수이므로 10진수 값을 나타내기 위해 10과 11 뒤에 '온점'을 추가해야 합니다.

그렇지 않으면 0x10과 0x11이 기본적으로 사용됩니다.

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

감사합니다.

다음 구문을 사용하여 c:\t32\myproject 경로에 있는 myfile.c 파일의 42번째 줄에 브레이크포인트를 설정할 수 있습니다:

Break.Set \"c:\t32\myproject\myfile.c"\42
또는
Break.Set \myfile\42

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

이 오류 메시지는 오브젝트 파일 내에 코드나 데이터를 동일한 주소로 로드하는 섹션이 있다는 것을 의미하며, 이는 오브젝트 파일의 오류입니다.

TRACE32는 이러한 섹션들을 오브젝트 파일에 나타난 순서대로 로드합니다.

sYmbol.List.MAP 명령을 사용하여 섹션이 어떤 순서로 무슨 코드가 로드되었는지 확인할 수 있습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다.

이 오류 메시지는 다음과 같은 이유로 발생할 수 있습니다:

1. 오브젝트 파일이 손상되었을 수도 있습니다. 파일을 다시 컴파일해 보세요.

2. 오브젝트 파일이 TRACE32 PowerView에서 지정한 아키텍처가 아닌 다른 아키텍처로 컴파일되었는지 확인해 보세요.

예를 들어 Arm용 TRACE32 PowerView에서 x86용으로 컴파일된 ELF 파일을 로드하는 경우 이 오류 메시지가 표시됩니다.

3. 파일 형식이 TRACE32 버전에서 지원되지 않는 경우입니다.

예를 들어 사용 중인 TRACE32 소프트웨어에서 지원하지 않는 최신 컴파일러 버전을 사용하는 경우 이런 일이 발생할 수 있습니다.

최신 TRACE32 릴리스로 업데이트하거나 trace32@mdstech.co.kr에 소프트웨어를 요청하세요.

4. 오브젝트 파일의 형식이 아직 TRACE32 PowerView에서 지원되지 않는 경우입니다.

가능하신다면, 오브젝트 파일을 포함하여 trace32@mdstech.co.kr 에 연락 주세요.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다

TRACE32 PowerView 사용자 인터페이스를 비활성화하려면

TRACE32 config 파일(T32 폴더 밑에 config.t32 파일)에서 SCREEN=로 시작하는 줄을 찾아 SCREEN=OFF로 변경합니다.

SCREEN=로 시작하는 줄이 없는 경우 파일 끝에 빈 줄을 추가한 다음 SCREEN=OFF 줄을 추가합니다.

그런 다음 수행하려는 작업이 포함된 시작스크립트로 TRACE32 PowerView를 시작하거나

외부 프로그램(예를들면 python 스크립트 또는 C 어플리케이션)에서 TRACE32 어플리케이션을 제어할 수 있습니다.

TRACE32 어플리케이션은 OS 반환값읗 인수로 사용할 수 있는 quit 명령을 사용하여 닫을 수 있습니다.

자세한 내용은 "TRACE32 installation guide"와 "API for remote control and jtag access in C" 에서 확인하시면 됩니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다.

인라인 함수는 각 call site의 calling functions 내부에 내장되어 있으며 고유 시작 주소가 없습니다.

인라인 함수는 sYmbol.List.InlineFunction 명령을 사용하여 TRACE32에 표시할 수 있습니다

컴파일러가 debug information의 인라인에 대한 정보를 제공하는 경우 디버거는 인라인 함수에 대한 일부 정보를 표시할 수 있습니다.

인라인 함수의 call site는 "인라인된 함수" 아래에 있는 sYmbol.INFO 명령을 사용하여 TRACE32에 표시할 수 있습니다.

예를 들어 다음 이미지는 함수 func1이 함수 func2 내부에 두 번 인라인 되었음을 보여줍니다:

이 정보는 함수 stack frame의 디버거에서 사용됩니다(Frame.view)

함수에 고유 시작 주소가 없으므로 함수 시작 시 breakpoint를 설정할 수 없습니다.

따라서 breakpoint 시 TRACE32에 "symbol not found"라는 오류 메시지가 표시됩니다

그러나 assembly로 변환된 인라인 함수의 싱글 라인에서 program breakpoint를 설정할 수 있습니다.

함수가 두 번 이상 인라인으로 표시되면 다른 호출 지점을 표시하도록 확장할 수 있는 [+] 기호가 표시될 수 있습니다

TRACE32는 Trace.STATistic.sYmbol, Trace.Chart.sYmbol 및 Trace.PROFILEChart.sYmbol 명령의 /INLINE 옵션을 사용하여 Trace 결과를 기반으로

인라인 함수에 대한 runtime 정보를 표시할 수 있습니다.

이러한 명령에 대한 자세한 내용은 https://www.lauterbach.com/pdf/general_ref_t.pdf 을 참조하세요

최적화 코드 디버깅에 대한 자세한 내용은 다음 동영상을 참조하세요:

https://support.lauterbach.com/kb/articles/debugging-optimized-code-in-trace32

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의 주십시오.

감사합니다.

해당 에러는 지원되는 컴파일러를 설치한 후 MATLAB에서 C/C++ MEX 컴파일러가 설정되지 않은 경우 발생합니다.

자세한 내용은 아래의 링크를 참고하십시오.

https://www.mathworks.com/support/requirements/supported-compilers.html
https://www.mathworks.com/help/matlab/matlab_external/changing-default-compiler.html

해당 에러 상황은 또한 다음이 경우에도 나타날 수 있습니다.

- Simulink와 TRACE32의 통합 환경에서 TRACE32 설치 폴더의 demo/api/capi/dll 내부에서 t32api 라이브러리를 찾을 수 없습니다.

(Windows의 경우 t32api64.dll/t32api.dll, Linux의 경우 t32api64.so)

- Simulink와 TRACE32의 통합 환경에서 TRACE32 설치 폴더의 deml/api/capi/src 내부에서 t32.h 헤더 파일을 찾을 수 없습니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr로 문의주십시오.

감사합니다.

구성 파일(예: config.t32)에 SCREEN= 옵션을 추가하여 TRACE32 Hidden Instance로 시작하는 세 가지 방법이 있습니다.

다음 옵션 중 하나를 선택하세요.

1. TRACE32의 main window는 안 보이는 상태로 유지됩니다.

그러나 dialog 나 다른 window들은 ​​열 수 있습니다.

테스트 중 오류가 발생하는 경우에 유용합니다.

SCREEN=

INVISIBLE

2. TRACE32의 main window를 포함해 모든 dialog와 window들은 오류가 발생하더라도 보이지 않습니다.

SCREEN=OFF

3. TRACE32의 main window가 호스트 컴퓨터의 툴바에 추가됩니다.

오류가 발생하는 경우 전체가 표시될 수 있습니다.

SCREEN=

VICON

자세한 내용은 TRACE32 설치 가이드의 "TRACE32 as a Hidden Instance" 챕터를 참고해주세요.

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

감사합니다.

"Bus error"는 TRACE32 디버거가 특정 메모리 접근을 시도할 때 CPU가 처리할 수 없는 영역이면 발생합니다.

Bus error는 CPU 내부에서 먼저 발생하고 TRACE32 디버거에는 나중에 보고됩니다.

Bus error의 원인:

• 특정 주소에 메모리가 없음(No memory available)
• 접근 거부 (읽기 또는 쓰기 보호된 영역)
• 잘못된 접근 모드 (access width, length)

Buss error가 발생한 영역에 대한 오류 메시지가 명확하지 않을 수 있습니다.

예를 들어, B::List나 B::Data.dump 창에서는 버스 오류가 ???????로 표시될 수 있습니다.

1. Buss error의 원인을 알아보기 위해 다음 단계를 시도해봅니다:

2. TRACE32 명령 식별: Bus error를 유발하는 TRACE32 명령(read, write)이나 창 열기(B::List)와 같은 특정 TRACE32 action을 확인합니다.

3. Bus error 재현 준비: Bus error를 재현할 환경을 설정합니다. 오류를 발생시키지 않습니다.

4. 로그 설정:

B::SYStem.LOG 창을 엽니다.

Init 버튼을 눌러 "log" 상태를 ON으로 설정합니다.

5. 로그 리스트 열기: B::SYStem.LOG.List 창을 엽니다.

6. Bus error 발생: Bus error를 유발하는 작업을 수행합니다.

7. 로그 분석: B::SYStem.LOG.List 창의 마지막 줄에 Bus error를 유발한 접근 정보와 action을 확인합니다.

다른 궁금한 사항은 TRACE32@mdstech.co.kr 로 문의 주십시오.

감사합니다