[参考译文] MSPM0G3519-Q1：MSPM0G3519-Q1、MCAL MSPM0_00.02.05.00 CDD_I2C：CDD_I2C_I2C 中的实现问题 Isr_Handler 和 NACK 处理

您好：Markus、

感谢您的反馈。

对于#1、“else if“句子与“switch case“句子的效果相同、每次进入中断处理程序时只会执行一个开关。 如果执行了一个开关、相应的中断状态将被清除、并下次执行下一个开关。 您是否看到 txDone 和 rxDone 处理程序未在您的测试中调用？

对于#2、已理解。  CddI2cSequenceErrorNotify 函数可以由用户正确实现？ 我想您可以尝试在您的描述中实现它。  

1) 是的、txDone 和 rxDone 处理程序不能使用 else if 条件调用。 在我看来、检查是否必须进行相同的迭代、否则 cdd_I2C_DrvState 将永远不会设置回 cdd_I2C_idle。

2) 是的,  CddI2cSequenceErrorNotify 可以由用户实现。 但在我看来,这种重试机制必须在 CddI2cSequenceErrorNotify 之前的代码中实现。

您好：Markus、

1) 根据我的理解、每次 I2C ISR 处理程序都将处理一个中断源标志、并在相应处理后清除该标志。 因此、如果先前的中断被完全处理、rxDone 和 txDone 开关将在末尾得到处理

2) 理解。 但由于重试也可以添加到  CddI2cSequenceErrorNotify 中、因此它 为用户提供了更大的灵活性来确定是否进行重新发送以及在这种情况下应进行多少次重试、对吧？ 由于 I2C 是 CDD 模块、因此这将是有关本例中处理方式的开放式主题。  

谢谢。

你（们）好

1) 我只能告诉你我在我身边观察到的。  
调用栈：
cdd_I2C_asyncTransmit（此处检查 cdd_I2C_HwUnitStatus 是否为 cdd_I2C_HW_UNIT_BUSY）
cdd_I2C_Async Transmit_Interrupt 模式
cdd_I2C_AsyncTransmit_interruptStart
...
CDD_I2C_FIFO（此处完成 Isr_Handler 的处理）
如果我们在处理 FIFO 后没有直接调用 txDone/rxDone 处理器、则 HwUnitStatus 不会设置回 cdd_I2C_HW_UNIT_FREE、在下一个 cdd_I2C_asyncTransmit 中、cdd_I2C_HwUnitStatus 的检查始终为 cdd_I2C_HW_UNIT_BUSY。 这将导致 SequenceErrorNotify 或 DetError。

针对 cdd_I2C_HW_unit_free 调用堆栈：
CDD_I2C_I2C Isr_Handler
cdd_I2C_rxDone Isr_Handler_
cdd_I2C_ChannelRead Isr_Handler_
cdd_I2C_Unit.checkLastChannel（此处，Isr_Handler_状态设置回 cdd_I2C_HW_UNIT_FREE  

2) 好的,理解。 尽管如此、如果您的开发人员有任何实施计划、或者有任何实施建议、您或许可以与他们交谈。

TI 团队大家好、

对此有何评论？

您好：Markus、

所以很抱歉晚回复,因为我在商务旅行这几周。  

我已将此问题提交给团队以提高认识。

我仍然有一个问题、如果 I2C 传输是从清除状态引起的、为什么 在完成的 I2C 传输中不会触发 I2C_CPU_INT_RIS_MTXDONE_MASK 中断、以将 HwUnitStatus 设置回 cdd_I2C_HW_UNIT_FREE？

TI 团队大家好、  

我从您的注释中了解到、您希望 rxDone/txDone 出现另一个中断。 因此、一个数据中断和一个 DONE 中断。 我的理解是否正确？

对我们来说、情况并非如此。 我们只得到一个中断。
这个中断是可配置的 DONE 中断、还是会被触发的 DONE 中断？

TI 团队大家好、

对此有何评论？

您好：Markus、

根据您的注释、我可以理解您预计 rxDone/txDone 会有另一个中断。 因此、一个数据中断和一个 DONE 中断。 我的理解是否正确？

是的、这是 MCU 处理多挂起中断的方式。 当 TXFIFO 中的数据从 I2C 总线发出时、将首先触发 TX FIFO 触发 (TXFIFOTRG) 中断、并在所有 TX 字节都发送完毕后最终触发 TXDONE。

我使用 MCAL 封装中的 CDD_I2C 示例进行了测试、如果您使用中断模式进行发送/接收、则在 Transmit_Interrupt  应用 cdd_I2C_Async-Mode () 功能后、可以在 IMASK 寄存器中启用 TXFIFOTRG 和 TXDONE 中断。 如果在中添加断点       cdd_I2C_FIFOTRG ()、我们应该能够看到 首先触发 Isr_Handler、然后 最后触发 TXDONE（从 IIDX 寄存器）。

TI 团队大家好、

我认为我们设置的问题是、 从 Isr_Handler 触发 CDD_I2C_FIFOTRG 时、已设置 RXDONE 标志。
因此、不会为 RXDONE 触发第二个中断。 这是我的假设。

如果我更改了如下屏幕截图所示的代码、则会在与 RXFIFOTRG 相同的中断中处理 RXDONE、并且一切都正常工作。 如果在单独的中断中触发 RXDONE、则此代码也是有效的。

您好：Markus、

感谢您的测试中有关中断状态的屏幕商店。

从您的寄存器状态来看、我假设问题是由以下原因引起的：   

1.CDD_I2C_RIS 从中的 Isr_Handler 寄存器获取待处理的 I2C 中断  
CDD_I2C_I2C Isr_Check 函数。 （所有原始中断都将在该函数中获得）。
2.中断处理优先级由手动代码定义：首先处理 TXFIFO、先处理 RXFIFO、然后进一步处理 RXDONE 和 TXDONE。
如果同时触发 RXFIFO 级别和 RXDONE 中断、并且挂起中断 (IIDX) 实际上为 RXDONE。 RXFIFO 级别中断实际上在 MCAL CDD_I2C_MCAL 中处理、因此 RXDONE Isr_Handler 不会在处理程序中清除。 并且无法进一步输入 CDD_I2C_IIDX（现有 Isr_Handler 将阻止其他优先级较低的中断）。

我仍在内部查看您建议的解决方法。 但从我的角度来看,我看不出你们改变的副作用。 当触发 I2C RXDONE 或 TXDONE 时、意味着通信已完成、并且在同一中断处理程序中的其他 RXFIFO/TXFIFO 中断之后可以处理它。