[参考译文] 使用中断/轮询进行 I2C NACK 检测

您好、Ruta、

在您的多从硬件设置中、您说同一总线上有多个 TCA9555、其中一个正在工作、另一个不工作？ 还是工作案例中的硬件完全不同？

您能否共享正在轮询 NACK 位的 ISR 代码？ 根据以下文档、当您在 ISR 中读取 I2CISRC 以获取中断代码时、I2CSTR.NACK 位可能会被清除。 但是、我不确定这是您遇到的行为。

I2CISRC 寄存器说明：

您不必启用 NACK 中断来轮询 I2CSTR.NACK 位、即可看到该位已设置。 TRM 中的位描述表示" CPU 可以轮询 NACK 或使用 NACK 中断请求。"

NACK 中断仅在 C2000器件为发送器时适用、因此不会检测到主器件生成的 NACK。

最棒的

Kevin

大家好、Kevin、感谢您的回复。 我看到我造成了一些模棱两可的情况，所以让我澄清一下(我的道歉)。

1.我的驱动程序将扩展到多个从器件(并非所有 IO 扩展器、而是 RTC、DAC_EVM 和 IO 扩展器 EVM)。 多从站支持正在进行中。

2.我的部门独立测试两个 IO 扩展器 EVM (使用 TCA 9555)(它们不是同时在同一 I2C 总线上、因为它们都具有相同的地址引脚配置)。 我运行的是相同的单元测试代码、它基本上会切换端口0上的 LED。

3.其中一个 IO 扩展器工作正常、我可以看到 LED 切换操作。 由于所有地址引脚都为高电平、因此在0x27H 寻址。

第二个 IO 扩展器具有相同的地址引脚配置。 当我将其交换到总线上(完全移除第一个)并运行相同的单元测试时、我会得到一系列的 nack (如图所示)。

我需要能够在软件中检测这些 nack、因此在 ISR 触发时包含了对 nack 位的检查。

但是、当触发 STOP_Condition_Detected 中断时、似乎 NACK 位从未设置。

根据重新读取技术参考、并由于您在上面的第一张图片、我开始怀疑每次读取 I2CISRC 寄存器时 NACK 位都会被清除。

我将在此线程上共享我的 ISR 处理逻辑。 我将修改单元测试以对故障 IO 扩展器 EVM 执行读取操作、并尽快发布结果。

**请注意：该函数名为 InterruptHandler，但根据设计采用一个参数，它由实际映射到 Hwi n BIOS cfg 的 void 参数函数调用。

void i2cInterruptHandler (uint32_DTC baseAddress)
｛
I2C_InterruptSource i2cInterruptSrc；
uint16_DTC I；

i2cInterruptSrc = I2C_getInterruptSource (baseAddress)；

IF (I2C_INTSRC_STOP_Condition = i2cInterruptSrc)
｛
//如果在 NACK 后的写入结束时检测到 STOP，则重置消息状态
//如果在正常写入结束时检测到停止条件，则重置消息状态
if (MSGSTAT_WRITE_BUSY =currMsgPTR->messageStatus)
｛
if (I2C_getStatus (baseAddress)& I2C_STS_NO_ACK)
｛
currMsgPtr->messageStatus = MSGSTAT_nack_recd；
｝
其他
｛
currMsgPtr ->messageStatus = MSGSTAT_INACTIVE；
｝
｝
//else、如果在成功读取结束时检测到停止条件、则将数据复制到消息缓冲器中
否则(MSGSTAT_READ_BUSY =currMsgPTR->messageStatus)
｛
对于(i = 0；i <(currMsgPtr -> dataByteCount)；i++)
｛
currMsgPtr ->dataByteBuffer[i]= I2C_getData (baseAddress)；
｝

currMsgPtr ->messageStatus = MSGSTAT_INACTIVE；
｝
｝

否则、如果(I2C_INTSRC_REG_ACCESS_RDY = i2cInterruptSrc)
｛

//如果主器件发出一个带有停止条件的写入操作，则不会触发该中断
//如果从接收器接收到地址设置请求，则更新消息状态并发出 STOP
在正常读取结束时应显示//NACK。


//检查状态寄存器中的 NACK 位
IF (I2C_getStatus (baseAddress)& I2C_STS_NO_ACK)
｛
//发送停止条件并清除 NACK 位
I2C_sendStopCondition (baseAddress)；
I2C_clearStatus (baseAddress、I2C_STS_NO_ACK)；

if (MSGSTAT_SEND_NOSTOP_BUSY =currMsgPTR->messageStatus)
｛
currMsgPtr->messageStatus = MSGSTAT_nack_recd；
｝
｝

//主设备需要在结束时将自身置于接收器模式
//地址设置。
如果(MSGSTAT_SEND_NOSTOP_BUSY =MscurrgtPtr ->messageStatus)则为其他地址
｛
//现在发送一个新的起始条件作为主接收器
currMsgPtr ->messageStatus = MSGSTAT_RESTART；

//设置从机地址
I2C_setSlaveAddress (baseAddress、currMsgPtr -> slaveChipAddress)；
//设置要读取的字节数
I2C_setDataCount (baseAddress、currMsgPtr -> dataByteCount)；
//I2C_MDR_MST = 1、I2C_MDR_TX = 0
I2C_setConfig (baseAddress、I2C_MASTER_Receive_mode)；
//I2C_MDR_STT = 1、I2C_MDR_STP = 1
I2C_sendStartCondition (baseAddress)；
当数据字节计数器递减计数时、//停止条件将在总线上发送
I2C_sendStopCondition (baseAddress)；

currMsgPtr ->messageStatus = MSGSTAT_READ_BUSY；
｝
｝

对于与 I2C 相对应的 PIE 通道上的伪中断、则为 ELSE //纠正措施
｛
I2C_clearInterruptStatus (baseAddress、i2cInterruptSrc)；
｝
//为组8中断发送 PIE ACK
interrupt_clearACKGroup (interrupt_ack_group8)；
｝ 

更新到上述帖子：我修改了器件测试、仅读取故障(Nack-ing) EVM 上的端口状态。 ISR 中 ACCESS_READY 部分内的逻辑执行并改变消息状态以反映 NACK、然后生成停止条件。 NACK 位保持为0、或在 STOP_Condition_Detected 的中断触发后读取 I2CISRC 寄存器后被清除。

您好、Ruta、

好的。 为了澄清您的最新测试、当 I2C_INTSRC_REG_ACCESS_RDY 中断触发时、NACK 状态标志被正确设置。 状态位按预期工作、对吧？

对于 I2C_INTSRC_STOP_Condition 中断情况、如果您执行的测试注释掉以下行、以便在读取状态寄存器之前不读取中断源、该怎么办？ 那么 NACK 位是否已设置？

i2cInterruptSrc = I2C_getInterruptSource (baseAddress)； 

这将测试当 I2C_INTSRC_ARB_Lost、I2C_INTSRC_NO_ACK 或 I2C_INTSRC_STOP_Condition 中断发生时、读取中断源是否清除 NACK 标志。

最棒的

Kevin

尊敬的 Kevin：

感谢您的回复。

1.我使用 NACKing IO 扩展器运行测试、只需读取端口状态。 当 I2C_INTSRC_REG_ACCESS_RDY 中断触发时、我的读取消息标志(请参阅上面的第52行)更改为 MSGSTAT_nack_recd。 因此、当中断触发时、NACK 位必须被置位。
在地址设置期间、在接收到 NACK 时采取的操作是将 NACK 位清零并发送一个停止条件。
之后我观察到寄存器状态、此时 NACK 位为0。

2.我注释掉了您提到的那一行内容、并直接检查了 I2C_getInterruptSource (baseAddress)返回的值。 行为是相同的。

那么这是否意味着在一个停止条件而不是 ACCESS_READY 条件之后简单地调用 I2C_getInterruptSource()将清除 I2C 状态寄存器中的 NACK 位？ 这种情况下是否有权变措施？

您好、Ruta、

好的、(1)和(2)是我根据文档预期会发生的情况。

Ruta Bhave 说：

这是否意味着在停止条件而不是 ACCESS_READY 条件之后，只调用 I2C_getInterruptSource()就会清除 I2C 状态寄存器中的 NACK 位？

由于 I2C_getInterruptSource()函数读取 I2CISRC.INTCODE 寄存器位，因此清除了相应的状态位，所以似乎就是这种情况。

[引用 user="Ruta Bhut"]在这种情况下是否有权变措施？

您的情况的一个可能的权变措施是使用 I2C_getStatus (baseAddress)函数来检测停止条件，而不是 I2C_getInterruptSource()。

最棒的

Kevin

尊敬的 Kevin：

我进行了以下小改动、只是为了检查当我从 TCA9555接收到 nacks 时、在 I2C_getInterruptSource()之前调用的 I2C_getStatus()是否允许我读取状态寄存器并设置 NACK 位。

void i2cInterruptHandler (uint32_DTC baseAddress)
｛
I2C_InterruptSource i2cInterruptSrc；
bool DTC nackDetected；
uint16_DTC I；

nackWasDetected = I2C_getStatus (baseAddress)& I2C_STS_NO_ACK；

i2cInterruptSrc = I2C_getInterruptSource (baseAddress)；

IF (I2C_INTSRC_STOP_Condition = i2cInterruptSrc)
｛
//如果在 NACK 后的写入结束时检测到 STOP，则重置消息状态
//如果在正常写入结束时检测到停止条件，则重置消息状态
if (MSGSTAT_WRITE_BUSY =currMsgPTR->messageStatus)
｛
IF (nackWasDetected)(nackWasDetected)
｛
currMsgPtr->messageStatus = MSGSTAT_nack_recd；
｝
其他
｛
currMsgPtr ->messageStatus = MSGSTAT_INACTIVE；
｝
｝

但是、这仍然会将消息状态标志更改为 MSGSTAT_INACTIVE、而不是我所期望的 MSGSTAT_nack_recd。 我开始怀疑 NACK 位是否已设置、因为 EVM 上的地址引脚存在问题且 TCA9555无法识别地址0x27、因此应该会发生这种情况。 我很不明白为什么会发生这种情况。

停止条件后 I2C 模式寄存器(I2CMDR)的内容为0x4220：自由运行、发送模式、模块启用。 当 I2C 主机产生一个停止条件时、主机(MST)位被自动清零。

此外，使用 I2C_getStatus()函数检测停止条件而不是在 ISR 中读取 I2CISRC 寄存器会导致错误行为。  

if (I2C_getStatus (baseAddress)& I2C_STS_STOP_Condition)
｛
nackWasDetected = I2C_getStatus (baseAddress)& I2C_STS_NO_ACK；
//如果在 NACK 后的写入结束时检测到 STOP，则重置消息状态
//如果在正常写入结束时检测到停止条件，则重置消息状态
if (MSGSTAT_WRITE_BUSY =currMsgPTR->messageStatus)
｛
IF (nackWasDetected)(nackWasDetected)
｛
currMsgPtr->messageStatus = MSGSTAT_nack_recd；
｝
其他
｛
currMsgPtr ->messageStatus = MSGSTAT_INACTIVE；
｝
｝ 

这就是我临时修改原始 ISR 的方法、在这种情况下、messageStatus 标志不会更改为 nack_recd 或不活动。 因此，出于某种原因，if()条件不会评估为 true。

现在我将恢复到我的原始实现方案，并尝试在读取 I2CISC 之前弄清为何无法使用 I2C_getStatus()读取 NACK 位。

如果您可以在停止条件后向正确方向指示以检测 NACK、我将不胜感激。

非常感谢您迄今提供的帮助。

您好、Ruta、

在最新的代码片段中，I2C_getStatus()返回第1行中的值是什么？ 它是否包含 NACK 位？ 可以通过如下所示存储返回值并设置一个断点来检查该值：

uint16_t I2C_int_FLAG_STATUS；//可用于存储状态值

I2C_int_FLAG_STATUS = I2C_getStatus (baseAddress)；

ESTOP0；//此处的断点然后检查 I2C_int_FLAG_STATUS 

这种行为对我来说似乎很奇怪、我本来希望在使用您的最新代码片段运行时设置 NACK 位。 当我有时间时、我会尝试在我的一侧测试此行为。

您已经查看了 C2000ware 中的 i2c_ex2_EEPROM.c 示例、对吧？ 目录中找到

C：\ti\c2000Ware_1_00_06_00\driverlib\f2837xs\examples\cpu1\i2c\i2c_ex2_EEPROM.c

此示例似乎在基于 msgStatus 状态机的停止条件后检测到 NACK。 请参阅以下中的注释：

//
//中断源=检测到停止条件
//
if (intSource = I2C_INTSRC_STOP_Condition)
｛
//
//如果已完成的消息正在写入数据，则将 msg 重置为非活动状态
//
if (currentMsgPtr ->msgStatus =MSG_STATUS_WRITE_BUSY)
｛
currentMsgPtr ->msgStatus = MSG_STATUS_INACTIVE；
｝
其他
｛
//
//如果在的地址设置部分收到 NACK 消息
// EEPROM 读取、下面的代码进一步包含在寄存器中
//访问就绪中断源代码将生成停止
//条件。 在接收到停止条件后(此处)、设置
//要重试的消息状态。 用户可能希望限制该数字
//在生成错误之前重试次数。
//
if (currentMsgPtr ->msgStatus = MSG_STATUS_SEND_NOSTOP_BUSY)
｛
currentMsgPtr ->msgStatus = MSG_STATUS_SEND_NOSTOP；
｝ 

最棒的

Kevin

大家好、Kevin、对于我之前的查询、我可能已经找到了一个解释、说明为什么尽管发出了一个带有停止条件的写入、ACCESS_READY 中断会被触发。  

http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK

似乎在硬件中清除了 STP 位、因此 ACCESS_READY 中断在 NACKing 事务之后被触发。 按照上述链接中的步骤和其余步骤、我能够针对似乎有效的 NACK 问题实施变通办法。

这似乎是一个有效的解释吗？ 如果您能确认、我将不胜感激。

谢谢你。