中断期间的总线冲突

你从来没有提到你的PIC是一个主还是奴隶。在一个读事务中间的SCL上的噪声可能会导致一个奴隶开始发送一个主不想要的额外字节。这可能会导致奴隶保持SDA低，等待事务继续进行。从中恢复的干净方式是让主控器释放SDA，并在手动输出停止条件之前手动切换SCL九次。



      以下为原文

   
You never mention if your PIC is a Master or a Slave.
Noise on SCL in the middle of a read transaction could cause a slave to start sending an extra byte that the Master did not want. THAT could cause the slave to hold SDA low, waiting for the transaction to proceed.
The clean way to recover from that is for the Master to release SDA, and manually toggle SCL nine times before manually outputting a STOP condition.
 

很抱歉，PIC设备处于从模式。当PIC进入空闲模式时，这会导致代码执行退出中断程序，像往常一样继续，还是冻结？我确实有其他的定时器中断，所以我假设这些也会把它从空闲状态中恢复过来。



      以下为原文

    Sorry about that, the PIC device is in slave mode. When the PIC goes into IDLE mode would this result in the code execution to exit the interrupt routine, continue as usual, or freeze? I do have other timer interrupts so i'm assuming those would also bring it back from the IDLE state.
 
 

HI检测总线碰撞通常是主机的责任，如果一个主机在从一个从属器读取时检测到总线冲突，则主机可以停止时钟，并释放总线。如果没有从从属设备检测到，则I2C从机可以持续等待剩余的时钟信号，包括AC。我认为这是SMBus设备规定的10毫秒超时的原因之一。SSP I2C外围空闲状态和PIC CPU空闲模式是完全不同的现象。I2C在总线碰撞中的外围空闲，意味着MSSP硬件应该放弃它正在做的任何事情，应该是Read。简化SDA和SCL线，并设置Bclif标志。它对指令执行不起作用。ISR和固件的责任是适当地对Bclif作出反应。当PIC在普通的SSP中断的ISR中时，其他中断源被禁用，因此可能有可能您的代码尝试在硬冲突检测到冲突后发送数据。但是，只要设置了Bclif，I2C硬件就应该忽略它。当检测到问题时，所有SSP寄存器的状态是什么？如果你已经确定了一个硬件问题，那么解决僵局的方法对我来说似乎是合理的。你有一个可以用来挑起或验证问题的测试程序吗？如果这个问题可以反复演示，那么它可能是一个理由来支持一个支持票。迈西尔



      以下为原文

    Hi,
Detecting Bus collision is ordinarily a responsibility of the Master.
If a Master detect a Bus collision during a Read from a Slave,
then the Master may stop clocking, and release the Bus.
If this is Not detected by the Slave, I2C slave may wait forever for remaining clock signals, including the ACK clock.
I think this is one of the reasons for the 10 millisecond timeout prescribed for SMBus devices.
 
SSP I2C peripheral idle state and PIC CPU IDLE mode are completely different phenomena.
I2C peripheral idle on Bus collision, means that MSSP hardware shall give up whatever it is doing, should release SDA and SCL lines, and set BCLIF flag. It do nothing with instruction execution.
It is responsibility of ISR and firmware to react to BCLIF as appropriate.
 
When PIC is in ISR for ordinary SSP interrupt, other interrupt sources are disabled,
so it may be possible that your code have tried to send data after collision was detected by hardware,
but that should be ignored by I2C hardware as long as BCLIF is set.
 
When problem is detected, what is state of all SSP registers?
If you have actually identified a hardware problem,
then the workaround to resolve the stalemate seem reasonable to me.
 
Do you have a test program that may be used to provoke or verify the problem?
If the problem can be demonstrated repeatedly, then it may be reason to raise a support ticket.
 
There is nothing about anything like this in Errata document for the device.
 
   Mysil
 
 
 
 
 

谢谢你的回复！！！！解决方案并不简单，但Qub在解决方案的正确轨道上，MysIL帮助识别了一个我的情况的边缘情况。主设备似乎已经失去了仲裁，停止了SCL线的时钟，使从设备在某种程度上处于等待状态，同时保持从设备。ICE持有SDA线低。我们必须编辑Linux I2C内核驱动程序，并添加IOCTL调用来控制IMX6处理器（主控器）上的I2C引脚。为了快速解决方案，我们只使用9个时钟控制IO内存位置。后来我们把它改为16个时钟，因为9个时钟不会总是解决锁定问题。我们仍然需要添加一个停止条件，但是这对我们来说是有效的。谢谢。



      以下为原文

    Thank you for the replies!!! 
 
The solution was not simple but QUB was on the right track for the solution and Mysil helped identify an edge case for my situation.
 
The master device seems to have lost arbitration and stopped clocking the SCL line leaving the slave device in some sort of a waiting state while holding the slave device held the SDA line low.
 
We had to edit the Linux I2C kernel drivers and add an IOCTL call to control the I2C pins on the IMX6 processor (The Master). For a quick solution we just controlled the IO memory locations using 9 clocks. We later changed it to 16 clocks since 9 clocks would not always solve the lock up issue. We still need to add a stop condition but this is working for us now.
 
Thank you