I2C Slave Status Reg

[TucsonDon]

I am using a PIC18F46K22 as a slave. As I am working through the order of operation I can't tell if the bits (R_nW, D_nA ect) in the SSP1STAT register are set buy hardware or are they set by software?

 

[granddad]

These flags will be set by the peripheral hw according to the bytes received , transmitted. looks like they are read only (DS40001412G-page 252)

 

[TucsonDon]

I am using a PIC18F47K42 (the master) and a PIC18F46K22 (the slave). The bus also has an i2c display and using code generated from MCC. The issue that I am having is that the slave will interrupt for either address. How can I address this in the software? I thought that it only interrupted on an address match.

 

[Pommie]

Are you using 7 or 10 bit addressing? If 10 bit then an interrupt will be generated if the first byte matches and you need to load SSPADD with the second byte of the address in SSPADD.

Mike.

 

[TucsonDon]

I am using 7 bit. I have attached a copy of the logic - Ch0 = SDA, Ch1 = SCL. The first byte is the address sent to the slave (0x18 << 1) and then the second byte is suppose to be the register (0x02) to read but that isn't sent. If I read this correct the logic low after the 9th clock is an ACK (by hardware) and then it looks like the slave is clock stretching. At the end the master sends a P because on no ACK is that correct?

 

[Pommie]

Do you have 0x90 in SSPADD and 0xFF in SSPMASK? The clock stretching looks like it's just so the slave can do the address comparison. If you were in 10 bit mode the clock stretching will last until SSPADD is loaded with the low byte. Does an interrupt happen?

Mike.
Edit, what interrupts do you have enabled?

 

[TucsonDon]

I assume that you're referring to the slave - SSP1ADD = 0x30, SSP1MSK = 0x30. The SSP1MSK was @0x18, but I forgot about the left shift and changed it to match the address. I only have the BLC and the SPI interrupts enabled, SEN = 1 for clock stretching, AHEN = 0, DHEN = 0, yes I do get an interrupt. I have attached the source files that were generated by MCC.

 

[Pommie]

Any bits in SSPMSK that are zero = don't care. So SSPMSK needs to be 0xFF. Sorry for my bad shifting - yes, 0x18<<1 = 0x30 - not 0x90 as I said.

Note that SPI interrupts can be enabled on start and stop bits.

Mike.

 

[TucsonDon]

I had done that in the past but as you can see MCC generates a warning for invalid mask. If I enable start/stop interrupts then it will interrupt on data for the LDC also, right?

 

[Pommie]

Section 15.5.9 suggests it should be 0xFF.

Mike.
Edit, it may need to be 0xFE.

 

[TucsonDon]

That it does. So is the ACK hardware driven or software driven.

 

[Pommie]

The ACK/NACK is completely hardware.

Mike.