首次使用此部件。 我尝试写入配置端口以将所有 I/O 引脚设置为输出。 我首先发送器件 ACK 的 Start 序列。 然后、它还 ACK 命令字节(0x8C)。 但是、我随后用数据字节写入命令字节(在本例中为0x00、将端口0上的所有 I/O 设置为输出)。 它会将该数据包和所有后续写入操作置为 nack。 我缺少什么?
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.
约书亚、您好!
当您得到 NACK 时、您能否提供 SDA/SCL 的示波器截图?
您是否还有我们可以查看的原理图?
[引用 userid="489227" URL"~/support/switches-multiplexers-group/switches-multiplexers/f/switches-multiplexers-forum/1008423/tca6424a-device-is-nack-ing-config-data-via-i2c "]然后它还会确认命令字节(0x8C)[/quot]0x8C 不是器件中的寄存器、我希望它不起作用。 是否确定要发送0x8Ch?
谢谢、
-Bobby
尊敬的 Eric:
我在这里附加了 SCL 和 SDA 线路的示波器捕获。 不确定您是否希望我触发某个特定事件。
下面是一张图片、其中显示了我的原理图的相关部分。 我实际上使用两个 TCA6424A。 如您所见、一条线路连接高电平、另一条线路连接低电平。 这两个器件都表现出相同的行为:当发送起始序列时、它们将使用相应的地址进行 ACK 应答、并对命令字节0x8C 进行 ACK 应答。 但它们会否定在命令字节之后发送的任何数据。
约书亚、您好!
感谢您分享示波器截图。 基于这些、器件似乎正在确认发送的每个字节。 我已经标记了每个字节来显示其数据、并且每个字节中的第9位在相应的上升时钟边沿期间显示为低电平。 图示的快照看起来像是用 下面显示的一些数据写入配置2寄存器(地址0x0E)的 U6 (命令字节位0清零用于写入、位1设置用于 ADDR =高电平)。 当接收器件将 SDA 线路驱动为低电平时、该事务中的所有 ACK 位看起来都是0。
由于这与您的初始报告不一致、此问题可能只偶尔发生、您使用的控制器对 ACK 的解释不正确、或者探测位置和任一接收设备之间出现了其他一些电气问题。 是否有方法准确识别控制器何时报告 NACK? 这是否在每次交易的软件中出现、或者只是偶尔出现? 有时、我们可能需要做一些额外的工作来捕获不良的通信帧。 大多数示波器都可以在 I2C 等简单通信协议中分析逻辑。 是否可以配置您的范围以识别此数据并在感知的 NACK 上触发?
此致、
Eric Schott
Eric、
很抱歉、此示波器捕获的命令字节为0x0E、正如您所注意到的、而不是我之前提到的0x8C。 我认为自动递增功能可能是问题、所以尝试不使用它。 无论如何、这种模式非常一致:Start 会收到 ACK、Command 会收到 ACK、但之后的数据包不会收到 ACK。 只需确认:将所有线路配置为输出的正确序列应该是在开始和命令字节后对数据= 0x00进行三次写入、对吧? 我没有看到不同的结果、每次都是一样的、这让我相信问题不是噪音/电气问题、而是发送数据时我做了一些错误。
因此、只要确认一下、如果我发送:
启动序列
命令字节0x0E
0x00
0x00
0x00
这应将所有引脚设置为输出、对吧?
约书亚、您好!
要对所有输出的全部三个配置端口进行编程、地址字节应包含0x8C、以便最初写入配置端口0、并允许随后自动递增到端口1和2。 对于输出配置、以下3个数据字节应该包含0x00。
请注意、自动递增可能会导致寄存器地址无效、这可能是报告的 nack 的来源。 如果使用非自动递增地址、则任何超过1个的数据字节都将继续覆盖同一寄存器。 为了在不自动递增的情况下执行此操作、可以相应地使用0x0C、0x0D 和0x0E 的地址字节发送三个单独的序列。
您是否能够捕获 NACK 数据字节的示波器截图?
此致、
Eric Schott
约书亚、您好!
该示波器屏幕截图似乎还包含每9个时钟脉冲上的 ACK。 但是、我不确定这里的序列是正确的。 每次手动输入新地址时、都需要使用起始条件和器件地址启动新的 I2C 事务。 在同一事务中、您无法手动输入新的寄存器地址。
对这些寄存器的手动递增写入应如下所示:
(开始) (0x44)- (0x0C)- (0x00)- (开始) (0x44)- (0x0D)- (0x00)- (开始) (0x44)- (0x0E)- (0x00)。
此致、
Eric Schott
约书亚、您好!
对于大多数器件、由于 SDA 线上的电压似乎没有超过高电平输入阈值、因此我怀疑 ACK 的时序会导致问题。 SDA 上的探测点和控制器之间更有可能存在一个。 在扩展器和控制器之间是否可能有单向缓冲器或转换器可防止数据反向传输? 请尝试在尽可能靠近接收器件的位置探测系统、以确保波形代表在输入端看到的波形。
如果这不是电气问题、可能与控制器器件中 I2C 驱动器的配置有关。 这可能超出了我的支持范围、但我可以帮助解答可能与 I2C 标准相关的具体问题或详细说明您的器件中可用的配置设置。
此致、
Eric Schott
Eric、
多路复用器上的 SDA 引脚和主机上的 SDA 引脚之间的唯一一个是10k 上拉电阻。 在探测上拉的 SDA 侧时、结果是相同的。 根本没有单向缓冲器或转换器。 遗憾的是、我没有让任何 TP 在物理上更靠近 TCA6424A (我将修复下一个旋转)。
我用作主机的器件是 Atmel AVR328BP。 它非常直接。 我使用相同的代码与另一条 I2C 总线上的其他器件进行通信。 如果您认为这会有所帮助、我可以发布代码。
约书亚、您好!
感谢您在我外出几天的耐心等待。
根据示波器截图、这似乎不是一个电气问题。 在每个帧期间、仍会显示最新的消息以显示器件堆栈。
我很高兴查看代码、以确保程序正确配置器件。 但是、我认为您遇到的问题是 MCU 无法识别器件发送的 ACK。 读取/写入此器件与工作示例之间是否存在软件差异? 这两个器件是否位于同一 I2C 总线上?
另一种调试方法是将逻辑分析仪连接到 I2C 总线、并将其设置为在 nack 上触发。 这将有助于我们缩小周期性发生这些事件的位置和时间、或者确定 MCU 可能无法以电气方式识别 ACK 的原因。 您是否有此类设备?
此致、
Eric Schott
Eric、
我被骗了。 首先、(尴尬)我忘记了我有一个 I2C 协议分析器。 连接它、它同意我们在示波器上看到的内容:所有数据包都是由多路复用器应答的。 但我的主机微控制器仍然看不到数据包的 ACK。 我已经在一些 Atmel AVR 论坛上发布了信息,以了解是否有人有任何想法。 感谢您的帮助;我同意这不是 TCA6424A 的问题、而是我的代码或微控制器本身的问题。