• 状态
  • 已锁定 已锁定
  • 个回复 7 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 72 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] LP-CC1352P7：CC1352P7导致 OAD 崩溃

admin
Guru**** 1807890 points
Other Parts Discussed in Thread: CC1352P7, UNIFLASH, SYSCONFIG
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1416607/lp-cc1352p7-oad-crash-with-cc1352p7

器件型号：LP-CC1352P7
主题中讨论的其他器件：CC1352P7、 UNIFLASH、 SysConfig

工具与软件：

大家好、我们正在处理从 CC1352P1到 CC1352P7的应用程序移植：CC1352P1 OAD 运行完美。 当我们对 CC1352P7进行同样的操作时、会出现一些问题：

-一旦发出复位命令以控制 BIM ,应用程序不再有效,并应通过处理器的物理重置将控制权传递给"持久"应用程序。 Persistent 应用与我们从 Resource Explorer 中下载的应用完全相同、仅更改用于驱动天线开关的 I/O 以及相对 CB、与我们在 CC1352P1上所做的完全相同。 这是非常容易检测持久性是运行由什么打印在串行通信:"TI 传感器(持久应用程序)". 然后在 OAD 状态行"Transfering Block 0 of 1041"上打印以下消息、进程在此停止。 也就是说、持久性完全不响应、无法通过通信本身采取任何行动。 注意、此状态消息指示：

-持久已在重置后调用

-持久性应用程序中的 OAD 流程已正确启动

除了此消息之外、所有内容都将崩溃。

在使用相同过程的 CC1352P1上、一切都正常运行：有什么进一步的区别吗？ 还是其他设置、以使 OAD 独立于底层处理器运行？

谢谢

路易吉

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

    路易吉您好！

    感谢您的咨询。 您可以提出以下问题来帮助我更好地理解该问题吗？

    1. 要从 CC1352P1迁移到 CC1352P7、您要执行哪些步骤？ 在 CC13x2x7或 CC26x2x7上运行软件示例。
    2. 您使用哪种设备作为中心设备？ 是否是运行 SimpleLink Connect 移动应用程序的手机？
    3. 您使用的 SDK 版本是什么？
    4. 您如何刷写 BIM、PERSISTENT 和应用二进制文件？ 如果您使用 UNIFLASH、您是否可以考虑附加一个屏幕截图、其中显示您用于二进制文件的地址？
    5. 您能否尝试使用 BTool 运行 OAD 过程？

    BR、

    David。

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

    尊敬的 David：

    以下是我的回复：

    1. 创建了名为 P7的新工作区(以实现干净的工作区)
    2. 导入了"传感器"示例
    3. 添加了从 P1相关工作区链接这些文件的所有自定义文件：特别是 sensor.c 添加了一些特定于我们工作的特性、但基本架构没有改变。 在任何情况下、这些特性都处于编译标志下、有助于在最终代码中避免使用这些特性
    4. 更改了 SysConfig 文件以使天线切换与我们的 HW 兼容、并 根据 相同的内容调整了 rfDriverCallbackAntennaSwitching 过程
    5. 我们正在使用 Linux 控制台发送 OAD 命令：请注意、所有这些步骤都能完美地与 P1处理器配合使用
    6. BIM 和持久已从资源浏览器添加、对于持久、我们更改了与前一点4相同的内容
    7. SDK = simplelink_cc13xx_cc26xx_sdk_7_41_00_17
    8. 所有三个二进制文件最初都加载了 Uniflash：检查随附的图片：请忽略用红色(ICE 板)包络的内容、因为我们仅使用该板的调试器、且拥有的处理器完全隔离：我们有一个自定义平面来将此 ICE 连接到我们的板

    我可以说的是下面我用冰追踪的流程:

    1. 当从 Linux shell 访问命令"w"时、应用程序会将一些连接数据保存到 NVRAM、这些数据用作持久性的共享内存、并使其代码失效
    2. 然后生成一个复位来将控制权交给 BIM
    3. BIM 验证应用程序不再一致、因此停止对持久性的控制
    4. 然后、PERSISTENT 读取连接数据并开始加入
    5. 加入后、OAD 过程可以开始、但在打印第一个 OAD 状态("传输1041的块0 ")后、它挂起
    6. 很难检查挂起发生在何处
    7. 显然、如果您重新启动板、BIM 会反复停止对 PERSISTENT 的控制、但此过程再次停止

    我们没有在应用中使用 BLE、

    希望这能有所帮助

    此致、路易吉

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

    尊敬的 David：

    从接下来的 pic、我可以争辩说

    1. 应用程序正确发出复位
    2. PERSISTENT 正确从 BIM 获得控制权
    3. 持久重新加入网络、以便从 TE 应用程序保存的数据保持一致
    4. OAD 过程已启动、但是

    持续挂起。

    希望这能有所帮助

    真诚的路易吉

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

    路易吉、您好！

    让我总结一下：

    1.您正在使用 TI 15.4-Stack sensor_oad_onchip_secure、 sensor_oad_onchip_persistent_secure 和 bim_onchip 示例。

    2.定制电路板上安装了 CC1352P7器件

    3.您使用的是 LP_CC1352P7_1版本的示例、唯一进行的代码更改是重新分配天线开关引脚。

    a)您是否可以发布传感器的监听器日志(运行持久应用)、以重新加入网络并直到挂起？ 这应该告诉我们停止 OAD 过程的是传感器还是 OAD 分配器。

    b)您可以在连接调试器的情况下执行此测试、并在器件挂起时暂停调试会话吗？ 这将告诉我们它是否实际挂起。 请发布呼叫堆栈的屏幕截图。

    谢谢、

    Marie H.

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

    尊敬的 Marie：

    在回答您的问题之前、请告诉我原来的 TI 项目本身并不能正常工作。 让我解释一下：

    1. 我开箱即用了新的 CC1352P7-1开发板：选中"附加的 pic "
    2. 使用 Uniflash、我在 从 Resource Explorer 加载并编译后刷写了 BIM、传感器和持久应用
    3. 我设置正确的 PANID 以连接电路板、就是这样
    4. 我尝试用我们的 Linux 控制台运行 OAD 会话
    5. 开发板 正确响应软件版本请求(命令"v")
    6. 电路板正确响应硬件版本请求(命令"b")
    7. 当我们尝试启动命令"w"(OAD 过程)时、出现在开发板中遇到的同样错误：开发板停转
    8. 然后、我通过 CCS 调试器加载并启动了用户传感器应用
    9. 相应的 COM 端口显示所有 UI 可能的操作
    10. 如前所述、我将 PANID 设置为能够识别我们网络中的该电路板并将其正确连接
    11. 从同一个 Linux 控制台,我启动了一个 OAD 会话,错误出现:从 Putty 没有什么工作了
    12. 因此,我决定尝试检测问题隐藏在持久性应用程序中的哪个地方,在调试器中重新加载它
    13. 连接开发板后、我在 OADClient_processEvent 条目中放入 BP 来 跟踪发生的情况
    14. 我将每条陈述都单步执行至392行、在那里调用了 SSF_setPollClock
    15. 再次越过(F6)会出现失速
    16. 暂停运行后、我发现代码在 Main_assertHandler 过程中停滞不前、 断言 Reason = MAIN_ASSERT_HWI_TIRTOS (4)
    17. 现在、我将使用 DEV 板重试此过程、以更深入地检查 SSF_setPollClock 中发生的情况、我将告知您

    现在我来回答你的问题：

    1. 有
    2. 有
    3. 有

    对于我来说、安装监听器是没有用处的、因为持久性应用程序中出现的问题似乎非常清楚。 请注意、无论是在 CC1352P1板上重复的相同过程还是在我们的定制硬件中、都不会发生这种情况

    希望这对您有所帮助

    此致、路易吉

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

    尊敬的 Mari：

    一个非常奇怪的事情反复发生:用户应用程序有时挂起后刚刚重新加入:它是否可能是一个堆栈错误的尺寸和随后的 RAM 损坏? 我会调查,让你知道

    谢谢路易吉

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

    路易吉、您好！

    对延迟响应深表歉意。

    由于您遇到硬件异常、我建议您 阅读调试指南中的以下部分：解密 CPU 异常：

    https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/ti154stack/html/ti154stack-guide/debugging-index.html#deciphering-cpu-exceptions

    谢谢、

    Marie H.