> Back in August Olin wrote > > >3 - The MSSP module does not directly support slave flow control > >during a write. The master can always slow down communications to > >avoid being overrun of underrun because it controls the clock. A > >slave during a read sequence can (automatically does) do clock stretch > >to avoid underrun. However, there is nothing a slave can do to avoid > >overrun during a write, at least not directly using just the IIC bus > >via the MSSP. > > Is this correct? Nah, I just made it up. August was a slow month. > I understood that a slave can avoid overrun during a write > by clock stretching the acknowledge bit. No, it can't. > The problem I have is the slave device seems to hold the clock low after a > read of a byte. Right. Like I said, the MSSP does clock stretch on a read, but not on a write. Therefore after a read transfer, the slave will hold clock low until SSPCON,CKP is set to release it. > >2 - Note that a slave in clock stretch mode holds SDA according to > >the high bit of SSPBUF. When the SSPCON,CKP is set to release clock > >stretch, clock is released immediately. While this makes sense, the > >fix to #1 can cause trouble here at high CPU clock speeds (has nothing > >to do with IIC clock speed). The fix for #1 slows down SDA a little > >with respect to SCL. With a 20MHz slave, one instruction is not enough > >time to start driving SDA appropriately before clock is released. This > >can cause the high bit of the data byte to be read as 0 by the master > >when it 1 inside the slave. The fix is to set SSPBUF a few instructions > >before setting SSPCON,CKP. Insert a few NOPs if necessary. > > First my clock rate is much slower, the PIC is clocked at 3.6MHz, That means you have a minimum of 1.1uS between setting SSPBUF and releasing the clock by setting SSPCON,CKP. This is fine as long as your worst case SDA rise time is less than 1.1uS. If not, insert NOPs to increase the delay between SDA being set to the new value and SCL released. > and the I2C is currently running at about 50KHz. This has nothing to do with the problem above, which is a function of SDA rise time, not bus clock speed. Of course the maximum SDA and SCL rise times do dictate the upper limit of the clock speed. > From reading the AN734, Personally I don't find the Microchip app notes of much use. It is much more important to read the data sheet very carefully. You probably need to read the MSSP chapter and IIC section several times. > it would seem that once the byte is put in the > buffer of the slave for transfer to the master, everything should be > automatic for the data to transfer and the NAK to be generated by the > master, once the slave releases the clock. Not quite. First the master must be tring to do a read, else the clock pulses will never be generated whether the slave releases the clock or not. Second the master does not automatically generate ACK or NACK. This must be done separately by the master code after the byte is received. It sets SSPCON2,ACKDT to select ACK or NACK, then sets SSPCON2,ACKEN to start the ACK/NACK sequence. You really need to read the data sheet, screw the app notes. > I see the eight clock pulses for > the data, but the clock for the ACK never occurs. That is consistant with your misconception above. > The other thing that > puzzles me is that the byte that is supposed to be transmitted is 01, but > what I see on the I2C bus is 00, and the bus never gets released after the > eight clock pulses. Has anyone else had to deal with a problem like this, > and give an idea of the remedy? Strange and undocumented things can happen when a slave is overrun on a write, but it seems you are having problems with reading. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.