Hi, I'm working on a bare metal I2C multimaster library for the MKL25Z4 and I'm having issues when trying to enumerate attached devices to the bus.
The process I follow is basically: START --> Write[address] --> STOP. By checking the ACK bit I know if there is a device listening or not.
It works from time to time but on most occasions the bus stays lock with both SDL and SCL lines low:
The picture above shows a device attached "listening" on address 0x03. See how the ACK is issued by the servant device, but the master seems unable to STOP the transmission. This doesn't seem to happen when sending actual data (START -->WRITE[address] --> BYTE[1] --> BYTE[2] --> ... --> STOP).
My Read method:
int read_byte(){
_i2c_t.i2c->C1 &= ~I2C_C1_TX_MASK; // Set RX mode
_i2c_t.i2c->C1 &= ~I2C_C1_TXAK_MASK; // Enable ACK
byte = (_i2c_t.i2c->D & 0xFF); // Read
wait_for_bit(I2C_S_IICIF_MASK); // Wait for the transfer to be over
_i2c_t.i2c->S |= I2C_S_IICIF_MASK; // Clear out the interrupt flag
}
I'm not using interrupts so the servant device is continuously checking the status register in order to detect a transaction:
onTick(){
if(_i2c.i2c->S & (I2C_S_TCF_MASK | I2C_S_IAAS_MASK | I2C_S_BUSY_MASK | I2C_S_IICIF_MASK)){
// Master sending
while(_i2c_t.i2c->S & I2C_S_BUSY_MASK){ // Keep reading as long as the line is active
read_byte();
}
}
}
I have tried multiple things but the lines always end up locked (low). I even tried enabling the Glitch Filter just in case it was a noise issue, but it didn't work. Lines use 2k2 resistors to VCC.
Also, any advice on how to recover from this? I can detect it using the SMB->SHTF1 and SHTF2 registers, but so far the only way to do it is by hard resetting the chip.
Any help will be appreciated.
Regards,
Alex.
Hi Bob, thanks for the advice.
I tested with 1.5k resistors but the result is the same 
Regarding Mark's comments, yes a multimaster implementation can be a pain in the back side but I'm afraid I haven't even got that point yet. Here I'm just testing a standard master-slave transaction and those are the only devices in the bus.
I'm not sure if this is a hardware issue, I tested with multiple FRDM-KL25Z boards as well custom ones, the result is the same. I also tried using other libraries (mbed's I2C) and even a SoftwareI2C master version, but the problem persists.
I forgot to mention that I connected the same devices to an i2c EEPROM memory and it works just fine! reading and writing multiple bytes, the problem seems to happen only when connecting 2 MKL25Z4 devices.
Something curious I noticed; if in the original code, I keep reeding in a second loop (line 30) the problem goes away, so I believe this could be a timing issue. The state machine in one of the 2 devices (or both) seems to go out of sync for some reason:
// This works! (replacing line 30)
while(true){
data = (_i2c_t.i2c->D & 0xFF);
}
Any other ideas?
Thanks,
Alex.
Ok, I don't really know what else to do at this point. I'm about to start praying to all known deities and probably offer my cat (will have to get one first) in sacrifice.
I implemented the following logic (not optimized, just exactly as described. I'm desperate here!) as suggested on the datasheet (p. 718). It runs in every clock tick.
// Clear flag
_i2c_t.i2c->S |= I2C_S_IICIF_MASK;
// Check if arbitration is lost
if(_i2c_t.i2c->S & I2C_S_ARBL_MASK){
_i2c_t.i2c->S |= I2C_S_ARBL_MASK; // Clear arbitration
if(_i2c_t.i2c->S & I2C_S_IAAS_MASK){
if(!(_i2c_t.i2c->S & I2C_S_SRW_MASK)){
_i2c_t.i2c->C1 &= ~I2C_C1_TX_MASK; // Set Receiver mode
data = (_i2c_t.i2c->D & 0xFF); // Dummy read
}else{
// Master requesting?
// Not interested right now...
}
}
}else{
if(_i2c_t.i2c->S & I2C_S_IAAS_MASK){
if(!(_i2c_t.i2c->S & I2C_S_SRW_MASK)){
_i2c_t.i2c->C1 &= ~I2C_C1_TX_MASK; // Set Receiver mode
data = (_i2c_t.i2c->D & 0xFF); // Dummy read
}else{
// Master requesting?
// Not interested right now...
}
}else{
// Read the actual data!
data = (_i2c_t.i2c->D & 0xFF);
}
}
I'm sending 11 bytes per transaction and it seems to work fine for the first few:
(each "bar" is a transaction of 11 bytes).
Notice how at the end the bus remains locked. A closeup basically looks exactly as my previous post:
It's also worth mentioning that there is a 100ms spacing between transactions, and that if I increase this to 2000ms (2 seconds) it seems to work "fine" indefinitely.
Again, Any help will be appreciated.
Alex.
