• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 232 视图
  • 用户 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.

[参考译文] CC2630：ROM 引导加载程序有时不会自动检测 ACK 波特率

admin
Guru**** 2540720 points
Other Parts Discussed in Thread: CC2630

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/750848/cc2630-rom-bootloader-sometimes-not-ack-ing-baud-rate-automatic-detection

器件型号：CC2630

我们正在运行基于 CC2630的设计、该设计启用了引导加载程序后门功能。 它通过基于 FTDI 的电缆连接到 PC。

在正常情况下、PC 软件会通过对微控制器执行"ping"操作来初始化通信、该微控制器的顺序为三个字节0x03、0x00、0x00、这三个字节被微控制器正确忽略(因为尚未执行波特率检测)。 接下来、在等待约450ms 后、PC 发送必要的0x55、0x55 (两个字节)序列、用于自动波特率检测。 微控制器通过常规0x00、0xCC 序列进行确认、然后 PC 知道微控制器处于活动状态、并开始请求 ID 和大量其他内容。

但是、在某些情况下、微控制器不会 ACK 自动波特率检测。 这种情况并非总是发生的、但当发生这种情况时、始终是在新加电后发生的。

在这种情况下、PC 对0x03、0x00、0x00执行 ping 操作、等待450ms、然后发送0x55、0x55。 微控制器忽略此情况、PC 应用程序停止、并发送一条消息、表明它无法与微控制器通信。 如果我们随后再次运行 PC 应用程序(不进行循环通电或重置 micro)、PC 会 ping 0x03、0x00、0x00、而 micro (意外的) ACK 会使用0x00、0xCC 序列进行此操作。 我认为这表明在 PC 应用程序的上一次运行期间、先前的自动波特率检测尝试成功、但微控制器只是 dd、而不是当时的 ACK。 不管怎样、在第二次运行时、PC 非常高兴收到此 ACK 至其初始 ping、它跳过0x55、0x55序列(因为不再需要此序列)、并继续成功请求 ID 和其余通信。

是否有什么想法会导致这种行为？ 我已经监视了 VDDS、VDDR、RESET 和 DIO2 (我们的 BL_PIN_NO)上的波形、在这种情况发生时以及在上电后第一次尝试通信时、这些波形看起来是相同的。

此致、

克里斯蒂安

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

    您能否提供波形截屏以进一步强调您的观点？ MCU 上电和 PC 操作之间存在多长时间的延迟、更改此延迟是否会对行为产生任何影响？

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

    您好！

    从 MCU 上电到 PC 操作的延迟时间长短无关紧要。 可能需要很多秒、我之前所描述的这种情况偶尔也会发生。 我不确定是什么使 MCU 以这种方式运行。 我可以看到工作序列和非工作序列之间的加电波形没有实际差异。 我在下面包括了 UART 通信逻辑分析仪捕捉的屏幕截图和上电波形的示波器图(适用于工作序列和非工作序列)。

    DIO2是我们的 BL_PIN_NO、由于示波器输入阻抗的影响(与该引脚上的1MEG 外部上拉至 VDDS 相结合)、它在初始摆动至 VDDS 后稳定下降至大约2.9V。 我们还在 UART_RX 引脚上有一个外部1MEG 上拉电阻器。

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

    今天我做了更多的调查、似乎在加电大约500ms 后、FTDI 线缆决定在 UART_RX 线上扔一些垃圾(注意 UART_RX 是指微型的 RX 线)。 这在启动 PC 软件之前发生(我们不能早于启动 PC 软件、因为我们需要手动与键盘交互才能启动它)。

    奇怪的是、在工作场景中、垃圾似乎由几个半向脉冲组成、在非工作场景中、仅由一个半向脉冲组成。 这些脉冲与微控制器的正常/异常行为之间的关系是非常确定的(也就是说、当我们获得多个垃圾脉冲时、微控制器始终执行正常预期序列、从第一次尝试开始 ACK 0x55 0x55序列； 当我们得到单个垃圾脉冲时、微控制器需要第二次运行 PC 软件来进行 ACK。 UART_RX 是下面示波器图中的紫色布线。

    我现在有点困惑、因为这几个垃圾脉冲应该更糟、但似乎使微控制器的行为正常...

         

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

    可能 UART_RX 线上的这种垃圾会干扰通信建立、在这种情况下、必须发送一些虚拟字节以某种方式复位接口。 默认情况下、发送虚拟数据以解决该问题是否会有任何危害？ 我正在尝试在硬件团队中进行循环、以进一步评论。

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

    您好、Ryan、

    感谢您的回复。 公平地说，我认为现在是结束这一主题的时候了，没有任何进一步的辩论了。 很明显、微控制器内没有什么问题、这种行为实际上是由 UART_RX 信号垃圾造成的。

    正如我之前所说的、甚至不是 FTDI 线缆产生这种情况、而是 FTDI 线缆和微控制器本身的 UART 线之间的一个所谓"完美"的电路(我们继承的电路)、其目的是在 FTDI 和微控制器之间提供某种"隔离"。 总之、该电路远非完美、它实际上使用了书中的一些"请勿做"的内容(例如、使用运算放大器作为比较器、有时会起作用、但在本例中不起作用；或者忽略某些双向缓冲器的指定加电序列)。 因此、我们可以更改此电路或接受必要的 PC 应用程序重新运行(并感谢至少这样做！)。

    此致、

    克里斯蒂安