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.
工具与软件:
大家好、我们正在处理从 CC1352P1到 CC1352P7的应用程序移植:CC1352P1 OAD 运行完美。 当我们对 CC1352P7进行同样的操作时、会出现一些问题:
-一旦发出复位命令以控制 BIM ,应用程序不再有效,并应通过处理器的物理重置将控制权传递给"持久"应用程序。 Persistent 应用与我们从 Resource Explorer 中下载的应用完全相同、仅更改用于驱动天线开关的 I/O 以及相对 CB、与我们在 CC1352P1上所做的完全相同。 这是非常容易检测持久性是运行由什么打印在串行通信:"TI 传感器(持久应用程序)". 然后在 OAD 状态行"Transfering Block 0 of 1041"上打印以下消息、进程在此停止。 也就是说、持久性完全不响应、无法通过通信本身采取任何行动。 注意、此状态消息指示:
-持久已在重置后调用
-持久性应用程序中的 OAD 流程已正确启动
除了此消息之外、所有内容都将崩溃。
在使用相同过程的 CC1352P1上、一切都正常运行:有什么进一步的区别吗? 还是其他设置、以使 OAD 独立于底层处理器运行?
谢谢
路易吉
路易吉您好!
感谢您的咨询。 您可以提出以下问题来帮助我更好地理解该问题吗?
BR、
David。
尊敬的 David:
以下是我的回复:
我可以说的是下面我用冰追踪的流程:
我们没有在应用中使用 BLE、
希望这能有所帮助
此致、路易吉
尊敬的 David:
从接下来的 pic、我可以争辩说
持续挂起。
希望这能有所帮助
真诚的路易吉
路易吉、您好!
让我总结一下:
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.
尊敬的 Marie:
在回答您的问题之前、请告诉我原来的 TI 项目本身并不能正常工作。 让我解释一下:
现在我来回答你的问题:
对于我来说、安装监听器是没有用处的、因为持久性应用程序中出现的问题似乎非常清楚。 请注意、无论是在 CC1352P1板上重复的相同过程还是在我们的定制硬件中、都不会发生这种情况
希望这对您有所帮助
此致、路易吉
尊敬的 Mari:
一个非常奇怪的事情反复发生:用户应用程序有时挂起后刚刚重新加入:它是否可能是一个堆栈错误的尺寸和随后的 RAM 损坏? 我会调查,让你知道
谢谢路易吉
路易吉、您好!
对延迟响应深表歉意。
由于您遇到硬件异常、我建议您 阅读调试指南中的以下部分:解密 CPU 异常:
谢谢、
Marie H.