[参考译文] CC2340R5：引导加载程序收到意外响应

尊敬的禹文：

CC2340引导加载程序 CMD_DOWNLOAD cmd id 为0x26、请参阅技术参考手册第"8.5.3 ROM 串行引导加载程序命令"部分。

cmd ID 0x21为 CMD_GET_STATUS。

(请注意、CC26xx 和 CC23xx 之间的 ROM 引导加载程序存在差异)。

谢谢！
Toby

尊敬的先生：

感谢您提供这些信息。

我们是否可以修改引导加载程序的代码？ 或者在哪里可以检查 CC2340引导加载程序的确切代码流程？

谢谢。

BR、

Yuwen

否、无法实现、因为引导加载程序位于 ROM (只读存储器)中。

尽管我们不提供 ROM 源代码、但 TRM (技术参考手册)中详细介绍了引导加载程序功能。

很好、您已经有了与它连接的方法、因此请按照 TRM 中的命令详细信息来实现固件下载。
具体而言、本节将介绍"8.5.4引导加载程序固件更新示例"。

尊敬的先生：

在回顾引导加载程序的过程时、我们发现了一件奇怪的事情：

根据 TRM P470、我们看到了以下过程：

我们最初希望在发送 BLDR_CMD_GET_STATUS 后收到 ACK/NACK。

但是、在发送  BLDR_CMD_GET_STATUS 后、我们收到0x03 0x40 0x40、这似乎是 BLDR_CMD_RET_SUCCESS 值。

我们认为可能缺少一些东西。

1.您能帮助我们澄清这是引导加载程序的预期行为还是错误吗？

2.另外,我们可以看到以下描述:

发送器被允许发送零、直到接收到非零响应、这是 SPI 所必需的并被 UART 允许。 在准备好应答或否定应答正在发送的数据包前、接收器可以返回零。 在发送数据包后收到响应之前、两种器件都不传输非零字节。

这是否意味着我们在发送任何 CMD 后收到的每个0x00都可以忽略？

谢谢。

BR、

Yuwen

每条命令后都会返回 ACK。
然后收到 ACK 后使用 BLDR_CMD_GET_STATUS 来检查上一条命令的状态。

[报价 userid="562607" url="~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1402984/cc2340r5-receive-unexpected-response-on-bootloader/5374915 #5374915"]

另外、我们可以看到以下描述：

发送器被允许发送零、直到接收到非零响应、这是 SPI 所必需的并被 UART 允许。 在准备好应答或否定应答正在发送的数据包前、接收器可以返回零。 在发送数据包后收到响应之前、两种器件都不传输非零字节。

这是否意味着我们在发送任何 CMD 后收到的每个0x00都可以忽略？

[报价]

是的、基于这一点、SPI 主机可能会忽略这些零字节。

尊敬的先生：

每条命令后都会返回 ACK。
然后收到 ACK 后使用 BLDR_CMD_GET_STATUS 来检查上一条命令的状态。

我还是有点困惑。

我们预计在发送 BLDR_CMD_GET_STATUS 后会看到另一个 ACK/NACK。

但我们没有收到 BLDR_CMD_GET_STATUS 的任何 ACK/NACK。

我们会直接获得 ACK/NACK 以外的内容。

我们认为这是不正确的。

您能解释一下为什么会发生这种情况吗？

谢谢。

BR、

Yuwen

是的、您应该在每个命令后收到一个 ACK/NACK。。 您能否确认要发送的  BLDR_CMD_GET_STATUS CMD ID？ 是 0x21吗？

发送 BLDR_CMD_GET_STATUS 后、您从器件中看到什么值？

发生问题时、您能否提供通信线路的逻辑分析仪快照？ 还应在问题发生之前添加一些命令。

尊敬的先生：

1.能否确认要为 BLDR_CMD_GET_STATUS 发送的 CMD ID？ 是0x21吗？
->是的、我们已确认发送的地址正好是0x21。

2.发送 BLDR_CMD_GET_STATUS 后、您从该器件中看到什么值？
->我们满足两个条件:

a)我们直接收到0x03 0x40 0x40、前面没有0xCC 或0x33。

b)我们收到0xCC/0x33并等待了很长时间、但在 ACK/NACK 之后没有得到任何其他字节。

基于 TRM、以上所有情况都不正确。

请帮助我们澄清如何找出问题。

感谢您分享有关您的调查的更多详细信息。

我将在3个工作日内查看并提供更新。