AVR Freaks

It appears that the only thing in the way of this working is that by ending the transaction in ADDR+R, the TWI interface still believes it is in a transaction when the next ADDR+W and thus we get a collision error. Here is some code illustrating what I am trying to do.

ISR (TWI1_TWIS_vect)
{
	static uint8_t TxBufferPtr = RESET;
	static uint8_t RxBufferPtr = RESET;

	uint8_t status = TWI1.SSTATUS;		// Get copy of status 

	// Check if Stop was received
	if ((status & TWIC_GET_STOP) == TWIC_STOP)
	{
		// Check if we are NOT ignoring msg
		if(TWIClientStatusReg.Ignore == FALSE)
		{
			TWICStopFlag = TRUE;	// Set Stop flag
		}

		TWI1.SCTRLB = TWIC_ENDTX_NACK;
	}
	// Check if ADR+W
	else if ((status & TWIC_GET_ADDR) == TWIC_ADDR_W)
	{
		/* Ext device wants to send data (Write Start) */
		TWIClientStatus.all = FALSE;				// Reset Status reg
		TWICAddress = TWI1.SDATA;				// Get the address Rx'd

		switch (TWICAddress & ~I2C_READ)
		{
			case ADDR_NO_RESP_0:
			case ADDR_NO_RESP_1:
			case ADDR_NO_RESP_2:
				TWIClientStatus.Ignore = TRUE;		// Ignore data from these addresses
				TWICAddress = RESET;
			case ADDR_RESP_0:
			case ADDR_RESP_1:
			case ADDR_RESP_2:
				TWIClientStatus.SniffAddr = TRUE;	// Get data if next byte is to out port
				break;
		}

		TWI1.SSTATUS |= TWI_CLKHOLD_bm;				// Release SCL for next byte (IO Expander should Ack/Nack for us)

	}
	// Check if DATA+W
	else if ((status & TWIC_GET_DATA) == TWIC_DATA_W_RX)
	{
		/* Ext device sent us data (Write Send Data) */

		// Check if first byte (will be a command byte)
		if(TWIClientStatus.CommandRx == FALSE)
		{
			TWIClientStatus.CommandRx = TRUE;		// Set that we've RX'd a command byte
			TWICCommand = TWI1.SDATA;			// Data is a command byte
			RxBufferPtr = RESET;				// Set buffer to first location

			if(TWICCommand != PCA9535_OUT_PORT_CB)		// Only care about writes to output port
			{
				TWIClientStatus.Ignore = TRUE;
				TWICCommand = RESET;
			}

		}
		else
		{
			// Check if this is the first data byte
			if(RxBufferPtr == RESET)
			{
				TWIClientStatus.FirstByteRx = TRUE;	// We've Rx'd the first data byte (Flag to set data)
			}

			TWIRxBuffer[RxBufferPtr++] = TWI1.SDATA;	// Load Rx'd data in buffer and increment
		}

		TWI1.SSTATUS |= TWI_CLKHOLD_bm;				// Release SCL for next byte

	}
	// Check if ADDR+R
	else if ((status & TWIC_GET_ADDR) == TWIC_ADDR_R)
	{
		/* Ext device has requested data from us (Read Start) */

		TWI1.SCTRLB = TWIC_ENDTX_NACK;				// Don't care about reads so end transaction
	}
	// Check if Data+R
	else if ((status & TWIC_GET_DATA) == TWIC_DATA_R_TX)
	{
		/* Sent data to ext device (Read Send Data) */
		// Should never get here
	}
}
/* END I2C ISR */

Note that clearing SDATA in ADDR+R and setting the bus state to Idle had no effect. I also tried clearing the DIR bit in SSTATUS in an attempt to fool the TWI into thinking that it was addressed as a write instead of read...it's too smart for that. 

Because every time the external device writes an IO expander I care about's output port, I need DATA1 (referencing the OP) and to know which IO expander it was sent too.

And...apparently I didn't know what a "sniffer" was, because I thought it was a passive listener of all communication on the bus. It is not that, lol. I need a passive listener. 

No you have it right, I only want to see the writes. But the TWI doesn't like COMPTRANS+NACK on the ADDR+R because the IO Expander will ACK like it is supposed to, and therefore the TWI tries to NACK but sees the line low. That's the collision. If we COMPTRANS+ACK there though, the TWI and the IO expander will both ACK, but the TWI will wait for the next Start and everything is fine.

I don't need the reads but I can see the utility in "bit sniffing" them. It's a shame you can't clear the DIR bit when in ADDR+R so it treats the rest of the Tx as a write. 

It's prolly me, lol.

As I understand it, the problem is that COMPTRANS+NACK to address+R does respond, as it is the slave's responsibility to ACK/NACK to the master when an address match is Rx'd. Here's a capture of a read in progress for illustration:

When 'Address read: 24' comes along, we COMPTRANS+NACK since we know at this point we don't care. The IO expander will ACK that like it is supposed to, but the TWI will NACK there, shown as the thick red line. It then stops doing anything (shown as the vertical red line) and waits for the next Start. The problem is that the TWI must be monitoring the pin value while NACK'ing, sees that the pin is actually low when it thinks it should be high, which triggers the collision (0b01001000 or 0b01001010, can't remember). The kicker is what happens next.

Imagine the same message comes again in a few ms because that's the way the external device debounces...it's looking for the Data read to be 0xFE again to confirm the press. The interrupt fires at the end of the first byte (Address write: 24) but for whatever reason the collision is still set in TWI.SSTATUS so it enters the Error routine rather than the ADDR+W routine. It appears that the TWI hardware doesn't clear the registers on Stop, Bus Idle or Start in this case. Might this be a hardware bug?

To avoid this all, we just need to COMPTRANS+ACK when we see ( addr & 1 ) because that way the SDA pin state will be in agreeance with the TWI's action, but it will still ignore the rest of the Tx. At least, this is my working theory, haha.

All I'm saying is at least on my device COMPTRANS+NACK there causes a collision, where COMPTRANS+ACK doesn't. 

Yes, I was ignoring master reads with COMPTRANS+NACK like you were, and am RESP+ACK to master writes (although TWI1.SSTATUS |= TWI_CLKHOLD_bm; seems to work as well there).

Are those screenshots of a master read to a peripheral? If so, can you set a break point on the isError(s) and read twice? Here's what happens for me with COMPTRANS+NACK on master reads:

The top lane is the close up of the two master reads back to back. I have a breakpoint set on the my isError routine and it triggers after the first byte which is why it stops...Clock hold is active at that point. SStatus reads 0b01001010. I believe the collision actually occurs in the first transaction's address+r but we only see it at the start of the second because there's no "Error Interrupt" in the DA's TWI...only Address match, Data and Stop. COMPTRANS must disable the Stop interrupt. The bottom lane is the whole recording from the time I turn on the external device or Device A.

Here is with COMPTRANS+ACK:

Same setup but the collision isn't triggered this time. You can see at the end of the 2nd read a new transaction starts, those are the master writes that we actually want get data from.

Ok, this has been my hang-up, that the collision is occurring in the first place.

What's interesting to me is that the collision bit is still set at the next ADDR+W interrupt. On the one hand, I can see keeping the collision bit set so the user know it has occurred...the next opportunity to display that would be the Addr match interrupt. But that then forces the error routine to trigger instead of the ADDR+W routine. I guess the proper way to write the ISR then is to have the error routine in it's own if statement at the top instead of "if (error), else if (ADDR+W), else if (ADDR+R)"?