[参考译文] CC2640：调试无法开始

您好 Luigi ,感谢您与我们联系详细说明。  

问题的根本原因是 SDK/器件不匹配。 您导入的“project_zero“工程来自“simplelink_cc2640r2_sdk_5_30_00_03“、但您的硬件是 CC2642R1F、该器件系列完全不同。 只需更改目标处理器或链接器文件就不会纠正您的问题。  CC2640R2 SDK 中包含的预构建 BLE 栈二进制文件专为 CC2640R2 编译、与 CC2642R1 不兼容。 这就是情况 1 失败的原因、因为二进制文件尝试刷写到错误的存储器布局。 至于第 2 种情况、会出现链接器文件冲突、因为您将 CC2642 链接器与 CC2640R2 SDK 混合、在预构建的堆栈库中包含自己的嵌入式链接器引用。

正确解决问题的方法是迁移到与 CC2642R1 兼容的 SDK。 您需要为器件使用正确的 SDK：
1) 下载并安装支持 CC2642R1 的 SimpleLink CC13xx/CC26xx SDK
2) 从新 SDK（不是 CC2640R2 SDK）导入“project_zero“示例、在 CCS 中转到：

File→Import→SimpleLink SDK→BLE5→PROJECT_ZERO→CC2642R1F

在 CCS 工程属性中、将目标器件设置为 CC2642R1F。 这现在与 SDK 二进制文件保持一致。 请勿在 CC2640R2 SDK 和 CC2642R1 SDK 之间混合项目文件、链接器文件或堆栈库。  

请告诉我这是否能解决您的问题 Luigi。 有一个伟大的星期一！

尊敬的 Mopel：

是 您建议的跑步。 但另一个问题出现:在 main () 条目中,根本没有清除的 ram。 因此、当代码到达以下函数时：

void HEAPMGR_INIT (void)
｛
heapmgrHdr_t *tmp;

if (heapInitialize == 1)
｛
//初始化已完成。 仅允许初始化一次。
返回；
}

它会立即返回、然后处理器进入发出此诊断的状态：“Cortex_M4_0：错误：(ERROR –1170 @ 0x0) 无法访问 DAP“

原始 project_zero 在同一点也会出现相同的行为。  我认为缺少一个链接器命令来清除所使用的整个 RAM 段、否则我不知道如何继续

注意 ：我在 AssertHandler () 条目上放置了一个 BP、但处理器永远不会在这里停止：每次我执行 iCall_registerApp(&selfentity, &syncEvent);语句时、行为就是我上面描述的：进入、控制到达 HEAPMGR_init、我认为存在问题

我真的疯了,明白为什么会发生这种情况。 可以帮帮我吗？ 谢谢 Luigi

您好 Luigi、

很高兴 SDK 迁移解决了以前的问题！ 您遇到的新问题是 RAM 初始化问题、特别是
.bss 段（保存零初始化的全局/静态变量、如 heapInitialize）在输入 main () 之前不会被清零。 这是链接器/启动配置问题。 我将为您提供问题的一些背景信息、然后我将解释您可以用来解决问题的一些行动方案。  

在 Cortex-M 器件上、C 运行时启动代码（通常在 startup_*.c 或复位处理程序中）负责将.bss 段归零（启动时未初始化的全局变量/静态变量必须为 0）并将.data 段从闪存复制到 RAM。 如果没有发生这种情况、诸如 heapInitialize 之类的变量会保留上一次运行或下电上电时产生的垃圾值、导致 HEAPMGR_INIT () 完全跳过初始化、并使堆处于中断状态、然后使系统崩溃。

现在您已经了解了问题的背景、我希望您首先尝试以下潜在的解决方案：

1) 检查链接器命令文件 (.cmd)、并 确保链接器文件正确定义了.bss 段并且该段正确放置在 RAM 中。 在 CC2642R1 工程中、打开.cmd 文件并验证您是否看到如下代码部分：
 

.bss : {} > SRAM

此外、请 SRAM  MEMORY {} 使用正确的 CC2642R1 基地址和大小确认块中定义正确。

2) 通过检查 startup_cc26x2_ccs.c（或等效文件）文件来验证启动/复位处理程序。 复位处理程序必须对.bss 进行零初始化。 寻找循环、如下所示：

// Zero-fill the .bss segment
uint32_t *bs = (uint32_t *)&__bss_start__;
uint32_t *be = (uint32_t *)&__bss_end__;
while (bs < be) {
*bs++ = 0;
}

如果此循环丢失或符号定义不正确、.bss 将不会被清除。 确保您使用的是 CC2642R1 SDK 随附的启动文件（而不是 CC2640R2 工程附带的启动文件）。 <-我实际上认为这可能是您问题的原因。

3) 确认您在 CCS 中使用的是正确的 Startup 文件。 在 CCS 中、转至：Project Properties→Build→Linker→File Search Path 确保链接的启动文件为：startup_cc26x2_ccs.c（来自 CC13xx/CC26xx SimpleLink SDK、而不是 CC2640R2 型号）。

尝试这些潜在的解决方案后、请向我更新您的项目状态。 我希望上述信息有所帮助。 如果您有更多问题、请再次联系 Luigi。  

尊敬的 Mopel：

我拍了一些屏幕截图,对我来说有一些非常奇怪的事情。 注意这两个应用程序都有相同的行为：原始 project_zero、以及我从中迁移的内容、称为 move：您可以在 每个 pic 上看到它
如您所见、我对两个应用程序执行了相同的操作：

• pic #1：
• 将 BP 放在_c_int00 条目处
• 运行的代码最高可达_TI_auto_init()；
• 检查 heapInitialize 中的值（它应该是一个随机值）
• 步进一次以到达以下语句_args_main ()
• pic #2：
• heapInitialize 预加载了值 1：我认为这是由于链接器映射而导致的错误
• pic #3：
• 运行代码直至 ICallHeapInit ()
• 检查 heapInitialize:根据:static hmU8_t heapInitialize=0 的声明、它应该为 0；
• 而是为 1、从此处开始、代码可能会在出现 “Cortex_M4_0：ERROR：(ERROR –1170 @ 0x0) 无法访问 DAP“时挂起、并且调试器无法完全失去控制
•  对 project_zero 应用程序验证了相同的行为：实际上、要派生移动应用程序、我只需导入 project_zero 并更改了其名称：因此两者之间没有变化、行为与预期相同

现在我想问为什么 heapInitialize 预加载了 1：此变量似乎是从错误的段加载的、但这是链接器作业：链接器命令文件是 原始导入的文件、那么为什么这种行为？ 如何解决？ 我是否要重新定义一些链接器命令？

正在等待您的帮助

路易吉

尊敬的 Mopel：

让我补充一些信息。
请在附加 pic 的帮助下检查以下各项：

• 我只处理原始 project_zero
• 在_c_int00 () 中的第一个条目上放置一个 BP、以跟踪电路板复位的流程
• 将 BP 置于 HEAPMGR_INIT 的第一个条目上 ()
• 自由运行 (F8)
• 它停在 HEAPMGR_INIT ()、这是令人惊讶的：我预计这个函数是从 main () 调用的、其中有一个显式 iCall_init ()；
• 堆栈调用可 按以下方式进行跟踪：  
• c_int00 ()
• _TI_auto_init_nobinit_nopinit ()
• _TI_auto_init_template ()
• TI_SYSBIOS_RUNTIME_Startup_exec ()
• BIOS_INIT ()
• TI_SYSBIOS_堆 叠_HeapCallback_init ()
• osalHeapInitFxn ()
• iCall_heapInit ()
• 所以这个函数是在 iCall_init () 之前在 main () 中调用的,这就是为什么在随后的调用 heapInitialize 中为 1
• 下一步、我们到达 ProjectZero_init ()、它在 project_zero 任务内调用：此时发生了一些事情、因此下一个语句 (iCall_registerApp (&selfent,&syncEvent) 失败
• 单步进入 iCall_registerApp,调试器在第一个语句 Ia Call_Task Entry *taskentry = iCall_newtask (Task_self()) 丢失;
• 一旦在 iCall_registerApp (&selfentity、&syncEvent) 停止、使用装配步进调试器似乎可以正确执行、购买它就会在执行语句 iCall_enterCSImpl () 时停止工作；

这是我的意见在达到这一指示之前发生的事情。 有什么想法吗？

真诚的路易吉

您好 Luigi、  

您使用的是定制电路板是的吗？  考虑到这一点,我希望你能做一些事情,这样我就能更熟悉我们系统和你系统之间的三角洲。 首先、我希望您转至.syscfg 文件、然后点击彼此分开的两个箭头。 然后、点击蓝色标识“Use Custom Board“。

接下来我要让您做的是、在.syscfg 配置面板上、选择“TI Devices“类别下的“Device Configuration“选项卡。 在标题为“低频时钟源“的行中、请选择与您在电路板上的设置最匹配的参数。  

我有一些资源进一步说明了如何将定制电路板与我们的软件配合使用、请参阅以下链接、详细了解如何将定制硬件与我们的软件集成：

https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AORV2P9xKyaQCr.Dunw8Rg__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST   

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/docs/ble5stack/ble_user_guide/html/sysconfig/sysconfig-board.html#migrating-board-variant   

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_33_00_16/docs/ble5stack/ble_user_guide/html/cc13xx_cc26xx/custom-hardware-cc13xx_cc26xx.html#custom-hardware 

最后、请随时点击此链接提交您的定制电路板设计： https://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS 我们团队的工程师将查看您的设计、并帮助您解决可能由硬件设计引起的任何故障。  

尊敬的 Mopel：

我的定制设计实际上是原始 LaunchPad cc2642/2652 原理图的基本副本、但进行了一些不太重要的更改。 无论如何、为了避免任何问题、我需要在我的定制板（组装了 CC2642）上处理 Project_Zero。 我尝试了以下方法：

• 使用调试器,在 main() 中,我跳过了 iCall_createRemoteTasks() 的执行,因此不会再创建任务。
• 此时、系统中运行的唯一任务是具有 ProjectZero_taskFxn 任务函数的 ProjectZero。
• 显然没有可用的性能、但系统是稳定的：也就是说、调试器不再有问题、比如说 DAP 错误、我可以暂停处理器、恢复处理器、所有调试器功能都可用、没有问题
• 这使我认为系统中有一些不能正常运行的东西: iCall_createRemoteTasks () 将提供的是创建和运行系统进程,这是真正隐藏的用户 (Me),我认为这些是运行没有任何问题:这不是,所以我担心有什么东西我不知道,不能检查,这将阻止所有运行
• 因此,我的问题是:为什么 DAP 不再可用? 处理器 JTAG 外设是否未通电？ 谁正在为 JTAG 断电？ main() 中的第 1 条语句不允许电源管理器切断所有电源、因此我认为 JTAG 应该始终通电
• 我将示波器连接到 JTAG 信号：TCK 和 TMSC：当一切都正常运行并且没有出现问题时、这些信号与 pic #1 中的信号相似、在这里、与调试器的通信丢失、这些相同的信号与 pic #2 中的信号相同
• 对我来说、两者都是由 Launchpad TM4Cxxx USB 集线器/调试器控制器驱动的、但我无法理解为什么 在这种情况下 TMSC 线路似乎是高阻态
• 在 ProjectZero_init () 中有 以下注释：
• //********************************************************************************
  //在对 iCall_registerApp 进行该调用之前不能进行堆栈 API 调用
  //********************************************************************************
  //将当前线程注册为 iCall 调度程序应用程序
  //以便应用程序可以发送和接收消息。
   iCall_registerApp (&selfentity、&syncEvent)；
• 由于最后一个函数会导致（或清单）问题、我担心由于如前所述创建了运行时远程任务、这里可能会进行一些堆栈 API 调用
• 这是根据以下事实强制执行的：运行 ProjectZero_taskFxn 时、该调用是第 1 个调用
• 但此任务的优先级最低、因此很可能可以运行其他一些优先级较高的任务、问题是：这些任务是否提供堆栈 API 调用、而这可能会成为问题的根源？
• 不幸的是、根本没有为这些功能提供任何文件、我完全不知道问题的根源
• 我尝试 在 ProjectZero_createTask() 中移动 iCall_registerApp(&selfentity,&syncEvent)、即在 ProjectZero_taskFxn 第一次 运行之前：它完成时没有出现任何问题、但现在出现相同的问题（“Cortex_M4_0: error:(error –1170 @ 0x0) 无法访问 DAP。 重置器件、然后重试此操作。 如果错误仍然存在、请确认配置、对电路板进行下电上电、和/或尝试更可靠的 JTAG 设置（例如下 TCLK）。 (emulation package 9.12.0.00150 )“）被移动到 ProjectZero_init () 的第 1 条语句 中、该语句现已变为
• queue_construct (&appMsgQueue、NULL)；
• 这让我有理由关闭 JTAG 外设
  
  

我完全不知道,所以请帮助我

等待一些支持,真诚,路易吉

您好 Luigi、

我已经将您的 E2E 帖子与原始 E2E 主题合并、我的想法是、您在尝试回复时遇到的任何障碍都是临时流程、现在这些流程已经解决。

我不熟悉 Launchpad TM4Cxxx 调试器 、并担心 SimpleLink F2 CC13XX/CC26XX 器件无法完全支持该调试器。  您之前提到过 XDS110 的使用、它们是相同的吗？ 很明显、您能够对器件进行编程、但在调试会话期间运行器件时还会出现其他问题。  JTAG 线路中可能存在导致通信问题的缺陷、我想请您确认这些线路的长度尽可能短。

不过、 project_zero 旨在与 BIM 应用程序一起运行以进行 OAD 操作、并需要连接到外部闪存。  这在我链接的自述文件以及 BLE OAD SLA 中有进一步说明。  这意味着、您也许能够通过 CCS 调试器启动应用、但随后的重新启动或下电上电会导致固件无法启动。  鉴于您当前遇到的问题、我建议从 basic_ble 甚至是无 BLE 的 TI 驱动程序示例（例如空或 pwmled2）开始 、以确认您的硬件能够运行 CC26X2R 固件。   如果您尚未选择将 API 包含在定制 PCB 中、最好选择“Use Custom Board“、使 API 不会纳入控制前面提到的外部闪存的启动过程中。

此致、
Ryan

您好、Ryan、

感谢您的支持。
开放式问题：
1) 我可以确认、JTAG 线路不仅尽可能短、而且在用于将 Launchpad 连接到我的目标的探头上、还针对“相对传播延迟“进行了补偿、布线长度差< 20mil、相移< 0.088ns（这是因为我专门设计了该探头是非侵入式的）。 我发送给您的信号图片直接取自目标处理器的引脚、在我看来没有问题。
2) JTAG 故障在代码的特定状态下发生：它尝试通过 iCall_registerApp（TI 开发工具 SimpleLink 中提供的函数）注册应用时。 在我看来、使用调试器命令 F6 “单步执行“一个函数、下面有一些运行的东西会产生一些问题、并且 JTAG 最终未通电（我猜是这样，但我无法证明，因为在此之后所有这些都变得无法正常工作）。 因此、为了尝试检测故障点的原因、我尝试了不同的测试：
a) 在 iCall_registerApp () 的条目放置一个 key = iCall_enterCSImpl ();语句,在执行之后放置一个 BP :这样,我就创建了一个 iCall_registerApp () 过程的原子行为来检查它的作用:这样调试器通常处于活动状态,完全没有问题,所有该过程都是初始化一些结构。 这极大地强制我认为在执行“步过“调试器的命令期间运行了一些导致挂起的代码。 但哪种代码？ 我不知道、我认为堆栈或库代码、但这个实验足够清晰。 所以我把 iCall_leaveCSImpl（键）;调用结束刚刚描述的原子行为。 会发生什么情况呢？ 尝试“单步执行“下一条指令（即 Queue_Construct (&appMsgQueue、NULL) 时会出现相同的信号问题；调试器错误“Cortex_M4_0：Error：(error –1170 @ 0x0) Unable to access the DAP“被再次发出、调试器已死机。 我真的不知道该怎么想、最后一个想法是：CC2642 库与安装在开发板上的 CC2652 是否有一些不同、这种差异导致了这个问题？ 我不知道接下来该怎么想。
请注意、我已将完整的硬件设计交付给地址 (connectivity-24ghz-hw-review@list.ti.com)、Mopel 向我发出信号、我正在等待回复。 无论如何,我相信不会有任何问题报告,因为一切都运行良好,当它运行,但我真的介意这种挂起的原因。 我完全坚持,没有更多的想法怎么做。 此外、文档对我没有帮助、但我将再次阅读。 我会尝试你的建议
谢谢、帮帮我

下面是 BLE-Stack 调试指南 、了解它的价值。

运行良好、但我真的很介意这种挂起的原因

您的应用在运行时是否正常工作？  因此、当您逐步执行代码时、您只关注调试期间的 JTAG 断开问题？  确认您正在 为 SDK 使用正确的依赖项。  您可以从 CC2652R1F.ccxml 文件中修改 JTAG 频率、以防有所帮助。  逐步执行 iCall 任务不是典型的或建议的。  您是否尝试过简单地运行 BLE 应用任务？

此致、
Ryan