vmilea/pico_i2c_slave

I2C_SLAVE_FINISH before transmission is done

Closed this issue · 2 comments

zzzbatmand commented

I am using a pycom device as I2C master running MicroPython.
When I try to send/read some bytes, this is the order that the pico_i2c_slave i2c_slave_handler triggers:

  1. I2C_SLAVE_RECEIVE
  2. I2C_SLAVE_FINISH
  3. I2C_SLAVE_RECEIVE

The first (1) package is correct, but then the "I2C_SLAVE_FINISH" is hit before the actual data is recieved.
I have tried this with 4 bytes, and the same happens.
What could cause this? Is there something I can try to do?

Pycom command

from machine import I2C
i2c = I2C(0, I2C.MASTER, baudrate=100000)
i2c.writeto_mem(0x17, 0x00, 0x03)

4 Bytes:

from machine import I2C
i2c = I2C(0, I2C.MASTER, baudrate=100000)
i2c.writeto_mem(0x17, 0x00, b'\x01\x02\x03\x04')
  1. I2C_SLAVE_RECEIVE
  2. I2C_SLAVE_FINISH
  3. I2C_SLAVE_RECEIVE
  4. I2C_SLAVE_RECEIVE
  5. I2C_SLAVE_RECEIVE
  6. I2C_SLAVE_RECEIVE
zzzbatmand commented

After a bit of testing, it seems that the first data package in "i2c_slave_irq_handler" has the "I2C_IC_INTR_STAT_R_STOP_DET_BITS" in it.

Order of pacages:

  1. I2C_IC_INTR_STAT_R_START_DET_BITS
  2. I2C_IC_INTR_STAT_R_STOP_DET_BITS + I2C_IC_INTR_STAT_R_RX_FULL_BITS
  3. I2C_IC_INTR_STAT_R_RX_FULL_BITS
  4. ...

This means that the "finish_transfer" is triggered when the first package is sent, and never again. So the "Stop talking" only really happens after the next request is sent, since it won't stop communication, if no communication is made prior.
It seems to be an issue with the pico interrupt handler, but not really sure why this is.

zzzbatmand commented

It seems to be an issue with the GPy