[参考译文] CODECOMPOSER：AM64x R5f 上的内核跟踪解码问题

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1193512/codecomposer-core-trace-decoding-issues-on-am64x-r5f

器件型号：CODECOMPSER

尊敬的 TI 团队：

我尝试使用 CCS 内核跟踪功能来分析一些难以捕捉的崩溃/错误。我当前在 CCS 12.0上、但我在先前版本中看到过此问题(例如、早期 MCU+ SDK 版本所需的 CCS 10.x、11.x)。

我认为、过去(AM65x、PDK、TI-RTOS、GCC)这没什么问题。函数/文件/LineNo 信息并不总是100%正确、但是基本上已经足够好了。

我非常确信、由于我们切换到了 AM64x (MCU+ SDK、FreeRTOS、ti-CGT-armlllvm)、解码的跟踪信息基本上缺少函数/文件/线路否信息、而是显示 N/A。

更糟糕的是、它显然甚至没有正确解码已执行的指令。

例如、在本例中、内核跟踪告诉我它在函数末尾执行的指令超过了"bx LR"：

313981,0x700A0300,0x0000E7FF,n/a,,n/a,n/a,313980,
313982,0x700A0302,0x00009803,n/a,,n/a,n/a,313981,
313983,0x700A0304,0xF6447168,n/a,,n/a,n/a,313982,
313984,0x700A0308,0xF2C7010A,n/a,,n/a,n/a,313983,
313985,0x700A030C,0x00006809,n/a,,n/a,n/a,313984,
313986,0x700A030E,0x00003118,n/a,,n/a,n/a,313985,
313987,0x700A0310,0xF7FFFBFE,n/a,,n/a,n/a,313986,
313988,0x7009FB10,0x0000B084,n/a,,n/a,n/a,313987,
313989,0x7009FB12,0x00009003,n/a,,n/a,n/a,313988,
313990,0x7009FB14,0x00009102,n/a,,n/a,n/a,313989,
313991,0x7009FB16,0x00009802,n/a,,n/a,n/a,313990,
313992,0x7009FB18,0x00006800,n/a,,n/a,n/a,313991,
313993,0x7009FB1A,0x00009000,n/a,,n/a,n/a,313992,
313994,0x7009FB1C,0x00009800,n/a,,n/a,n/a,313993,
313995,0x7009FB1E,0x00003001,n/a,,n/a,n/a,313994,
313996,0x7009FB20,0x0000B920,n/a,,n/a,n/a,313995,
313997,0x7009FB22,0x0000E7FF,n/a,,n/a,n/a,313996,
313998,0x7009FB24,0x00009803,n/a,,n/a,n/a,313997,
313999,0x7009FB26,0x00006900,n/a,,n/a,n/a,313998,
314000,0x7009FB28,0x00009001,n/a,,n/a,n/a,313999,
314001,0x7009FB2A,0x0000E010,n/a,,n/a,n/a,314000,
314002,0x7009FB4E,0x00009801,n/a,,n/a,n/a,314001,
314003,0x7009FB50,0x00006840,n/a,,n/a,n/a,314002,
314004,0x7009FB52,0x00009902,n/a,,n/a,n/a,314003,
314005,0x7009FB54,0x00006048,n/a,,n/a,n/a,314004,
314006,0x7009FB56,0x00009802,n/a,,n/a,n/a,314005,
314007,0x7009FB58,0x00006841,n/a,,n/a,n/a,314006,
314008,0x7009FB5A,0x00006088,n/a,,n/a,n/a,314007,
314009,0x7009FB5C,0x00009801,n/a,,n/a,n/a,314008,
314010,0x7009FB5E,0x00009902,n/a,,n/a,n/a,314009,
314011,0x7009FB60,0x00006088,n/a,,n/a,n/a,314010,
314012,0x7009FB62,0x00009802,n/a,,n/a,n/a,314011,
314013,0x7009FB64,0x00009901,n/a,,n/a,n/a,314012,
314014,0x7009FB66,0x00006048,n/a,,n/a,n/a,314013,
314015,0x7009FB68,0x00009803,n/a,,n/a,n/a,314014,
314016,0x7009FB6A,0x00009902,n/a,,n/a,n/a,314015,
314017,0x7009FB6C,0x00006108,n/a,,n/a,n/a,314016,
314018,0x7009FB6E,0x00009903,n/a,,n/a,n/a,314017,
314019,0x7009FB70,0x00006808,n/a,,n/a,n/a,314018,
314020,0x7009FB72,0x00003001,n/a,,n/a,n/a,314019,
314021,0x7009FB74,0x00006008,n/a,,n/a,n/a,314020,
314022,0x7009FB76,0x0000B004,n/a,,n/a,n/a,314021,
314023,0x7009FB78,0x00004770,n/a,,n/a,n/a,314022,
314024,0x7009FB7A,0x00000000,n/a,,n/a,n/a,314023,
314025,0x7009FB7C,0x00000000,n/a,,n/a,n/a,314024,
314026,0x7009FB7E,0x00000000,n/a,,n/a,n/a,314025,

这是反汇编的一部分(从之前的分支和链接返回 vTaskPlaceOnEventList 中的某个位置、对 vListInsert 的调用以及该函数的执行)：

700a02d0 <vTaskPlaceOnEventList>:
...
700a0300: ff e7        	b	0x700a0302 <vTaskPlaceOnEventList+0x32> @ imm = #-2
700a0302: 03 98        	ldr	r0, [sp, #12]
700a0304: 44 f6 68 71  	movw	r1, #20328
700a0308: c7 f2 0a 01  	movt	r1, #28682
700a030c: 09 68        	ldr	r1, [r1]
700a030e: 18 31        	adds	r1, #24
700a0310: ff f7 fe fb  	bl	0x7009fb10 <vListInsert> @ imm = #-2052

7009fb10 <vListInsert>:
7009fb10: 84 b0        	sub	sp, #16
7009fb12: 03 90        	str	r0, [sp, #12]
7009fb14: 02 91        	str	r1, [sp, #8]
7009fb16: 02 98        	ldr	r0, [sp, #8]
7009fb18: 00 68        	ldr	r0, [r0]
7009fb1a: 00 90        	str	r0, [sp]
7009fb1c: 00 98        	ldr	r0, [sp]
7009fb1e: 01 30        	adds	r0, #1
7009fb20: 20 b9        	cbnz	r0, 0x7009fb2c <vListInsert+0x1c> @ imm = #8
7009fb22: ff e7        	b	0x7009fb24 <vListInsert+0x14> @ imm = #-2
7009fb24: 03 98        	ldr	r0, [sp, #12]
7009fb26: 00 69        	ldr	r0, [r0, #16]
7009fb28: 01 90        	str	r0, [sp, #4]
7009fb2a: 10 e0        	b	0x7009fb4e <vListInsert+0x3e> @ imm = #32
7009fb2c: 03 98        	ldr	r0, [sp, #12]
7009fb2e: 08 30        	adds	r0, #8
7009fb30: 01 90        	str	r0, [sp, #4]
7009fb32: ff e7        	b	0x7009fb34 <vListInsert+0x24> @ imm = #-2
7009fb34: 01 98        	ldr	r0, [sp, #4]
7009fb36: 40 68        	ldr	r0, [r0, #4]
7009fb38: 00 68        	ldr	r0, [r0]
7009fb3a: 00 99        	ldr	r1, [sp]
7009fb3c: 88 42        	cmp	r0, r1
7009fb3e: 05 d8        	bhi	0x7009fb4c <vListInsert+0x3c> @ imm = #10
7009fb40: ff e7        	b	0x7009fb42 <vListInsert+0x32> @ imm = #-2
7009fb42: ff e7        	b	0x7009fb44 <vListInsert+0x34> @ imm = #-2
7009fb44: 01 98        	ldr	r0, [sp, #4]
7009fb46: 40 68        	ldr	r0, [r0, #4]
7009fb48: 01 90        	str	r0, [sp, #4]
7009fb4a: f3 e7        	b	0x7009fb34 <vListInsert+0x24> @ imm = #-26
7009fb4c: ff e7        	b	0x7009fb4e <vListInsert+0x3e> @ imm = #-2
7009fb4e: 01 98        	ldr	r0, [sp, #4]
7009fb50: 40 68        	ldr	r0, [r0, #4]
7009fb52: 02 99        	ldr	r1, [sp, #8]
7009fb54: 48 60        	str	r0, [r1, #4]
7009fb56: 02 98        	ldr	r0, [sp, #8]
7009fb58: 41 68        	ldr	r1, [r0, #4]
7009fb5a: 88 60        	str	r0, [r1, #8]
7009fb5c: 01 98        	ldr	r0, [sp, #4]
7009fb5e: 02 99        	ldr	r1, [sp, #8]
7009fb60: 88 60        	str	r0, [r1, #8]
7009fb62: 02 98        	ldr	r0, [sp, #8]
7009fb64: 01 99        	ldr	r1, [sp, #4]
7009fb66: 48 60        	str	r0, [r1, #4]
7009fb68: 03 98        	ldr	r0, [sp, #12]
7009fb6a: 02 99        	ldr	r1, [sp, #8]
7009fb6c: 08 61        	str	r0, [r1, #16]
7009fb6e: 03 99        	ldr	r1, [sp, #12]
7009fb70: 08 68        	ldr	r0, [r1]
7009fb72: 01 30        	adds	r0, #1
7009fb74: 08 60        	str	r0, [r1]
7009fb76: 04 b0        	add	sp, #16
7009fb78: 70 47        	bx	lr
7009fb7a: 00 00        	movs	r0, r0
7009fb7c: 00 00        	movs	r0, r0
7009fb7e: 00 00        	movs	r0, r0

我认为(其中一个)跟踪解码现在比过去失败的频率更高的原因是、许多 MCU+ SDK 代码现在编译为 Thumb 代码、而在以前大多数/全部是 ARM 代码。

我已转储 ETB 内容并使用 OpenCSD 对其进行解码：

Idx:65211; ID:10; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x700a0300 )
Idx:65211; ID:10; OCSD_GEN_TRC_ELEM_ADDR_UNKNOWN()
Idx:65212; ID:10; [0xbc ];	P_HDR : Atom P-header.; EEEEEEEEEEEEEEE
Idx:65213; ID:10; [0xbc ];	P_HDR : Atom P-header.; EEEEEEEEEEEEEEE
Idx:65214; ID:10; [0x90 ];	P_HDR : Atom P-header.; EEEE
Idx:65216; ID:10; [0x15 ];	BRANCH_ADDRESS : Branch address.; Addr=0x700A0314 ~[0x14]; 
Idx:65217; ID:10; [0xbc ];	P_HDR : Atom P-header.; EEEEEEEEEEEEEEE
Idx:65217; ID:10; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x700a0314 )

从地址0x700a0300开始、代码执行49条指令、直到返回地址0x700a0314、没有任何指令"未执行"(将表示为"N"而不是"E"、例如"Atom P-header.；EEEN")：

vTaskPlaceOnEventList 中的7条指令，直到分支到 vListInsert
9从0x7009fb10到0x7009fb20的指令、此时采用条件分支
- 内核跟踪倾向于在指令7009fb24之后继续执行、我认为这是错误的
10条指令、从0x7009fb2c 到0x7009fb3E、此时采用条件分支
从0x7009fb4c 到0x7009fb78之间23条指令、此时该函数通过"bx LR"返回
- 内核跟踪倾向于在"bx LR"之后继续在地址0x7009fb7a 至0x7009fb84处执行

内核跟踪还从0x700a0300开始对49条指令进行解码、直到从0x700a0314恢复、但显然它忽略所有条件分支并且"仅捕获"无条件分支。

我非常确信、内核跟踪无法解码条件拇指模式分支。
我只是猜测在切换到 CGT-ARM-llvm 后、无法解码功能/文件/线路。
这些是已知问题吗？是否已计划对该非常有用的功能进行修复？

此致、

多米尼克

2 年多前

0 admin 2 年多前

TI__Guru**** 2343840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Dominic：

感谢您的查询、抱歉回复延迟。我已获取您的输入并对其进行研究。除了回答您的问题时出现一些延迟外、感谢您的耐心等待。

谢谢。此致、

Tushar Thakur

0 admin 2 年多前

TI__Guru**** 2343840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Dominic：

[quote userid="387520" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1193512/codecomposer-core-trace-decoding-issues-on-am64x-r5f 我当前使用的是 CCS 12.0

我假设您使用 TVT 将跟踪数据可视化并导出到*。csv 文件。 TVT 过去在正确关联正确的文件/函数/行信息方面存在几个问题。我相信、如果这些问题在当前最新的 CCS 版本(CCS 12.2.0)中得到解决、我会有所帮助。您能试一下这个版本吗、看看这对您有什么帮助吗？

谢谢

小标题

0 admin 2 年多前

TI__Guru**** 2343840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Ki 您好、

我不得不承认我不知道什么是"TVT"。我正在使用"Tools -> Code Analysis -> Core Trace"功能。这会打开一个视图"Core Trace"、我可以在其中配置跟踪并启动它。一旦目标停止、跟踪数据便会从 AM64x ETB 中下载并显示在表格中。该表缺少文件/功能/行信息。在该视图中、我可以将数据另存为.tdf、.csv 或.sqlite3。我通常会尽快将数据保存到.csv 中、因为 CCS 中的查看器似乎无法处理60k-200k 的线迹。

在 CCS 12.2中、文件/函数/行问题似乎要好得多、但在 addr2line 给出正确结果的某些地址上仍然失败。例如、它仅对编译器支持库中的所有__aeabi_uldivmod 等显示 n/a。我有一个 Python 脚本、运行在 CCS/Core Trace 输出的 CSV 文件上、该脚本通过 addr2line 传递每个地址、这让我获得了几乎完整的文件/函数/行信息、因此这不是很容易解决的问题。

但是，无法正确解码跟踪地址的问题仍然存在：

以下是跟踪执行的一些部分(这次使用 CCS 12.2.0)：

231325	0x7009D5D0	0xF64040F8	vTaskExitCritical	4364	任务 c	FreeRTOS 内核	231324.
231326.	0x7009D2D4	0xF2C7000A	vTaskExitCritical	4364	任务 c	FreeRTOS 内核	231325
231327.	0x7009D5D8	0x00006800	vTaskExitCritical	4364	任务 c	FreeRTOS 内核	231326.
231328.	0x7009D5DA	0x0000B168	vTaskExitCritical	4364	任务 c	FreeRTOS 内核	231327.
231329.	0x7009D5DC	0xF64040B0	vTaskExitCritical	4366.	任务 c	FreeRTOS 内核	231328.
231330.	0x7009D5E0	0xF2C7000A	vTaskExitCritical	4366.	任务 c	FreeRTOS 内核	231329.
231331.	0x7009D5E4	0x00006801	vTaskExitCritical	4366.	任务 c	FreeRTOS 内核	231330.
231332.	0x7009D5E6	0x00006D49	vTaskExitCritical	4366.	任务 c	FreeRTOS 内核	231331.
231333.	0x7009D5E8	0x0000B131	vTaskExitCritical	4366.	任务 c	FreeRTOS 内核	231332.
231334.	0x7009D5EA	0x00006801	vTaskExitCritical	4368.	任务 c	FreeRTOS 内核	231333.
231335.	0x7009D5EC	0x00006D4A	vTaskExitCritical	4368.	任务 c	FreeRTOS 内核	231334.
231336.	0x7009D5EE	0x00003A01	vTaskExitCritical	4368.	任务 c	FreeRTOS 内核	231335.
231337.	0x7009D5F0	0x0000654A	vTaskExitCritical	4368.	任务 c	FreeRTOS 内核	231336.
231338.	0x7009D5F2	0x00006800	vTaskExitCritical	4370	任务 c	FreeRTOS 内核	231337.
231339.	0x7009D5F4	0x00006D40	vTaskExitCritical	4370	任务 c	FreeRTOS 内核	231338.
231340.	0x7009D5F6	0x0000B100	vTaskExitCritical	4370	任务 c	FreeRTOS 内核	231339.
231341.	0x7009D5F8	0x00004770	vTaskExitCritical	4388.	任务 c	FreeRTOS 内核	231340.
231342.	0x7009D5FA	0x0000B662	vTaskExitCritical	4372.	任务 c	FreeRTOS 内核	231341.
231343	0x7009D5FC	0x00004770	vTaskExitCritical	4388.	任务 c	FreeRTOS 内核	231342.
231344.	0x7009D5FE	0x00000000	不适用		不适用	不适用	231343

下面是相应的反汇编代码：

7009d5d0 <vTaskExitCritical>:
7009d5d0: 40 f6 f8 40  	movw	r0, #3320
7009d5d4: c7 f2 0a 00  	movt	r0, #28682
7009d5d8: 00 68        	ldr	r0, [r0]
7009d5da: 68 b1        	cbz	r0, 0x7009d5f8 <vTaskExitCritical+0x28> @ imm = #26
7009d5dc: 40 f6 b0 40  	movw	r0, #3248
7009d5e0: c7 f2 0a 00  	movt	r0, #28682
7009d5e4: 01 68        	ldr	r1, [r0]
7009d5e6: 49 6d        	ldr	r1, [r1, #84]
7009d5e8: 31 b1        	cbz	r1, 0x7009d5f8 <vTaskExitCritical+0x28> @ imm = #12
7009d5ea: 01 68        	ldr	r1, [r0]
7009d5ec: 4a 6d        	ldr	r2, [r1, #84]
7009d5ee: 01 3a        	subs	r2, #1
7009d5f0: 4a 65        	str	r2, [r1, #84]
7009d5f2: 00 68        	ldr	r0, [r0]
7009d5f4: 40 6d        	ldr	r0, [r0, #84]
7009d5f6: 00 b1        	cbz	r0, 0x7009d5fa <vTaskExitCritical+0x2a> @ imm = #0
7009d5f8: 70 47        	bx	lr
7009d5fa: 62 b6        	cpsie i
7009d5fc: 70 47        	bx	lr
7009d5fe: 00 00        	movs	r0, r0

我相信代码显然无法按顺序执行地址7009d5f8、7009d5fa、7009d5fc 和7009d5fe。正如我在初始文章中所解释的那样、我之前手动解码了所有跟踪数据(这是一个非常乏味耗时的过程、我这次没有重复)、并且原始跟踪数据看起来是正确的并与二进制匹配。只是"内核跟踪"(或者任何为此而设置的后端)在处理 Thumb-2条件分支时、在解码跟踪数据时犯了错误。

此致、

多米尼克

0 admin 2 年多前

TI__Guru**** 2343840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Unknown 说：
我不得不承认我不知道什么是"TVT"。我正在使用"工具->代码分析->内核跟踪"功能。

是的、这应该是 TVT (跟踪可视化工具套件)：

https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#trace-visualization-toolkit

Unknown 说：
在 CCS 12.2中，文件/函数/行问题似乎要好得多，但在 addr2line 给出正确结果的某些地址上，该问题仍然失败。

听说12.2.0更好。这也是我的印象。请注意、虽然修复了几个问题、但针对此问题提交的错误仍然未决、这表明并非所有问题都已解决。因此、您仍然观察到一些未决问题。

Unknown 说：
例如，它仅显示所有__aeabi_uldivmod 的不适用，等等来自编译器支持库的内容。

编译器支持库中的内容可能会出现问题、具体取决于链接的库中的调试符号信息量。 TVT 依赖可执行文件的可用调试符号。

Unknown 说：
，原始跟踪数据似乎正确，并且与二进制文件匹配。只是"内核跟踪"(或任何后端)在处理 Thumb-2条件分支时、在解码跟踪数据时犯了错误。[/引号]
所以原始数据是正确的、但它只是显示在跟踪查看器中的值和导出到 csv 文件中的数据吗？是的、这将是 TVT 在数据解码方面的问题、以及它如何填补所收集到的不连续性差距。我需要 TVT 工程师进一步调查。

是否还有机会提供原始数据？您可以通过专有 E2E 对话发送。

谢谢

小标题

0 admin 2 年多前

TI__Guru**** 2343840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Ki 您好、

"对不起,我不小心给弄丢了。"

novar luo 说：
好得听12.2.0更好。这也是我的印象。请注意、虽然修复了几个问题、但针对此问题提交的错误仍然未决、这表明并非所有问题都已解决。因此，您还发现了一些未解决的问题。

不幸的是，"好"似乎与"好"有很长的距离。我想这取决于代码的具体编译方式、但在我的最新跟踪中、TVT 通常无法识别文件/行/函数。附加的存档包含两个文件：

"nested_interrupts_r5fs0-0\Debug\core_trace_unto_crash.csv：由 TVT 导出的 CSV 与 IDE Core 跟踪视图中显示的值匹配

"nested_interrupts_r5fs0-0\Debug\core_trace_tho_crash-annoted.csv：由我自己的脚本进行后处理、该脚本通过 addr2line 运行每个执行的地址

novar luo 说：

所以原始数据是正确的、但它只是显示在跟踪查看器中的值和导出到 csv 文件中的数据吗？是的、这将是 TVT 在数据解码方面的问题、以及它如何填补所收集到的不连续性差距。我需要 TVT 工程师进一步调查。

是否还有机会提供原始数据？您可以通过专有 E2E 对话发送。
[/报价]
附加的存档包含我在 E2E 上为另一个线程创建的示例应用、以及上面提到的 CSV 以及以下文件：

"nested_interrupts_r5fss0-0\Debug\core_trace_thon_crash_raW_TBR.bin"：我使用脚本控制台手动读取的 TBR 原始内容

"nested_interrupts_r5fss0-0\Debug\nested_interrupts_r5fss0-0.txt"：反汇编二进制文件

"nested_interrupts_r5fss0-0\Debug\core_trace_unto_crash_OpenCSD.txt"：处理原始 TBR 内容后的 OpenCSD 输出

如果您查看 CSV 中的第305132行("原始"CSV 或我的"注释"CSV)、并将以下行与反汇编进行比较、就很容易看到 TVT 输出可能不正确。

如果您对测试用例或我的任何文件还有任何疑问、请告诉我。

此致、

多米尼克

e2e.ti.com/.../nested_5F00_interrupts_5F00_r5fss0_2D00_0_2D00_trace.zip

0 admin 2 年多前

TI__Guru**** 2343840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

感谢您提供文件。我会将他们送到 CCS 跟踪工程师那里进行分析。

小标题

0 admin 2 年多前

TI__Guru**** 2343840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Unknown 说：
"nested_interrupts_r5fs0-0\Debug\core_trace_unto_crash.csv"：由 TVT 导出的 CSV、与 IDE Core 跟踪视图中显示的内容匹配

您是否也导出了*。TDF 文件？我在目录中没有看到它。该文件也会很有帮助。

Code Composer Studio™︎（参考译文帖）

Code Composer Studio™︎（参考译文帖）(Read Only)

[参考译文] CODECOMPOSER：AM64x R5f 上的内核跟踪解码问题