I2C ARBL bit not being set

[quevedo]

Hello,

I am writing my own functions for I2C multimaster communication, for the K64F microcontroller. Strangely, I noticed that the ARBL (Arbitration Lost) bit is never being set. I have written a small program to send data from a FRDM-K64F to an EEPROM, and a testing program in another FRDM-K64F to detect the START event and emulate an I2C transfer to the same EEPEOM (Same ID), but with a higher priority for the next byte. It means that the tested K64 should set ARBL and switch to slave mode. I have verified the correct behavior of the testing board using a logic analyzer. My tested board should send the following hexa bytes: A0 (ID 50 shifted left), 20, AA, 55; and the testing board should send A0, 10, AA, 55. At the bus I get A0, 10, AA, 55, which means that my testing board got the control of the bus and the testing board should release it, but my program does not set my user arbitration flag, which is set when the ARBL flag is tested within my I2C ISR.

Has anyone found any problem with the ARBL bit in the K64 controller? I am using I2C1.

Cheers,

Antonio

[quevedo]

Hello again,

I have finally found out by myself what was going on. I have written my ISR based on a fluxogram at the reference manual, and the first thing that should be done is to clean ihe IICIF bit at the I2Cx_S register. I am using the code line:

I2C1_S |= 0x02;

Which should write 1 to the IICIF bit without affecting the others. However, when I execute that line, the ARBL bit at the same register is cleared. I believe this is a hardware bug, but I managed to find a simple workaround: I just copied the status register to a variable before clearing the IICIF bit, and then I work with that variable to go through the IFs.

So, if any of you intend to work with a Kinetis I2C module in multimaster mode, make sure that you copy the status register before clearing the interrupt flag.

Now I can detect an arbitration loss, but I found another problem. I believe that it is better if I present it in another post.

Cheers,

[Jorge_Gonzalez · Accepted solution]

Hello Antonio:

Thank you for sharing your finding!! That explains the weird behavior.

Actually that is expected, not a hardware bug. It is caused by the use of the OR operator (I=). See a similar issue here.

Be careful with any status flag marked as w1c (write 1 to clear). Basically the code generated reads and stores the value of I2C1_S in a CPU register, then does the OR operation and stores the result back to the I2C1_S register in this case, then if the ARBL bit was previously set, this "refresh" write actually clears the flag.

Your workaround is good and it is typical in ISR functions.

Regards!

Jorge Gonzalez