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

[参考译文] MSP430F5308：MSP430F5308 i2c USCI 从器件发送时钟拉伸问题

admin
Guru**** 2344390 points
Other Parts Discussed in Thread: MSP430F5308
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/569401/msp430f5308-msp430f5308-i2c-usci-slave-transmit-clock-stretch-issue

器件型号：MSP430F5308

您好！  

主 控：MCP2221微芯片 USB 至 i2c 桥接器。  驱动程序是标准 MCP Linux 驱动程序。  100kHz i2c 总线速度。

从器件： MSP430F5308 @ 8MHz、使用 USCI 外设并略微修改了 TI 示例代码。

测试设备： 内置 i2c 总线分析仪的 LeCroy 示波器。  ArdvaarK/Beagle TotalPhase I2C 数据包分析器。  i2c 上拉电阻大约为2K、100kHz 时的边缘看起来很好很清晰、i2c 波形恰好超过0v、一直到3.3V。

问题： 当 MCP2221请求从机发送单个8字节数据包时、MCP2221不会生成 ACK 时钟、这会导致状态机在两侧中断。  速度100kHz I2C。  8MHz F5308时钟。  

分析： 经过全面的故障排除后、当 MSP430以8MHz 运行时、它需要8us 附近的一些器件来响应传入的7位地址+R/W、 然后、为了释放时钟(即我们认为430正在拉伸时钟)、当它释放时钟以供 MCP 启动 ACK 脉冲时、MCP2221不会正确响应、而不是发送 ACK、只是开始为数据字计时。  我们假设430需要8us 来处理"我的地址是否"并解释 R/W 位。

这只发生在从机发送上、而不是从机写入上。  当 MSP430的时钟速度增加到16或24MHz 时、MCP 会正确生成 ACK、一切工作正常。  在另一个也使用 USCI 的编程器代码中观察到一个情况、但在另一个 MSP430系列中、ACK 脉冲为正常的1/4 100 kHz 脉冲宽度、这表明我们加快了 MSP430时钟解决问题。  通过提高430代码速度并进一步证实时钟拉伸理论、这个代码也被固定(即、时钟脉冲返回到正常宽度)。  

我们在 MSP430上以更高的时钟速率运行了一些测试、如果时钟速度增加到8MHz 以上、例如16或24MHz、那么在大约与时钟速度增加成比例的时间延迟内释放时钟所需的时间似乎更少。  这可以实现更高的 i2c 速度、但对于 MCP2221不正确接受时钟拉伸、则是一种权变措施。

当然、我们正在与 Microchip 合作、以查看我们是否可以重新编程 MCP2221的驱动器、以便更好地利用时钟拉伸、但在平均时间内：

问题：  

1) 1)有什么想法、为什么我们看到的是从器件发送而不是从器件接收？

2) 2)是地址和 ACK 之间的往返延迟、具体取决于 MSP430上的纯时钟周期或我们正在处理的 RC/模拟/传播类型延迟。

3) 3)是否有一些我们缺少的设置或代码会使 MSP430不会在 R/W 位和 ACK 之间插入时钟拉伸延迟(即、我们能否加快430在 I2C 从器件发送 ACK 上释放总线所需的时间)？  

谢谢！  Blake

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

    该模块使用什么时钟(ACLCK/SMCLK/MCLK)、该模块设置为什么频率？ 即使 MCLK 为8MHz、也可以在32kHz 时关闭 ACLK。 您能否获取模块的设置代码？

    就从器件发送与接收的情况而言、我假设您使用重复启动切换到从器件发送。 如果是、您可能会遇到以下勘误表。 USCI35.
  • 0
    TI__Guru**** 2344390 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Jace：

    基本上、我们使用的内容与 示例代码设置例程非常接近：

     UCB1CTL1 |= UCSWRST；     //启用软件复位、禁用 P4

     UCB1CTL0 = UCMODE_3 | UCSYNC；   // I2C 从机、同步模式
     UCB1I2COA = SLAVE_I2C_ADDRESS；     
     UCB1CTL1 &=~UCSWRST；     //清除 SW 复位，恢复运行
     UCB1IE |= UCSTPIE | UCSTTIE | UCTXIE| UCRXIE；    //启用 STT、STP、TX、RX 中断                                  

    从系列手册的快速看、i2c 时钟 似乎由 UCBxCTL1寄存器中的 UCSSELx 选择、该寄存器默认为00、似乎表示 UCLK。   但是、我们在430上处于从模式、38.3.5提示： "在从模式下、不使用位时钟发生器、UCSSELx 位无关。"  如果您认为 UCSSELx 中的10b 会有所帮助(将时钟移至 SMCLK)、我可以在 UCSSELx 中设置10b、但它似乎不会用于从器件传输(我希望我错了、因为这将是一个超级容易解决的方法)。

    与 USCI35的问题相同、它看起来好像只处理我可以告诉的主模式(并且我们在从模式下运行)。

    感谢您的帮助！

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

    是的、您是对的、对于这个部件、USCI35只影响主控模式。 很抱歉造成混淆。 是的、在从模式下、您将由主器件计时、因此时钟设置无关紧要。 您是否为此使用了任何 LPM？ 可能是 LPM 唤醒时间会影响您这里的工作。
  • 0
    TI__Guru**** 2344390 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Jace：

    我们移除了所有 LPM 调用、因此处理器始终处于唤醒状态并全速运行。 内部处理器时钟是否为 i2c 状态机计时？ 如果是这样-似乎8us 需要很长时间才能解码"是我的地址"、并决定它是 R 还是 W。也许德国可以提供一些有关状态机如何运行的信息、因为我没有特别看到任何细节。
  • 0
    TI__Guru**** 2344390 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Blake、

    我对这里的8us 数字有点困惑、因为这是与100kHz I2C 通信时钟周期相同的时间。 现在、器件识别自身所需的时间可能取决于您的器件时钟速度。 请参阅下面的屏幕截图。 其中一个 MSP430F5529LP (相同的 USCI 模块和时钟系统)从器件以1MHz DCO 的频率发送、另一个以8MHz DCO 的频率发送。 (在100kHz 时钟下、I2C 线路上的一个周期为~9.5us。 @8MHz DCO、该时间稍微扩展至~12us、而在1MHz DCO 上、扩展至~60us。)

    [8MHz DCO ]

    [8MHz DCO ]

    [1MHz DCO ]

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

    很有趣 因此、基本而言、您看到的是从器件根据 DCO 时钟速度进行的 ACK 时钟扩展的线性缩放(无论如何都是如此)。 我们所看到的。 我们看到这个值在全部使用 USCI 的3个处理器之间略有不同。 我想这是正常行为。 奇怪的是、当主器件发送数据时、我们没有看到与从器件将数据发送回主器件时相同的拉伸时间。

    好消息是、我们启动了 Microchip 演示板、并在窗口下优雅地处理从器件传出的时钟。 在 Linux 下不会。 这指向 Linux 驱动程序配置问题。 我们正在寻求这方面的解决办法。

    所以我们应该能够解决眼前的问题，但我们一方仍然希望有某种程度的时间量化。 或许简单如下：

    @ 100kHz、1MHz = 60uS、8MHz = 12uS 等

    有什么想法为什么从读写的拉伸差异、我们应该去设计团队了解一些逻辑、或者尝试将其与我们的产品结合起来？
  • 0
    TI__Guru**** 2344390 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Jace：

    客户今天给我打了电话、问为什么读时钟延长、而不是写时钟延长？ 读取和写入似乎都必须执行相同的地址解码。 您会认为状态机由8MHz 时钟计时、与之匹配完全无需时间、而不是9.5uS。 您是否计划询问任何设计团队是否可以提供任何清晰信息？

    遗憾的是、MCP2221实际上是预编程的 PIC18、因此代码处于关闭限制状态、可配置性几乎为"无"。 我们计划更改几个 Linux 超时、但在这之后、我们就会变成吐司了。 如果我们能够排除加快状态机的速度、那将会是很好的。

    周末愉快！
  • 0
    TI__Guru**** 2344390 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    要关闭该线程、

    此线程中概述的相关性可在以下中进行描述。 从机读取实际上是向主机写入的从机。 如果从器件还没有准备好写入主器件、它将时钟拉伸行直到填充 Txbuff。 Txbuff 准备就绪后，会释放线路(并确认)，以便主器件在我获得确认后立即开始计时要读取的字节(从器件 TX)。 如果您在这里没有时钟拉伸、并且您可能无法从从从器件的 Txbuff 获取正确的数据。 因此，接收地址并不一定需要花费这么多时间，而是主控方读取的字节。