[参考译文] CC1310：当系统进入待机模式时、uLDO 出现故障

我忘记了提到、我们在仅连接了软件且未连接其他器件的情况下、就成功地在 LaunchPad 上复制了这种行为。  

科斯蒂安蒂

我们将仔细研究它、尽快返回给您。 请多多包涵。

BR、

成

您能否提供一个图来显示您在 D14上施加的信号？  

您能否提供有关第一个图和第二个图之间差异的更多详细信息？  

是第一幅图中 CH1显示的内容、还是在 DIO14上测量的第二幅图中 CH2显示的信号？

第一幅图上是发生器发出的信号、在 DIO14上测量。  

在第二个图中、CH2显示了我们在器件中注意到的在 DIO14上测量的实际信号。 该信号由另一个器件的 IO 引脚产生、在深度睡眠状态期间不应出现该信号。 但它可能会不时发生、不应影响操作。

您在 CH2上显示的信号会降至- 1V、这超出了芯片的绝对额定值。 因此、如果您看到的问题仅与 CH2信号有关或两者同时存在、这一点非常重要。

您写道、您能够在 LP 上重新创建问题。 如果您将该信号应用于任何 DIO 还是仅应用于 DIO14、会发生这种情况吗？  

我非常小心地用0 V 的纯方波再现了这个问题  
我已经在多个 Dios 上进行了测试、但 DIO14是我们的 FW 中唯一未使用的 Dios。 我们可以尝试以相同的方式设置另一个引脚、然后重新测试。

我们使用具有相同精确配置的 cc1310修订版 A 进行了重新测试、它绝不会失败。  
我们是否有可能使用某种带隙的酶？ 我希望所有 cc1310都能在此设置下失败、但只有 Rev B 失败。  

此外、空的 cc1310不会失败、休眠单元不会失败、使用数字 LDO 也不会失败。 只有具有 uLDO 和深度睡眠的非循环配置才会失败。

如果您可以提供一个我们可以在 Launchpad 上运行的示例并查看问题、这将非常有用。  

我不知道 rev A 和 B 之间有什么差异可以解释这一点。

当然、我可以向您发送私有二进制文件吗？  

是的、我接受了朋友的请求。 但我希望源代码能够看到正在发生的情况。  

这是否意味着您无法使用 TI-RTOS 对此进行三角测量、只能使用 Contiki 版本？  

我们从未使用过 TI-RTOS 进行过测试、因为我们从未使用过它。  

我们无法控制的一件事–为什么只有 uLDO、而不是数字 LDO 才会发生这种情况。  

另一个问题–假设我们在一段时间内具有-1V 尖峰的信号、uLDO 是否可能会永久损坏？ 以及 IO 引脚上的信号为何首先会对 uLDO 产生任何影响。

我认为问题与 uLDO 无关。 我怀疑32kHz xtal 为什么会停止。 然后、VDDR 将进入 VDDS (这将是致命的)或接地。  

您是否使用 Contiki NG 以及基于我们的驱动程序的版本或其他版本？ 我不熟悉 contiki、因此我想知道您是否能够使用 CC1310 SDK 中的一个示例对其进行分类。 我想看看这是否也与软件相关、或者它只是硬件使用问题。  

您是否能够在不使用32kHz xosc 但使用32kHz RCOSC 的情况下进行测试？ 如果这起作用、则与 xtal 相关。  

如果一个信号在 DIO 上变为-1V、则意味着 ESD 保护正在进行、并且电荷将被泵送到芯片的基板中、这会改变晶体管的行为。 32kHz xosc 以极低的功耗运行、实际上更改晶体管参数可能足以影响模块的驱动强度。  

您好、

我在 Kostiantyn 工作、但在软件方面。

> 您是否使用 Contiki NG 以及基于我们的驱动程序的版本或其他版本？  

我们仍在 Contiki 上使用 cc13xxware v2.04.03.17272 -但是深度睡眠(lpm.c/.h)应该与 NG 相同(我可以告诉它遵循 cc13xx TRM 中的示例)。

> 如果您不使用32kHz xosc 但使用32kHz RCOSC、是否能够进行测试？

我们可以、但可能需要一些时间来熟悉这些器件、以便正确操作。

关于发送给您的二进制文件、我认为主要部件是：

将 DIO 14设置为输入并被拉至低电平

2.节点进入待机模式30秒，快速唤醒，然后再次进入待机模式。

(3.在 DIO14上发送信号并观察故障)

您可能有一个 TI-RTOS 示例、可以轻松地修改该示例以匹配该示例吗？ (我认为待机模式的持续时间不是很短、因此并不重要)

我认为可以使用"空"示例。  

有关改用 RCOSC 的信息、请参阅 CCFG.c 或类似内容(不确定 contiki 中使用的内容)

我对此问题有一个小更新。  

我在发生器上犯了一个错误–它在错误的偏移上、脉冲的最有可能是负部分触发了这个问题。 但为了确保我已经重新测试了。 因此、如果没有过零、所有操作都正常。 脉冲从-1.25V 变为1.25V 时、器件进入睡眠状态时打开。 但是、如果我一直保持信号打开、并且在该器件进入睡眠状态后–一切都正常。 数字 LDO 也是如此–在任何情况下都不会触发任何问题。

此外、我们还有几个 cc1310、即使没有外部噪声源、也会发生故障、只需在待机模式下使用 uLDO 即可。 我相信 PowerPath 上的某个位置存在永久性损坏、但我不确定此时的位置。 是否猜到它仅使用 uLDO 失败的原因？

在我阅读您的上一篇文章时：在第一部分中、您会指出所有内容都是独立于测试方法工作的。 在第二部分中、您写的是无论采用何种测试方法、它都失败了？

如果我读取正确、为什么同一测试有两个完全不同的结果？  

我必须重新测试所有状态、以确保我们在这里看到的情况。

 对于所有情况、CC1310将进入深度睡眠模式

深度睡眠的电源配置：内部 DCDC 用于为 VDDR 供电、在该模式下使用 uLDO。  

测试1：当 MCU 处于深度睡眠状态时、方波信号、具有0偏移的2.5Vpp (从-1.25变为1.25V)被施加到 GPIO14。 结果：DCDC_SW 变为0、32kHz 晶振消失。 MCU 需要外部复位才能再次运行。

-测试2： 当  MCU 处于深度睡眠状态时、方波信号、具有1.25V 偏移(从0变为2.25V)的2.5Vpp 应用于 GPIO14。 结果：一切正常、MCU 按预期退出深度睡眠。

深度睡眠的电源配置：内部 DCDC 用于为 VDDR 供电、数字 LDO 用于此模式。  

测试1：当 MCU 处于深度睡眠状态时、方波信号、具有0偏移的2.5Vpp (从-1.25变为1.25V)被施加到 GPIO14。 结果： 一切正常、MCU 按预期退出深度睡眠。

-测试2： 当  MCU 处于深度睡眠状态时、方波信号、具有1.25V 偏移(从0变为2.25V)的2.5Vpp 应用于 GPIO14。 结果：一切正常、MCU 按预期退出深度睡眠。

！注：对全局 LDO 而不是内部 DCDC 稳压器执行了相同的测试，结果相同。

这些结果已在具有相同软件(使用 TI 驱动程序的 contiki 操作系统)的定制硬件和 Launchpad 上复制

我们已在一组定制电路板上执行下一组测试、我们认为这些电路板已永久损坏。

深度睡眠的电源配置：内部 DCDC 用于为 VDDR 供电、在该模式下使用 uLDO。  

- TEST：运行之前测试中的代码、而不向 GPIO14施加任何外部信号。 结果： DCDC_SW 变为0、32kHz 晶振消失。 MCU 需要外部复位才能再次运行。

深度睡眠的电源配置：内部 DCDC 用于为 VDDR 供电、数字 LDO 用于此模式。  

- TEST：运行之前测试中的代码、而不向 GPIO14施加任何外部信号。 结果： 一切正常、MCU 按预期退出深度睡眠。

我们对所有失败测试都做了重要的观察。 在我们的定制板上、我们有一个 WD 计时器 tpl5010。 它设置为~150s。 当 cc1310失败时、该时间将翻倍。 成功运行时、配置计时器工作正常。 不在 MCU 上运行任何代码也是如此–WD 工作正常。

由于它在允许的限制范围内与输入信号一起工作、我们是否需要评论更多？  

对于第二个测试、 据我所知、您认为损坏的电路板所承受的电压超出了芯片的绝对最大额定值、可能会损坏芯片的部件、因此我不想在此花费时间、因为这不在数据表中。  

最好了解问题的根源。

您是否有任何建议、我们可以如何在现场的单位中缓解这种情况？ 可能是可以保护系统的引脚配置？

我认为-2.5V 是一个纯实验室问题。 是否可以在现场以低于0V 的电压暴露引脚？  

遗憾的是–是的。 我们刚刚发现、我们使用的调制解调器具有一种奇怪的上电行为、在这种行为下、它会突发相对较长的脉冲包。

文档中从未提到过此问题、我们在测试过程中出于某种原因未发现此问题。  

请注意–revA cc1310器件根本不会出现此问题、这很奇怪、只有 revB cc1310。