[参考译文] CCS/LAUNCHXL-CC1310：DSLite LOAD IMAGE.OUT 置位&quot；在引导时暂停；标志导致应用程序在手动复位或关机后再运行

Michael、

如果我查看 CC1310使用的 GEL 初始化文件、如果调试器尚未连接到电路板、它看起来就像在启动时显式执行电路板复位。  您可以尝试注释掉该行

文件是 ccsv7/ccs_base/emulation/gel 中的 cc26x0.gel

启动(int major、int minor、int patch)

｛

  /*初始化内存映射*/

  memorymap_init()；

  /*调试器特定处理*/

  if (GEL_MatchesConnection ("../TIXDS.*")=1)

  ｛

    GEL_LoadGel ("$(GEL_file_dir)/cc26xx_connect_util.gel")；

    GEL_LoadGel ("$(GEL_file_dir)/cc26x0_Xds.gel")；

    定义复位(0)；

    //发出电路板复位以确保器件处于已知状态

    //注意：如果要附加到正在运行的目标而不重置

    //   设备，您必须注释掉以下4行：

    if (！GEL_isconnected ()))(如果(！GEL_isconnected

    ｛

      GEL_AdvancedReset ("电路板复位")；

    ｝

  ｝

  否则 if (GEL_MatchesConnection ("../JLink.*")=1)

  ｛

    GEL_LoadGel ("$(GEL_file_dir)/cc26xx_jlink.gel")；

  ｝

  其他

  ｛

    GEL_TextOut ("错误：未知调试器。\n");

    返回；

  ｝

｝

类似地、在 cc26x0.gel 中、我看到在加载程序之前会发出电路板复位命令。  这也许可以。

此致、

John

我在很长时间之前(2月)评论了这一行内容、因此我可以将调试器连接到运行/崩溃代码、而不会在执行此操作时透露所有可用的调试信息。

Michael、

我正在与其他一些在该器件上具有专业知识的人员联系、以提供帮助。

John

Michael、

我想让你知道，我们没有忘记这一点，仍然在努力为你提供一些帮助。

此致、
John

我能够从某人处获得以下信息：

• 我认为他们可能启用了看门狗，同时芯片已复位，或者由于其他原因切换了复位线路+ tck。
• 我将查看 TCK、TMS、RESET 的逻辑分析仪跟踪
• 在任何情况下、您卡在该地址的唯一原因是、如果在 TCK 切换之后或同时进行引脚复位、 或者、如果在调试系统和 HiB 被激活时只有一个内部系统复位/假引脚复位/看门狗复位。

他们还提供了一些信息、说明如何与运行的26xx 建立连接、这对于 cc13xx 应该是相同的。  BTW 您是否仍在使用 CCSv7.1或是否更改为7.2？  很明显、在7.2版中、26x0和13x0的 GEL 文件合并、因此您需要将该 GEL 文件 tweak 应用于 cc26x0.gel 文件。

我们没有使用看门狗、因为它看起来很糟糕。

我们在 LAUNCHXL 板上使用 XDS110调试器、它是否会发出您描述的信号模式？

我正在使用 CCS7.1.0.00016、我没有意识到有新的更新、因为 CCS 的"检查更新"显示"在可用的软件站点中找不到更新"。

PS：如何在该屏幕截图中为0x1000区域设置符号？ 几个月以来、我一直在要求提供准确的信息、但没有结果

嗯、至少我可以帮助处理符号部分、因为有人向我展示了这一点。

转到 SDK 的安装文件夹。 然后在/source/ti/devices <name of device 下
/source/ti/devices/cc13x0/rom/driverlib.elf
该文件夹中还有一个 c 文件和一个自述文件。 自述文件作为使源关联正常工作的提示。

driverlib.elf 位于哪个软件包/下载位置？ 我的 CCS+tirtos+CC13xx/CC26xx driverlib 安装中没有该文件。

我拥有的最接近的命名文件是 tirtos_cc13xx_cc26xx_2_21_00_06/products/cc13xxware_2_04_03_17272/driverlib/bin/ccs/driverlib.lib、它似乎是 driverlib 函数的 NOROM (闪存内)版本

它附带 SimpleLink cc13x0 SDK

您好、Michael、

关于：

[引用 USER="Michael Moon "]今天我确认了在 DSLite 加载 image.out 后确实发生了标题行为，应用程序不运行，附加调试器显示它在地址0x10003A12[/quot]上死锁

您报告说、升级到 CCSv7.2.0有助于解决类似的问题：

https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/609640/2253134#2253134

只需在此主题中与您联系、看看此问题是否也得到了解决。

谢谢

Ki

此问题仍然存在。

如果我调用 SysCtrlSystemReset 或触发看门狗超时、我的项目看起来会死锁、而不是复位