[参考译文] MSP430F5529：在将 MCLK 设置为32MHz 后、使用 I2C 模块读取数据

我非常确定 F5529仅限于25MHz [参考数据表(SLAS590P)第8.3"Fsystem"]节、您在25MHz 时会看到此行为吗？

您的从设备是什么？ 它是否可能拒绝寄存器编号0x00的原因？

您好 Bruce、  

感谢您的答复。

1.关于 MCLK、我测试了 MCLK 输出、它实际上是我设置的值(32MHz)、根据当前测试、MCLK 可以超出规格。 由于该系统中的其他功能要求、MCLK 不能降低到25MHz。 (您认为这个问题可能是因为 MCLK 过高？)

2.关于从器件,我用一个 PMBus 器件测试这个过程,这个器件不支持哪个命令代码是0x00的命令页面,所以它用 NAK 回复

最好的注意、

ZJY

TI [明智地、我认为]没有具体说明如果您在超出其规格的情况下运行器件会发生什么情况。

也就是说：根据您描述的内容、这种 I2C 行为似乎并不意外。 我不确定您的问题是什么。

您好 Bruce、

在我看来、当我收到 NAK 回复时、我需要立即停止 I2C、就像我在中断代码中所写的那样。 也就是说、主代码应返回、并且不会再发送读取-启动信号。

但确切地说、I2C 流程如下所示、即使我收到了 NAK 回复、它也会一直发送读取启动信号、这也不是我预期的行为。

我想知道为什么会发生这种情况。 我的主代码有什么问题、可能是因为高 MCLK？

顺便说一下、当我尝试逐步运行代码时。 我发现 MCU 运行中断代码所花费的时间晚于"UCB1CTL1 |= UCTXSTT；"。 这是因为 MCLK 过高、使代码操作比硬件响应更快吗？

关于 MCLK、我仍然很困惑。 如果我将 MCLK 源更改为外部晶体、并根据内部 PLL 使用频率更高的晶体、则可以通过25MHz 使 MCLK 非常高。 但根据规格规定、MCLK 应低于25MHz、这个限制来自哪里？ 功能模块(如计时器/ ADC 等)响应限制(如硬件设置中断标志需要时间或其他时间)？

此致、

ZJY

顺便说一下、我已经进行了测试、当 MCLK 降到8MHz 时、仍然会出现这个问题

尊敬的 ZJY：

在数据表中、我们将 fsystem (MCLK)限制为25MHz：

此外、对 I2C 时钟的限制与 MCLK 相同：

限制来自微控制器设计。 我们不能保证规格超出范围。

Unknown 说：

我想确定为什么会发生这种情况。 我的主代码是否有任何问题、或者可能是因为高 MCLK？

我怀疑的是,从 salve 的 NAK 答复比你处理 NAK 检查晚。

如果您正在处理以下数据传输、则在发生 NAK 的位置将丢弃 TXBUF。

当您处理下一个 重新启动信号时、似乎没有丢弃该信号的硬件机制。 因此、我建议您在下一次重新启动信号之前添加一些细节、看看它是否可以正常工作。

B.R.

Sal

[萨尔所说的,只有更具体的:]

如果您查看用户指南(SLAU208Q)图38-12 (顶行)中的流程图、第二次 TXIFG 设置为1时会出现在发送第一个数据字节之前、因此早在收到 NACK (针对该字节)之前。 这是因为 TXBUF 是保持寄存器、在其内容传输到移位寄存器时会变为空、而不是移出完成时。

插入延迟以允许移出数据字节(正如 Sal 所建议的)是可行的、但可能很难校准。

您的奴隶是否需要重复启动[大多数情况下不需要]？ 我怀疑如果您明确地在写入和读取事务之间停止、则在  停止完成之前会触发任何 NACKIFG。

[编辑：更正了拼写错误]

尊敬的 Sal：  

感谢您的答复。 我尝试在下一次重启之前增加一些延迟。 它需要非常长的延迟时间(比 I2C 频率长)。 尽管该延迟修复了错误的情况、但在正常情况下会导致意外现象(在 No8 SCL 和 No9 SCL 之间增加了延迟时间)、如下所示

我添加的代码延迟如下所示

在我看来、增加延迟时间可能不是一个好主意！

最好的注意、

ZJY

您好 Bruce、

谢谢你的答复,这是非常具体的。

因为我想使用 I2C 模块实现 PMBus 通信。 然而、在 PMBus 规范中、它规定在 Re 启动信号之前不应有 STOP 信号。 所以我无法添加 STOP 来触发 NACKIFG。

此致、

ZJY

USCI 没有给出表示一个字节已移出(并已进行确认)的显式指示器。

您可能会在 UCSCLLOW 中得到一些用途[Ref UG Sec 38.3.5.1]、因为移出完成后、时钟将延展(如果 UCTXIFG = 1)。 由于所有该位都表明 SCL 为低电平、因此您仍然需要校准(猜测)什么是"长时间"、但这将基于 I2C 位时间、因此时间要短得多(也略不是任意时间)。

我没有 PMBus 规范(我不是应用程序)、但我想知道(？) 如果在写入传输中发送 ByteCount=0、则写入传输是合法的。 如果是这样、您可以将其作为第二个字节(满足第二个 TXIFG=1)发送、然后观察第三个 TXIFG=1。 如果您在第一个字节上获得 ACK、它将发送0x00字节、但这是良性的。

您好 Bruce、

我知道你的意思,以上问题发生时,重新开始前的最后一个字节接收 NAK 应答。 您的意思可能是希望再发送一个字节来触发 NAKIFG。 也许这不是一个好主意。

此致、

ZJY

您好 Bruce、

我已经进行了测试。

由于 MCLK 为32MHz、当前 I2C 频率为100kHz、因此我添加83us 延迟(9 SCL)以确保收到 NAK 应答。  

但在正常情况下、No8和 No9 SCL 之间仍然会增加大约17us 的延迟(与 I2C 规范相比、还有7us 的延迟)、如下所示。

我还试图设置延迟时间短得多(82us ), NAK 回复将不会被检查,并去发送重新启动信号。 因此、该电路板的延时时间为83us (由于 No8和 No9 SCL 之间额外的7us 延迟、该延时时间设置也不是很好)并且没有容差。  

顺便说一下、如果我更换另一个电路板、由于 MCLK 的偏差、延迟时间可能会更改为另一个值。

有没有其他方法可以解决这个问题？

此致、

ZJY

我的想法已经用完了。 在将一个字节移出之前、您无法检查是否已对其进行了确认、 我不知道有任何 表明发生了这种情况的显式指示器。 所以 我只能想到的是(a)一个同步点(一个停止点或另一个 Tx 字节)或(b)一个延时时间(固定的或基于 UCSCLLOW)。

UCBBUSY 被定义为=1、从启动到停止[Ref UG 第38.3.2]节、因此没有任何帮助。  

---------------

TI 的 PMBus 库(此处)似乎没有什么特殊之处来处理无效命令的 NACK、因此它可能会遇到相同的情况。 我注意到：

1)没有任何示例(对于 TPS544C20)有意使用无效命令。

2)所有示例都启用 PEC；我想知道 PEC 字节最终是否满足与我所建议的 ByteCount=0字节相同的(同步点)用途。

您好 Bruce、

关于 PEC 字节、我使用 LM5066i (TI 支持 PEC 检查的 PMBus 器件)进行了测试。 当与 LM5066i 通信时、I2C 主器件可以选择是否发送 PEC 字节(在写入过程中)。 它不是一个必需的字节。 同时、在读取过程(例如读取过程)中、PEC 字节在回读数据结束时由从器件而不是主器件发送(在重新启动读取信号之后)、因此不能用作同步点。

此致、

ZJY

我会在这里指出,你显示的请求(使用无效命令)实际上失败了。 我想这是因为 交易被 Stop 分解成两个,但也许它与初始 NACK 有关。 但我 想 在这种情况下、无法(对于调用方)区分"无效命令"和更通用的"请求失败"。 也许这 对于 TI 库设计来说已经足够了。

我不能改变 MSP430 I2C 单元的工作方式、因此如果建议的解决办法(同步、延迟或忽略问题)都不符合您的项目要求、您可能需要考虑使用不同的 MCU。 MSPM0 (例如) I2C 单元处理传输/事务、而不是按字节工作、它会区分 SLA 字节 NACK 和数据字节 NACK、因此(我没有尝试过您的测试用例)它可以更好地满足您的需求。

或者论坛上的其他人可能有另一个建议?

尊敬的 ZJY：

Unknown 说：

我还尝试设置延迟时间更短(82us ), NAK 回复将不会被检查,并转到发送重新启动信号。 因此、该电路板的延时时间为83us (由于 No8和 No9 SCL 之间额外的7us 延迟、该延时时间设置也不是很好)并且没有容差。  [/报价]

是的、根据 UG 说的：

我现在没有其他想法、虽然我发现我们支持 MSP430的 PMBus、但您也许可以看看 它并了解它如何实现重复启动信号处理： MSP-PMBus 驱动程序或库|德州仪器 TI.com

B.R.

Sal