[参考译文] CC1352R：15.4 Stack OAD 片上在2.4GHz 频带上不工作。

您好、Matias、

此配置似乎没有已知问题。   

请再次执行这些步骤、并告知我们问题是否仍然存在、  

https://dev.ti.com/tirex/explore/node?node=AB3Gk81Kv0do0GCwtD9kEQ__BSEc4rl__LATEST

此致、

SID

您好、Sid、感谢您的回答。

我遵循了您提供的 SLA 模块中的步骤。 但是、我进行了一些修改、因为我要测试 OAD 片上处理、而不是片外处理。 我已经使用低于1GHz 进行了测试、该过程顺利完成。

当我使用2.4GHz 频段时、问题出现。 持久映像必须重新加入协处理器时、传感器停止响应。  传感器器件使用(BIM 片上十六进制文件、传感器 OAD 片上持久性2.4GHz 安全图像十六进制文件和传感器 OAD 片上2.4GHz 安全 bin 文件)进行编程。

我还尝试仅使用 BIM (片上)和蠕动图像对传感器进行编程、以使 BIM 从持久性图像引导、结果是相同的。 当传感器加入协处理器时、它停止响应来自串行接口的命令、并且不处理来自协处理器的任何命令(即使用"t"命令切换 LED)。

此致、

Matias

您好、Matias、  

我们正在尝试重现您在最后看到的内容。我们很快会回来。

此致、

SID

您好、Matias、

我想我可能已经复制了您看到的问题。

我看到、器件加入网络后不久、持续的2.4GHz 应用程序就会在 Main_assertHandler 中结束。 您是否能够验证这也是您身边发生的情况？

谢谢、
尼古拉伊

Nikolaj、您好！  

感谢您花时间研究此问题。

我可以确认 、器件加入网络后不久、持续的2.4GHz 应用程序就会在 Main_assertHandler 中结束。 调用此处理程序函数时、断言原因代码为 MAIN_ASSERT_MAC。

此致、

Matias

您好、Matias、

这只是一个状态更新、我还没有为您提供答案。

我将通过仅将 BIM 映像和持久应用映像(而不是用户应用程序映像)加载 到 器件来重现此问题。

这是我目前所了解/认为的：

OAD 客户端正在向未初始化的 OAD 服务器地址发送复位响应。

OADProtocol_sendOadResetRsp (在 OAD_protocol.c 中)在 OADClient_processEvent (在 OAD_client.c 中)中调用 、其中未  初始化参数 oadServerAddr。 这将导致 Mac 调用 assertHandler (因为该消息将是请求 ACK 的广播消息、无法完成)。

oadServerAddr 由于 非易失性存储器未初始化、因此似乎未使用。

我需要确定发生这种情况的原因以及预期的行为。  


感谢您的耐心、
尼古拉伊

Nikolaj、您好！

感谢您的响应并 关注 此问题。

如果此测试用例有任何更新/更正措施、请随时向我发布。

此致、

Matias

Nikolaj、您好、希望您做得好。

我只是想检查是否有任何有关此问题的更新、

提前感谢、

Matias

您好、Matias、

很抱歉耽误您的时间和缺少更新。

我无法确定问题的原因。 我已经联系了一些专家，他们应该能够帮助我们。

同时、您能否验证我在上一篇文章中描述的问题也是您看到的问题。 即、调用  OADProtocol_sendOadResetRsp 时使用的地址未初始化(全为零)

我已经针对低于1GHz 测试了相同的设置(仅限 bim 映像+持久映像)、我可以确认在这种情况下地址也未初始化、但栈以不同的方式处理它、这不会导致您看到的问题。

感谢您的耐心等待、

尼古拉伊

Nikolaj、您好、我在设置上验证了您在帖子中描述的内容。

一旦传感器加入收集器网络，OADProtocol_sendOadResetRsp()就会在 OADClient_processEvent()中调用。 此时 、oadServerAddr 变量中的所有字段都设置为零(未初始化)。

我还可以确认您描述的低于1GHz 案例行为(仅限生物映像+持久性映像)与我在本地设置中观察到的行为相同

此致、

Matias

您好、Matias、

感谢您的反馈、这对于调试您的问题非常有用。 我们仍在调查此问题。

感谢您的耐心等待、
尼古拉伊

Nikolaj、您好！

感谢您的回答。 我已经尝试了您建议的解决方法。 现在、传感器在加入网络时不会挂断。 但是、不执行 OAD 片上(我会说甚至不启动)。

传感器从持久应用程序映像发送 OAD 复位响应后、无法从新映像获取块。 它发出一个'OADProtocol_sendOadImgBlockReq'命令请求块#0但没有成功。 这在 OAD 进程被中止前发生四次不同的情况。

引起我注意的是、持久应用程序期望将新应用程序映像分为1536个块、而 Linux 处理器则显示"传输块1为768 "、这恰好是传感器预期块的一半。

您能否确认您是否遇到了相同的行为？

提前感谢、

Matias

您好、Matias、

这不是我看到的行为。 我能够成功完成 OAD 流程。 我使用 的是 SimpleLink CC13xx CC26xx SDK v6.10.00.29中的以下示例

传感器：

• sensor_oad_onchip_2_4g_secure_CC1352P_2_LAUNCHXL_tirtos7_ccs (具有先前 帖子中描述的修改版 Sensor_sendMsg ()))
• sensor_oad_onchip_persistent_2_4g_SECURE_CC1352P_2_LAUNCHXL_tirtos7_ccs (如 先前帖子中所述、具有修改的 Sensor_sendMsg ()))
• BIM_ONCHIP_CC1352P_2_LAUNCHXL_nortos_CCS ("调试"配置、而不是"调试不安全"配置)

我使用 Uniflash (具有以下设置)对传感器器件进行编程。

协处理器：

• CC1352P_2_LAUNCHXL_tirtos7_ccs

Linux (TI 15-4-Stack 网关 Linux SDK v4.40.00.03)：

• /prebuilt/bin/host_collector_2_4g  prebuilt/bin/collector-2_4g.cfg

请注意、我使用的是 CC1352P (因此是 CC1352P_2_LAUNCHXL 示例)、而不是 CC1352R、但差异不应成为问题。

您能否确认您的设置与我类似？

谢谢、
尼古拉伊