TWI Manager - TWI delayed after start condition

Hello,

I've used the TWI manager to implemented a burst of transfers to and from two devices on a single bus. Basically it waits for both devices to give a data-ready interrupt via GPIOTE, and then it schedules that block of transactions (36 in total). It runs reliably, but when I examine the bus, it looks like there is sometimes a large delay (several ms) between the start condition and the start of the transfer.

Here is a wide screenshot of the lines (so you can see how it generally runs smoothly) with the anomaly at the center:

Here's a zoomed in shot of the anomaly, with 2.26ms of delay shown:

This is especially problematic because after the interrupt, there is only 2.5ms before the data registers on the sensor will start to get overwritten (unfortunately there is no FIFO or SPI interface, otherwise this wouldn't be an issue).

My understanding is that using the TWI manager in scheduled/background mode is supposed to be non-blocking. It's clear that the transaction does start fairly quickly, but what else could be interfering with the operation like this? I do have a SPI bus configured as well (but it's not running currently, and it's using the SPI2 instance, and this manager is using TWI0, so there should be no interference). If it matters, I'm using SDK 17.1 and the latest S113 softdevice.

Thank you!

TWI Config below

#define I2C_MAX_PENDING_TRANSACTIONS    35
NRF_TWI_MNGR_DEF(m_nrf_twi0_mngr, I2C_MAX_PENDING_TRANSACTIONS, 0);

ret_code_t err_code;
    nrf_drv_twi_config_t config = {
            .scl                = SCL1_PIN_NUMBER,
            .sda                = SDA1_PIN_NUMBER,
            .frequency          = NRF_DRV_TWI_FREQ_400K,
            .interrupt_priority = APP_IRQ_PRIORITY_HIGH,
            .clear_bus_init     = true
    };

    err_code = nrf_twi_mngr_init(&m_nrf_twi0_mngr, &config);
    APP_ERROR_CHECK(err_code);

  • Hi,

    Are you interfacing the same slave TWI device on the bus on the second board that is failing? Have you been able to reproduce this behavior on one of our DKs?

    One of my colleagues suggested to connect a small resistor on the clock pin, to measure analog channels before and after the resistor to find if it's the slave or master that is holding the clock low here. Would you be able to measure that?

    P0.11 should noe have any special features that could affect the TWI peripheral as far as I can see.

    Best regards,
    Jørgen

  • Hi,

    Yes, both buses have two of the same slave devices (total of 4, they only have I2C interfaces and only two available addresses each, hence the two bus implementation). I haven't tried reproducing this on a DVK (I'm not sure I have the hardware available to replicate the exact setup). It'll be tricky, but I can try to cut the clock trace and solder a resistor in-line.

    Thanks,

    Dylan

  • Hi Jørgen,

    I can't say for sure if this alone solved it, but I fixed another issue related to the TWI interrupt priority interfering with the softdevice interrupt priority. Basically I had to reduce the TWI interrupt priority from HIGH to LOW_MID to get BLE streaming working, and since then I've looked back at the traces and they are much more stable. There is occasionally a 90-120 us gap, but that's much more tolerable than 2-4 ms and no longer concerning at all. Do you think that could have addressed the issue somehow? I wouldn't expect a priority reduction to *reduce* delays, but maybe you have some insight into that.

    Thanks,

    Dylan

  • Hi Dylan,

    I would also not expect a reduction in priority to affect this, but I also would not expect any delay before the address is output at all.

    If you could find a way to help us reproduce this behavior on a DK, we could look further into it, but otherwise I think it will be hard to debug further. 

    Alternatively, if you can confirm that this happens with any/no I2C slave device connected to the bus, and can provide your code, we can try to reproduce it on our DK ourselves.

    Best regards,
    Jørgen

Related