Hi Carlos,
thanks for the help.
I got my I2C Monitor Mode now up and running, but i ran into another problem.
Apparently my Interface interprets all intercepted I2C-Packets (so everything between Start and Stop Condition) as Writing-Operations (as Slave-Receiver).
Meaning the State changes look like:
0x60 -> 0x80 -> 0x80 -> ... -> 0xA0
where the states indicate the following:
0x60: Own Slave Address + Write Bit received, ACK received
0x80: Addressed with own Slave Address, Data received, ACK returned
0xA0: Stop or Repeated Start received
However they should also be State changes like:
0xA8 -> 0xB8 -> 0xB8 -> ... -> 0xC8 -> 0xA0
where the states indicate the following:
0xA8: Own Slave Address +Read Bit has been received; ACK has been returned
0xB8: Data byte in I2DAT has been transmitted; ACK has been received
0xC8: Last data byte has been transmitted, ACK has been received
I verified the measured protocol with an Logic Analyzer and the Results indicate that the R/W-Bit was indeed transmitted correctly.
Here is the code i used to configure the I2C interface:
LPC_I2Cx(id)->ADR0 = (I2C_SLAVE_ADDR << 1); //Set own device address
LPC_I2Cx(id)->MASK[0] = (I2C_SLAVE_MSK << 1); //Set address mask
LPC_I2Cx(id)->MMCTRL |= I2C_I2MMCTRL_MM_ENA; //Enable I2C Monitor Mode
LPC_I2Cx(id)->CONSET = I2C_CON_I2EN | I2C_CON_AA;
LPC_I2Cx(id)->CONCLR = I2C_CON_STA | I2C_CON_STO | I2C_CON_SI; //Enable I2C Interface
BOTTOM LINE:
So that leaves the Question what causes this behavior?
Is it the I2C Interface itself that forces the R/W Bit to a '0' and interprets therefore a Writing Operation (+ jumping to the corresponding States)?
If YES, is there a way to bypass this Issue?
If NO, did I configure something wrong?
(Feedback/Suggestions/Experiences are much appreciated ;-) )
BR,
Alexander
