AnsweredAssumed Answered

i2c master receive spurious bytes lost

Question asked by Rob. on Apr 22, 2013
Latest reply on Apr 24, 2013 by Rob.

 

My problem is that the last byte of a message, initiated via i2c_smbus_read_word_data can be lost when some other stuff is executed. The problem does not occur with byte-based transfers.

Other stuff executed?: notably, last bytes may not read  when e.g. aplay is run, also when the audio file is not present. When an audio file is playing, no problems occur. Missing read occurs in conjunction with the very start of aplay (no problems found with e.g. normal file transfers).

 

Some detail info:

- System based on 2011R1 (3.0.8)

- manually, I applied some patch details in i2c-bfin-twi.c, in order to take latest changes into account

I added following printk into i2c-bfin-twi.c code:

            printk(KERN_DEBUG "%d|%02x\n", iface->readNum, *(iface->transPtr));

            iface->transPtr++;

            iface->readNum--;

in bfin_twi_handle_interrupt()

after

  if (twi_int_status & RCVSERV) {

     if (iface->readNum > 0) {

The resulting log around a spurious loss looks like this:

i2c i2c-0: ioctl, cmd=0x703, arg=0x22

i2c i2c-0: ioctl, cmd=0x720, arg=0xa9fc5c

2|ff

1|ff

i2c i2c-0: ioctl, cmd=0x703, arg=0x25

i2c i2c-0: ioctl, cmd=0x720, arg=0xa9fc5c

2|ff

i2c i2c-0: ioctl, cmd=0x703, arg=0x24

i2c i2c-0: ioctl, cmd=0x720, arg=0xa9fc5c

2|ff

1|ff

where a non-read byte is given, the returned word in the above function is e.g. 0xCFFF.

The customer reports, that in some cases the I2C-transfers sticks in such error, where only a system restart helps.

The I2C clock is 100 kHz. 200 kHz makes things worse. A lower clock (60 kHz) makes not much difference.

Outcomes