[参考译文] CC1352P7：从 CC1352P7到 ADP5350 PMIC 的 I2C 读取命令被 NACKed。

admin

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

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1209376/cc1352p7-i2c-read-commands-from-cc1352p7-to-adp5350-pmic-being-nacked

器件型号：CC1352P7

您好！

我不确定这是否是发表这项质询的正确论坛。我在这里看到的问题不一定是由 MCU 引起的。我的问题是、检查其他任何人是否看到 CC1352P7RGZ MCU 或其他类似模型具有相同的行为。

我在一块电路板中通过 CC1352P7RGZ MCU 配置 ADP5350 PMIC。我看到了两个问题。

从 MCU 到 PMIC 的第一条(读取或写入)命令始终为 NACKed。在本例中、写入的内容应设置 PMIC 产生的电压。当 WRITE 命令消失时、PMIC 会锁定芯片地址和寄存器地址。逻辑捕捉显示这两个值都是正确的。同样的捕获显示、该请求中要写入寄存器的数据不是放在线路上。我假设这是因为 I2C 外设在收到请求的地址部分的 NACK 后停止工作。下面的屏幕截图显示了写入操作。蓝色阴影区域突出显示了黑色。如果再次写入相同的请求、则传输将顺利进行。

第二个问题是每个读取请求的最后一个字节被 NACKed。如果读取请求涉及单个字节、则该字节为 NACK。对于每个读取请求、PMIC 返回的数据都是正确的。下面的屏幕截图显示了一个寄存器的写入/读取序列、其中涉及两个字节。写入0x1C08后不会出现任何问题。返回0x1C08、但最后一个字节为 NACK。这会导致 I2C_transferTimeout() SimpleLink API 返回故障，尽管读取数据正确。

有人见过类似的行为吗？感谢任何帮助。

此致、

保罗

2 年多前

0 admin 2 年多前

TI__Guru**** 2393005 points

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

您好、Paul、

如果降低 I2C 总线的速度、会发生同样的情况吗？

我提出的问题是、因为模拟波形好像在信号路径中有一些电容

此致、

Arthur

0 admin 2 年多前

TI__Guru**** 2393005 points

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

您好、Adam、

感谢您的答复。在上面的屏幕截图中捕获的运行期间、时钟设置为400kHz。我将速度降低到了100 kHz。正如预期的那样、信号更干净、但通过 I2C 总线发送的第一个请求仍为 NACK。但是,我认为我发现了这个请求被拒绝的原因。

在与 PMIC 进行任何通信之前，根据需要调用 I2C_Open ()。该调用会导致高/低/高序列、并可在第一次事务之前看到。我可以非常肯定地说、序列会被识别为启动条件(逻辑探头使用了绿色标记)。但是、没有 STOP 条件。当实际事务开始时、会被另一个启动条件标记。此时、PMIC 被前一个序列弄混淆、并对这第一个事务进行 NACK。之后是一个停止条件(棕色标记)、它可能将所有内容"重置"为"干净"状态。一切都是从那里运作的。 I2C_Open()生成这样一个脉冲有什么原因吗？

这是该序列和第一个事务的屏幕截图。 SDA 脉冲在 SCL 脉冲前领先约4.7usec。