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.

[参考译文] CC3235MODASF:I2C 和 LPDS

Guru**** 2539500 points


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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/929610/cc3235modasf-i2c-and-lpds

器件型号:CC3235MODASF

您好!

我正在尝试将我们的项目之一从"使用休眠间歇性连接"切换到"始终使用 LPDS 连接"。  退出 LPDS 时、I2C 有一些问题。

LPDS 退出后的第一个 i2c 请求始终返回 I2C_STATUS_INCOMPLETE。 以下请求返回 I2C_STATUS_BUS_BUS_BUS_BUSY。

当使用示波 器查看信号时、我可以看到正在写入的地址和数据、但当相关读取发生时、SCL 保持低电平、并且我从 I2CMasterIntStatusEx 中获得意外的 I2C_MASTER_INT_STOP。

如果代码完全相同、并且在 LPDS 退出后添加了 i2c_close/i2c_open、则可以正常工作。

我可以在 I2CCC32XX.c 中看到 、I2CCC32XX_postNotify 函数在 LPDS 退出时正确地调用 I2CCC32XX_initHw。 但是、这似乎不足以正确复位 i2c 主器件。

我在阻塞模式下使用 i2c。

典型传输的设置如下:  

i2cTransaction.slaveAddress = I2C_ADDR_MSP;
i2cTransaction.writeBuf = txBuffer;
i2cTransaction.writeCount = 1;
i2cTransaction.readBuf = rxBuffer;
i2cTransaction.ReadCount = 4;

I2C_transferTimeout (i2c、事务、msec_TO_TICKs (500)); 

正常传输

NOK 传输

最新的 SDK 和服务包 simplelink_cc32xx_sdk_4_20_00_07

在相关的注释中、是否有充分的理由在停止条件下永远等待、而不是使用提供的超时?  (其中有注释:"如果从器件保持时钟线、这可能会永远阻止")

谢谢、

C é dric

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

    您好、Cedric、

    您的注释有效、在这种情况下、您能否在 TI 驱动程序中添加超时、以便在从器件保持时钟线时不会卡住?  

    从器件是否需要更多数据、或者您是否知道其仍被保留的原因?

    BR、

    Vince  

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

    尊敬的 Vince:

    当然、我可以添加超时、您是否还可以为下一个 SDK 版本规划相同的更改?

    不需要从器件不需要更多数据、它是 OK 和 NOK 情况之间完全相同的条件。 唯一的区别是 i2c_open/i2c_close (不影响 sda/scl 行)。

    我强烈假设是 cc 将 SCL 保持在低电平、这是因为检测到停止条件或 LPDS 退出后停止条件出现问题。  

    这是我获得的调试输出。 我们可以看到序列是相同的、不同之处在于在函数 I2CCC32XX_hwifxn 中 、intStatus 读取为1088 (0x440)而不是1024 (0x400)。 这意味着检测到一个停止条件。

    左= LPDS 之后的 NOK

    右=在 LPDS 之后正常

    是由于时间变化小吗? 或停止条件检测出现问题?  

    有什么关于如何进一步调试的想法吗?  

    在任何情况下、我都看不到从器件是如何产生差异的。

    谢谢、

    C é dric

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

    Cedric、

    您能否检查我们是读取数据的下降沿还是上升沿、并确保两个器件通信相同?

    此外、您的图片似乎没有显示出来。 您可以再尝试连接它吗?

    BR、

    Vince  

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

    尊敬的 Vince:

    这是左侧的图片、左侧检测到的停止时间太早、右侧的图片具有正确的顺序。 两者之间的唯一区别是、在执行请求之前、在右侧添加了 i2c_close/open。

    我们可以看到序列是相同的、不同之处在于在函数 I2CCC32XX_hwifxn 中 、intStatus 读取为1088 (0x440)而不是1024 (0x400)。 这意味着检测到一个停止条件。

    /cfs-file/__key/communityserver-discussions-components-files/968/2020_2D00_08_2D00_13-14_5F00_02_5F00_08_2D00_New-Text-Compare_5F00_-_2D00_-Text-Compare-_2D00_-Beyond-Compare.zip

    (我无法发布此图像... 所以这是一个拉链……)

    下面是交换的范围捕获。 (黄色= SCL、绿色= sda)

    最后一个时钟时的缩放。 我们可以看到、sda 在 SCL 下降后上升、因此不应将其检测为停止条件。

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

    您好、Cedric、

    是的、这看起来 I2C 外设在唤醒时未正确配置。 您能否验证、如果在 LPDS 之前调用 i2c close、在 LPDS 之后调用 i2c open、它是否按预期工作?

    我将向我们的内部研发团队报告这一情况、以便为将来的发布提供解决方案。

    这是否是您问题的可接受解决方案?

    BR、

    Vince  

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

    尊敬的 Vince:

    是的、当在 LPDS 之前关闭并且在 LPDS 之后打开时、也可以正常工作。  

    我只需要从主任务调用 i2c_open、通过 Power_registerNotify 的回调执行该操作时、我会得到一个堆栈溢出。

    感谢您将其报告给研发部门!  

    此时我将打开/关闭。

    此致、

    C é dric