Is there an issue with the XMEGA chips potentially missing certain TWI/I2C signals on the bus if the microcontroller isn't clocked at or near its maximum rate? Should this be documented somewhere, e.g. in one of the notes or manuals?
Consider the case where an XMEGA is acting as a TWI/I2C slave on a high-speed bus, e.g. 400 KHz. Imagine if a bus master is reading data from the XMEGA as part of a transaction, and has just received the last byte of data it is interested in. Per the protocol, after it receives the last byte, it sends a NACK back to the XMEGA and can take further action on the bus immediately. That is, there's no slave clock stretching allowed at this point. Therefore, this is a perfectly valid sequence:
1) Master reads last byte from XMEGA.
2) Master sends NACK for last byte.
3) Master sends START for next transaction.
4) Master sends slave address for next transaction.
Based on testing, if the microcontroller application code is not able to finish servicing the interrupt generated for #2 (i.e. writing a new value to SLAVE.CTRLB) before #3 occurs, it seems that the START bit is lost because the hardware isn't in the correct state to see it. The microcontroller never acknowledges its slave address and so no further interrupt is generated.
Is this interpretation correct? If so, is there anything which can be done on the XMEGA other than increasing the clock rate so that it can service the interrupt more quickly? Obviously the master can wait between transactions, but this shouldn't be required per the protocol. If nothing else, it would be helpful if this were documented somewhere.