[参考译文] CCS/LAUNCXL-CC1310：如何调试类似的内容？

它似乎在空闲线程上下文中出现故障，手动浏览堆栈并交叉检查符号表(CCS为什么不为我执行此操作？) 建议回溯如下所示：

my_fault_handler2 (空)
TI_SysBIOS_family_arm_m3_HWI_excHandler__I (空，0)
TI_SysBIOS_KNL_Idle_funclist__C
TI_SysBIOS_KNL_Task_schedule__i
TI_SysBIOS_family_arm_m3/hwi_dispatch __i
PowerCC26XX_StandbyPolicy
TI_SysBIOS_KNL_Idle_funclist__C
POWER_idleFunction
TI_SysBIOS_KNL_Idle_run__E
TI_SysBIOS_KNL_Idle_loop__E
TI_SysBIOS_KNL_Task_Exit__E

那么，TI-RTOS为什么会在空闲线程中崩溃？ 我甚至没有任何用户空闲功能...

奇怪的是，DFSR指向ti_uia_loggers_LoggerStopMode_Instance_State_0_HDR__A -1，MMAR指向ti_uia_loggers_LoggerStopMode_instance_0_packetArray__a，尽管我不知道其中任何一个符号的相关性，除了它们似乎与我目前没有使用的某种日志记录工具有关。

为什么他们的地址在这些寄存器中？ 根据数据表，DFSR不应该是地址，它所拥有的值不合法。 数据表中没有提到MMAR，但它可能实际上是MMFAR寄存器，它指向某种内存故障的位置。

R1-R9指向t0 ti_SysBIOS_family_arm_m3_Hwi_excHandlerAsm__i (0x1001c9fd)，R10指向ti_SysBIOS_Ffamily_arm_m3_Hwi_pendSV__i (0x1001ca3b)-不知道为什么这么多人指向同一个位置？

大多数其他寄存器看起来都是胡说八道...

有什么想法？ 甚至进一步的调试步骤或让CCS告诉我一些有用的信息也会很有帮助

Michael Moon 说：

CCS似乎无法提供任何类型的可用回溯，因此我不知道它实际崩溃的位置，除了“semaphore_pend启动的调用链中的某个位置”。

您使用的是GNU还是TI ARM编译器？

有一个未解决的错误，即在使用GNU ARM编译器时，从CCS 7.1 开始，堆栈回溯并不总是完整的-参见 CCS 6.2。当使用GNU编译器的Cortex-A15 SYS/BIOS程序由于错误或调用BIOS_EXIT()而终止时，0.0.005万 不显示完整的堆栈回溯。

我正在使用TI编译器。

我已将“步进期间中断”设置保留为与您描述的值相匹配的默认值；我将查看链接文章以了解更多信息。 但是，在我的情况下，故障发生在步进和运行时，所以我不认为这是我的问题。

图像

如果我手动编辑堆栈指针寄存器(SP)，我可以通过跳过CCS没有符号的函数来获得部分回溯，但我仍然非常困惑为什么它会在一开始就像这样崩溃。

此外，地址通常与函数不一致，函数参数通常看起来也很错误。

无论我走多远，所有函数调用似乎都深入到TI RTOS内核中，我无法确定实际问题是什么。

我从代码中输入的几个对象指针和内容似乎是完整的，尽管我从未完全确定它们中应该包含什么-关于这些内容的文档非常少，阅读源代码以找出问题相当累，因为经常有链 无方向函数和设置的东西和使用的东西之间的各种shenanigans。 在TI RTOS中，在函数之间传递的东西在很多情况下似乎都被破坏了，尽管我不知道这是如何发生的，也不知道为什么发生的。

例如，在上述截屏的HWI_dispatchC中，hwi显然应该是指向某个HWI_Object的指针，但指针地址是0x4008.1万 - IOCFG0寄存器的地址-为什么？

I2CCC26XX_hwiFxn显然需要一个指向I2C_handle的参数，但它只是传递中断号-为什么？

当写入Debug/output.map的符号表显示此地址在"ti_uia_loggers_LoggerStopMode_write1__E"函数中，而I2CCC26XX_hwiFxn显然未在地址或符号按符号分排的符号中列出时，CCS为什么会列出此地址？

简而言之，当CCS不能告诉我什么意思的时候，我怎么能找出真正的问题？

CCS为什么在将符号表写入Debug/output.map时，如果I2CCC26XX_hwifxn显示为0x6F6A，则CCS将该地址列在函数"ti_uia_loggers_LoggerStopMode_write1__E"中，而I2CCC26XX_hwiFxn显然不是按符号/符号排序的名称来排列的 CCS调试器使用的符号与 Debug/output.map文件的内容不匹配。

启动调试会话时，CCS是否将Debugg/output.out文件编程为闪存？

您能否查看CCS调试配置并发布项目的“程序”选项卡的图像，因为该图像应显示在启动调试会话时CCS将编程到闪存中的程序。

是的，当我更改代码时，主板的行为会按预期发生变化-除了所有这些看似随机的崩溃！

图像 -调试配置对我来说正常

我禁用了我的崩溃处理程序函数(我只在尝试首先调试这些错误时使用了它)，并打开了我可以找到的所有调试内容，但CCS仍然拒绝告诉我实际的问题是什么。

现在我的崩溃看起来像 图像，但这基本上是无用的。

如果我尝试在核心寄存器中编辑堆栈指针，以便在崩溃时向我显示报告的堆栈指针，则什么也不会发生-它甚至不会更新UI元素， 但是，如果我再次编辑它，它将显示我输入的值，直到我按Enter，此时它将恢复为旧值，不执行任何其他操作。

我尝试 了此处的说明 ，但没有结果- 图像 就是结果。 请注意，SP和LR仍显示旧值，因为CCS在我输入新值时忽略了我。 此外，我的符号表在0x1000xxxx范围内根本不包含任何内容，而且我找不到关于应该存在的内容的更多信息，因为CC1310 TRM似乎缺少正确的内存映射。

从这里可以看出，我的所有任务都在休眠-这种崩溃显然发生在TI-RTOS的空闲线程中！ 我没有添加任何自定义空闲功能，我只使用空闲作为内置节能功能。 另请注意，我的堆叠都没有溢出。

系统堆栈(0x2.0004万C00-0x20004FFF)中2.0004万中显示的各种地址是各种TI-RTOS内部组件，电源和时钟模块(根据符号表)。

如果不能随意更改堆栈指针，并且必须在符号表中手动查找每个地址，那么解释原始堆栈是一项相当艰巨的工作，即使我浏览了它，似乎也不会提供任何有用的信息。

最令人愤怒的是我会改变一些完全无害和不相关的东西，然后事情会突然正常工作一段时间，我可以完成一些实际的工作， 然后过了一会儿，我会直接回到这个地方，完全停顿下来，我会在随机换东西的过程中，直到代码在没有明显理由的情况下突然再次运行。 我非常擅长使用另一个嵌入式工具链(gcc/gdb)调试内容，但这种TI工具链根本不能提供我需要的信息，并且在TI-RTOS内部不断地指出。

感谢所有的帮助，因为在此阶段，我掌握的所有信息都表明，TI-RTOS本身正在崩溃，CCS调试视图和构建工具链之间似乎存在某种无法克服的中断，这使得发现其他方面的工作非常困难。

Michael Moony 说：

此外，我的符号表在0x1000xxxx范围内根本不包含任何内容， 我也找不到关于应该存在什么的信息，因为 CC1310 TRM似乎缺少正确的内存映射。

我找到了线程 CC1310内存的地址范围是什么？ 这说明CC1310具有以地址 0x1000万开头的128K字节ROM。

   TI 15.4 堆栈SDK用户指南的“在ROM符号中加载TI-RTOS”部分指出，ROM中的所有TI-RTOS内核代码均以地址0x1001xxxx开头，并显示如何在ROM中的TI-RTOS函数的CCS调试器中加载符号。

如果您在TI-RTOS安装中查找，则应该有 一个软件包\ti\SysBIOS\ROM\crtexm\cc13xx\goldi\CC13xx\RTOS_ROM.map链接器映射文件，其中列出了ROM中TI-RTOS内核代码中符号的地址。

在这里可以看到，我的所有任务都在休眠-这种崩溃显然发生在TI-RTOS的空闲线程中！

您的项目.cfg文件是否使用ROM模块 ti.SysBIOS.ROM.ROM， 如果是，您的应用程序代码是否使用ROM代码所使用的任何RAM或闪存区域？

线程 RTOS/CC1310：在闪存中的两个应用程序之间跳转 ，注意到ROM中的TI-RTOS代码在固定地址上需要一些RAM和闪存数据，如果应用程序尝试使用与ROM代码相同的RAM/闪存区域，大概会发生奇怪的崩溃。

谢谢切斯特

在尝试获取更多调试信息时，我从配置中删除了ti.SysBIOS.ROM (以进行堆栈检查，并至少尝试查看这些0x100xnnnn符号是什么)，但这似乎根本没有帮助-无论如何，情况显然仍在跳进ROM。

您链接的第二个线程显示：“两个项目的链接器命令文件将把ROM引用的BIOS对象放在所需的地址。” 由于我只尝试运行单个应用程序，链接程序应该为我执行此工作，没有问题，对吗？ 我的链接程序脚本是在我构建项目时所基于的empty_min示例中的默认脚本。

是否是TI-RTOS正在使用ROM调用，尽管我已经告诉它不使用，并且链接器未能为ROM代码保留内存，因为我已禁用它，从而导致了所有这些疯狂？

我看了一下那个RTOS_ROM.MAP文件，它很好奇-

为什么用户闪存中有一堆符号(0x0-0x2万)？ 如果相应的目标文件也包含它们，那么当我加载RTOS_ROM.xem3目标文件时，这是否会使我的调试程序混淆？

为什么0x1000nnnn范围内没有内容？ 这是我在暂停时经常发现代码旋转的地方(即使它看起来工作正常)，也是代码经常崩溃的地方。 内存映射显示这是ROM区域的一部分，但我找不到该区域的符号。

由于CCS似乎无法堆叠过去它无法识别的符号，因此调试非常困难。

为什么它在RAM中有0x2000.01万-0x20000600范围2000.06万范围之外的符号，而线程显示为ROM .BSS部分？ 当我加载RTOS_ROM.xem3目标文件时，这是否也会使我的调试器混淆？

0x1000nnnn范围内为何没有内容？ 这是我在暂停时经常发现代码旋转的地方(即使它看起来工作正常)，也是代码经常崩溃的地方。 内存映射显示这是ROM区域的一部分，但我找不到该区域的符号。

我认为 0x1000nnnn范围包括CC13xx 驱动程序库的ROM版本。

例如，查看rom.h的联机文档时，有两个宏 ROM_HAPI_TABLE ADDR 和 ROM_API_TABLE ，它们指向0x1000nnnn 范围内ROM函数上的表。

是否有办法为该区域输入CCS的某些符号？ 似乎在我尝试调试内容的大部分时间里，PC将进入此区域，CCS将完全丢失。 我可以单步完成，有时它会弹出到其他地方，有时它会返回到'正在运行'状态，即使我正在尝试步进

即使事情(相对)正常工作，CCS中的调试信息似乎有些混乱。

请参见 图像 示例-为什么我的(当前正在运行的)任务未在ROV任务查看器中列出？ "拆卸"视图中为什么有额外的符号？ 为什么堆栈指针明显指向未使用的堆栈空间？ 为什么在堆栈中看不到列出的任何一个函数地址？ (是的，我知道LSB地址如何奇怪地用于ARM皮质架构)

我想知道为什么这个任务在Task_sleep()调用时停止-这是在该Task_sleep调用上设置的断点的视图...

Michael，

您是否创建了IMU_Task？ 如果是，您是如何创建的？ [静态地在*。cfg文件中？ 动态使用Task_create()，或使用Task_construct ()?]

很长一段时间内，构建的任务线程不会显示在ROV中(我必须仔细检查是否仍然如此)。 如果使用Task_construct ()创建，这可能是它未显示在ROV中的原因。

Steve

Michael Moon 说：

在Disassembly (分解)视图中为什么有额外的符号？[/QUOT]如果您的意思是$C$CON670符号，则该名称的符号是编译器用于循环等内容的静态标签。 它们不会显示在地图文件中。

为什么堆栈指针明显指向未使用的堆栈空间？

从IMU_Task：Task_function (unsigned int) prologuue中，在堆栈上推送了9个寄存器，然后分配了0x94字节的堆栈空间。 如果当前SP是0x2000.056万，则表示在函数条目处，SP将是 0x2000.056万 + 9*4 + 0x94 = 0x2000.0618万，它横跨内存浏览器中显示的地址0x2000.06万处的符号ti_SysBIOS_KNL_Task_Instance_State_0_stack_A。

符号 ti_SysBIOS_KNL_Task_Instance_State_0_stack_A来自何处，不同任务的堆栈区域是否可能重叠导致损坏？

@Steven，

>您是否创建了IMU_Task？ 如果是，您是如何创建的？ [静态地在*。cfg文件中？ 动态使用Task_create()，或使用Task_construct ()?]

我使用的是Task_create和Task_construct的混合。

我需要一些任务的多个实例，但不包括静态实例化，除非我设置了多个静态缓冲区，这会阻止我在我只选择在运行时启动的特定任务子集的情况下削减内存使用量。

其他任务始终运行，因此我使用静态实例化来执行这些任务。 如果TI-RTOS限制我只使用一种创建任务的方法(这是我在文档中没有看到的限制)，我可以将它们翻转到动态并增加堆。

>很长一段时间内，构建的任务线程不会显示在ROV中(我必须仔细检查是否仍然如此)。 如果使用Task_construct ()创建，这可能是它未显示在ROV中的原因。

真的吗？ 哇，这是在某处记录的吗？ 该问题是否有时间安排？

有几次我可以在ReadyQ中找到我的一些任务，但没有找到其他视图，但目前它们似乎也在消失。

@切斯特

>如果您的意思是$C$CON670符号，则该名称的符号是编译器用于循环等内容的静态标注

我指的是ti_SysBIOS_family_arm_cc26xx_Timer_setNextTick__E_manked()

PC处于此符号之后，但回溯未将其显示为当前功能。

此外，它前面的反汇编表明它不属于此处- IMU_Task::Task_Function在它之前似乎没有任何类型的返回。

这看起来像是一个伪造的符号，可能来自RTOS_ROM.xem3，我显然需要添加它，以便在0x1001nnnn内存范围内调试这些内容。

也许我应该objcopy RTOS_ROM.xem3以只包含0x1001nnnn中的符号而使用它吗？

>符号ti_SysBIOS_KNL_Task_Instance_State_0_stack_A来自何处

可能在TI-RTOS内部。

>是否存在不同任务的堆栈区域重叠导致损坏的可能性？

仅当工具链的链接器严重损坏时。 我甚至不想对内存布局做任何幻想。

在删除malloc和free的所有使用后，我似乎遇到的崩溃大大减少，但下面有一个类似的崩溃，当我在尝试查找i2c_transfer为什么一段时间后不返回时，当我浏览我的代码时，出现了一个类似的崩溃：

(从ROV Hwi例外查看器)
解码异常，
已解码，未定义的Hwi：197
异常上下文，
$addr,0x0
$type，ti.SysBIOS.family.arm.m3.HWI.ExcContext
threadType，ti.SysBIOS.BIOS.ThreadType_Hwi
threadHandle,0xacf5.
threadStack，0x1001c9fd.
线程堆栈大小，2.68552701亿
r0，0x1001c9fd
r1，0x1001c9fd
r2，0x1001c9fd
r3，0x1001c9fd
r4，0x1001c9fd
r5，0x1001c9fd
r6，0x1001c9fd
r7，0x1001c9fd
r8，0x1001c9fd
r9，0x1001c9fd
r10，0x1001ca3b
r11，0xc335
r12，0xc500
SP，0x101c90f
LR，0x8500.75万
PC，0xd101cf0e
PSR，0xFFc6
icsr，0xa5c5
MMFSR，0x10a6cc61
BFSR，0x3f56c93
UFSR，0x290.0371万
hfsr，0x3.3119万f11
DFSR，0x802.0003万f
MMAR，0x32.0002万a
BFAR，0x5500.0333万
afsr，0x10df1404
异常调用栈，
0   <SYMBOL is not available >，PC = 0xD101CF0E FP = 0x0101C90F
解码异常，
已解码，未定义的Hwi：197
异常上下文，
$addr,0x0
$type，ti.SysBIOS.family.arm.m3.HWI.ExcContext
threadType，ti.SysBIOS.BIOS.ThreadType_Hwi
threadHandle,0xacf5.
threadStack，0x1001c9fd.
线程堆栈大小，2.68552701亿
r0，0x1001c9fd
r1，0x1001c9fd
r2，0x1001c9fd
r3，0x1001c9fd
r4，0x1001c9fd
r5，0x1001c9fd
r6，0x1001c9fd
r7，0x1001c9fd
r8，0x1001c9fd
r9，0x1001c9fd
r10，0x1001ca3b
r11，0xc335
r12，0xc500
SP，0x101c90f
LR，0x8500.75万
PC，0xd101cf0e
PSR，0xFFc6
icsr，0xa5c5
MMFSR，0x10a6cc61
BFSR，0x3f56c93
UFSR，0x290.0371万
hfsr，0x3.3119万f11
DFSR，0x802.0003万f
MMAR，0x32.0002万a
BFAR，0x5500.0333万
afsr，0x10df1404
异常调用栈，
0   <SYMBOL is not available >，PC = 0xD101CF0E FP = 0x0101C90F

调试这种情况令人发指，因为所有三个SP，PC，LR都远远超出了内存映射的有效区域，而TI-RTOS/CCS显然甚至不知道这是什么类型的异常。

0x1001C9FD是ti_SysBIOS_family_arm_m3_Hwi_excHandlerAsm__I()的地址，它似乎一点也不有用。

来自'Core Registers (核心寄存器)'的SP似乎正常，但CCS只能回溯几个函数，然后在0xFFFFFFFD上扼流，显然无法将其识别为异常描述符。

此外，CCS不允许我更新SP，LR，PC寄存器，因此我可以手动步过跟踪的该部分-我可以写入新值，但当我按Enter时，它会恢复到上一个值。

这需要我手动回退，因此：

SP -> 0x0.0001万   0x1001BBD9   0x2.0003万A3C   0xFFFFFFFD   0x400.9202万C   0x0.1378万   0xFFFFFFFF   0xFFFFFFFF 0xFFFFFFFF      0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF    
0xFFFFFFFF   0x00000000   0x1000万   0x0万   0x20003A3C   0x00006D6D   0x1001C93D   0x1001C950   0x4100万   0x0.0001万   0x0万   0x4008218C   0xF3BFFF3A
0x0.0006万D6D   0x0.0077万EF   0x000077EE   0x01000000   0x2.0003万A3C   0x0万   0x0.1378万   0xFFFFFFFF   0x0000C69B      0x2.0003万A3C   0x1001BD15   0x2.0003万A3C
0xFFFFFFFF   0xFFFFFFFF   0x1001C20D   0x2.0003万A3C   0x1001B425   0x0万   0x0万 0x0万 0x1001C207      0x1001B425   0x1001BE05   0xBEEBEBEBEBE (TI_SysBIOS_KNL_Task_Instance_0_stack_A结束)

0x1001BBD9是ti_SysBIOS_family_arm_m3_Hwi_excHandler__i()
0x2.0003万A3C是ti_SysBIOS_KNL_Task_Module_State_0_readyQ__A
0x0.1378万是(根据Debugg/configPkg/linker．cmd) ti_SysBIOS_KNL_Idle_funclist__C
0x0.0006万D6D是ti_uia_loggers_LoggerStopMode_write4__E
0x1001C93D位于ti_SysBIOS_family_arm_m3_Hwi_dischart__i()中
0x1001C950是"NVIC_icsr"
0x0.0077万EF在PowerCC26XX_standbyPolicy()内
0x000C69B位于Power_idleFunc内
0x1001BD15位于ti_SysBIOS_KNL_Idle_run__E内
0x1001C20D位于ti_SysBIOS_KNL_Idle_loop__E内
0x1001B425是ti_SysBIOS_KNL_Task_Exit__E，我认为它是任务函数返回的处理程序
0x1001C207是ti_SysBIOS_KNL_Idle_loop__E
0x1001BE05为ti_SysBIOS_KNL_Task_enter_I
0xBEBEBEBEBE是一个金丝雀值，启动程序似乎用它来填充内存。

值得注意的是，我没有添加我自己的任何闲置功能-这是100 % TI-RTOS内部组件。

据我所了解，这表明在TI-RTOS的空闲节电期间，它在空闲线程中抛出了某种硬件异常...

我猜可能CCS希望某些处理程序在某个位置填充结构，而不是在HW异常上直接检查堆栈，因此我将处理程序切换为默认处理程序。

现在，Hwi/Exception信息看起来更加合理，它表明PendSV在tirtos_cc13xx_cc26xx_2_21_00_06/products/bios_6_46_01_37/packages/ti/SysBIOS/family/arm/m3/hwi_ASM.sv7M:226处触发Pc，而不是在其试图执行IC_NVsr符号时，而是通过该代码。

为什么这可能是我完全不知道的-这是TI-RTOS内部的*deep*，我目前只想做一个简单的I2C_TRANSFORT()。

可能 是TI-RTOS 正在使用ROM调用，尽管我已经告诉它不使用，并且链接器未能为ROM代码保留内存，因为我已禁用它，从而导致了所有这些疯狂？

我目前没有CC1310， 但使用了具有相同ROM结构的LAUNCHXL-CC2650，以检查何时调用TI-RTOS ROM代码。 在CCS调试器中设置两个监视点，以检测从地址0x100.1万...处的TI-RTOS ROM代码读取的数据。 0x1001FFFF (一个监视点的最大范围是0x8000字节)：

设置这些监视点并注释.cfg文件中的ROM配置代码块时，监视点未被触发，从而确认未使用TI-RTOS ROM函数。

而当在.cfg文件中启用ROM配置时，则触发了监视点。

您是否可以尝试在项目上设置相同的监视点，这些监视点应已禁用TI-RTOS ROM并查看它们是否触发？

我目前正在从头开始重新安装CCS，因为在尝试更新到7.1 后，cfg查看器已完全显示信息，并且尽管cc13xxware在包含路径列表中并提供了该文件，但在尝试生成BIOS.o时，现在内部版本出现“Cannot find driverlib/sys_Ctrl.h”(找不到driverlib/sys_ctrl.h)。 我希望全新安装可以帮助解决这些不断出现的奇怪工具链故障。

这需要一段时间，CCS安装程序提供零进度指示，上次安装时，我整夜都没有安装，所以我不知道典型的安装时间是多少。 到目前为止，它已经持续了几个小时，没有给出何时完成的建议。