Hi thx for the library code u provided. This got me a working back and forth comm with an ESP32 with wire library.

I had to add some stall loops to the i2c_write_byte function to transmit multiple bytes (20) in a row. Without the code only 17 went thru.

I added the i2c_wait_until_ready_to_write function, which I then use in i2c_write_byte to make sure the buffer is ready to send.

/**
 * \brief Checks the Tx FIFO if not full
 * If full stall for maximum `max_wait_loops` times, 
 * returns false if the buffer was still full.
 * 
 * \param i2c I2C instance.
 * \param max_wait_loops stall this amount of loops until buffer is ready.
 */
    static inline bool i2c_wait_until_ready_to_write(i2c_inst_t *i2c, uint16_t max_wait_loops)
    {
        i2c_hw_t *hw = i2c_get_hw(i2c);
        while (!(hw->status & I2C_IC_STATUS_TFNF_BITS))
        {
            if (max_wait_loops-- == 0)
                return false;
        }
        return true;
    }

/**
 * \brief Push a byte into I2C Tx FIFO.
 * 
 * \param i2c I2C instance.
 * \param value Byte value.
 */
    static inline void i2c_write_byte(i2c_inst_t *i2c, uint8_t value)
    {
        i2c_hw_t *hw = i2c_get_hw(i2c);
        i2c_wait_until_ready_to_write(i2c, 3000);                     // required to wait for tx buffer to send
        hard_assert_if(I2C, !(hw->status & I2C_IC_STATUS_TFNF_BITS)); // Tx FIFO must not be full
        hw->data_cmd = value;
    }

maybe there is a better way to request a flush/send.

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

I am utilizing your library as you suggested in issue #2 namely

Produce the data in your main loop, and consume it in the callback. If there's nothing ready to send yet, simply return from the callback and it will be invoked again. For producer-consumer scheme there's buffering and synchronization to deal with.

I am using pico/util/queue.h to pass the data from the main thread to the interrupt (I also experimented simply with volatile variables). The IRQ gets called without data being ready, and for my application this is a guarantee that will happen all the time, but for now I am just doing a test in which the data is not ready at the beginning. Based on what you wrote above, I expected that the callback would be automatically called a few more times, until the data was ready. Instead, the data gets prepared, but the IRQ callback is never called again, and everything comes to a stall.

I could make a dummy packet for these situations, but I really want to avoid that, since it's a lot of unnecessary traffic (and some additional code on both the sender and receiver side to deal with) which I really want to avoid. As such, can you please elaborate more on the "it will be invoked again" part? In what circumstances will that happen? Just making a single call to i2c_read_blocking on the controller side, and nothing else on the worker side, does not trigger that re-invocation, only a single invocation (from which I return as discussed above) and then a hang. Should I use timeouts on the controller and re-invoke the read? Or anything else on the callback to sign that the IRQ should not be cleared?

Sorry for being such a pester, I really counted on I2C to work in both directions and encountering all these issues is a huge disappointment about using the picos for my project.

Hi, I have been using your very useful library to create some test code to try and get to the bottom of an issue I originally encountered using I2C slave mode with Arduino-Pico.

I recreated a test scenario using pure SDK and your library and found similar issues, the issues are fully detailed in this post along with scope traces. https://github.com/raspberrypi/pico-sdk/issues/1102

The issues are only really noticeable at I2C bus speeds above 100KHz. Earle Philhower added a recent commit to his Arduino-Pico Wire API implementation which provides a workaround for the bulk of the issues, getting the failure rate down to around 0.02%, from originally being up to 50% at 1Mhz bus speed. (fast mode plus)

It looks to me like the remaining issues are with the SDK or maybe the hardware.

Hello! First of all thank you for creating this awesome library. We've used it in the firmware for an open source device we're building (https://github.com/badgeteam/mch2022-firmware-rp2040/tree/renze/i2c-debug).

We're encountering a problem: if we talk to the RP2040 at low speeds (8kHz bus speed) everything is stable but once we increase the bus speed to 100kHz (or 400kHz) we found that the RP2040 can get into a state where slave->transfer_in_progress gets stuck high until a new transfer is started from the bus master.

We're using that flag to implement a simple form of locking on the register map, preventing registers to be used by the firmware until the transfer is done. Thus when it gets stuck on true the firmware doesn't handle requests anymore.

What bus speed did you test this library at and do you have any idea what might be causing the transfer_in_progress flag to get stuck to true until a new transfer gets it unstuck again?

Thanks for providing this example, in fact the Raspberry Pi Pico C/C++ SDK is really incomplete in this regard!!!

Are interrupts like your library does really the only way to implement I2C slave on the Pico?

I need to do something like the following on my pico slave

while(true) {
    prepare some stuff
    write some_stuff to the i2c bus # ok to block
}

Of course I could change that code to use interrupt, but it becomes unnecessary more complicated, so I tried using i2c_write_blocking() and i2c_write_raw_blocking() but those do not seem to be working. Is it really so, or am I doing anything wrong?