I'm debugging a K20F120 board and running into a problem where the 9th SCL is not issued, somewhere in the middle of transferring (block write) several tens of KB, usually after several hundred bytes.
I noticed the same bug mentioned here: i2c: Is This a Bug?
I'm attaching a logic analyzer capture, where I set the cursors at the ACK bit of the previous two bytes. You can see the spike on SDA but it's within timing requirements, it's a valid ACK. So then you can count the Kinetis is only issuing 8 bytes the last time (analyzer set to trigger on a both-low timeout), so the slave has no chance to ACK.
Slowing down the overal timing doesn't help. Putting big waits between bytes doesnt help. Doing one byte at a time doesn't help. Tried setting the glitch filter to 3, that didn't help. Eventually this happens....
Bug? Workaround?
Thx
Marc
Hi Marc,
I checked with Kinetis I2C module test engineer, we do the I2C module test between two I2C modules, such as: I2C0 module as master and I2C1 module as slave. The I2C communication is inner Kinetis MCU.
We find that phenomena (after the ninth CLK cycle on SCL line, there without low to high to low toggle signal in SDA line) during our test.
Whatever I2C module test with interrupt mode or polling mode, when I2C0 as master, there with this phenomena; when I2C1 as master, there without this phenomena, the behavior is after the ninth CLK cycle on SCL line,there always with low to high to low toggle signal in SDA line ).
The I2C communication baud rate only affect the that toggle signal width, higher baud rate with wider toggle signal (only for I2C1 module as master).
While, we found that toggle signals is continuous appears or continuous disappear during I2C test.
Whatever, we could get I2C test pass (get correct data transmit) with this toggle signal or without this toggle signal.
I also check the I2C specification, there with no requirement about this toggle signal during I2C communication.
Please check below picture:
About I2C communication problem with ADAU1445 chip, if there with EMI noise on SCL link, which cause the I2C communication fail?
Thank you for the attention.
The i2c bus is physically probably 4" with 2kΩ pullups to +3.3V. Two devices on the bus, an ADAU1966 and ADAU1445. I'm writing to the ADAU1445. It's about 13KB of data in an array. The part supports burst mode, where you write the 'register address' (looks like first 2 data words to i2c) then as many bytes as you want. Here's the code for writing a block (note, it depends on Erich Styger's 'generic I2C' Processor Expert module):
void SIGMA_WRITE_REGISTER_BLOCK( byte devAddress, int address, int length, ADI_REG_TYPE* pData )
{
word addrBuf = address;
byte ret = ERR_OK;
/*
while( length > WRITE_SIZE )
{
ret = I2Cbus_WriteAddress(ADAU1445_BASE_ADDR + devAddress, &addrBuf, sizeof(addrBuf), pData, WRITE_SIZE);
Sigma_ErrCheck( ret, "SIGMA_WRITE_REGISTER_BLOCK (big)");
addrBuf += WRITE_SIZE;
pData += WRITE_SIZE;
length -= WRITE_SIZE;
FRTOS1_vTaskDelay(1/portTICK_RATE_MS);
}
if( length > 0)
{
ret = I2Cbus_WriteAddress(ADAU1445_BASE_ADDR + devAddress, &addrBuf, sizeof(addrBuf), pData, length);
Sigma_ErrCheck( ret, "SIGMA_WRITE_REGISTER_BLOCK");
}
*/
if (I2Cbus_SelectSlave(ADAU1445_BASE_ADDR + devAddress) != ERR_OK)
{
ret = ERR_FAILED;
}
else
{
ret = I2Cbus_WriteBlock(&addrBuf, sizeof(addrBuf), I2Cbus_DO_NOT_SEND_STOP);
if( ret == ERR_OK)
ret = I2Cbus_WriteBlock(pData, length, I2Cbus_SEND_STOP);
}
if (I2Cbus_UnselectSlave() != ERR_OK)
{
ret = ERR_FAILED;
}
Sigma_ErrCheck( ret, "SIGMA_WRITE_REGISTER_BLOCK");
}
(notes: Sigma_ErrCheck() simply prints out an error message if ret != ERR_OK. You can see a previous version of the function commented out above the current version)
And here's a scope capture of a typical transaction (same part - note, this is not the same transaction as captured by the logic analyzer above, actually it's the beginning of that transaction)
