Does ncs 2.5.0 implement the workaround for TWIM timing spec anomaly 219?

[tellg]

Does ncs 2.5.0 implement the suggested workaround for https://docs.nordicsemi.com/bundle/errata_nRF52840_Rev3/page/ERR/nRF52840/Rev3/latest/anomaly_840_219.html ?

If not, will it be implemeted later?

[Håkon Alseth]

Hi,

 

Unfortunately, this is not implemented in the nrfx_twim drivers and should be overridden in the application space.

I will suggest internally that this should be handled for the driver setup on nRF52840.

 

Kind regards,

Håkon

[tellg]

Do you have a formula or register value available for setting the TWIM I2C frequency to e.g. 380 kHz in the FREQUENCY register (to make some headroom)?

We are using a https://www.ti.com/product/LDC1612 which seems to be very sensitive when being close to 400 kHz

The anomaly workaround works most of the times, but on some very few boards, 390 kHz is still too fast, but we do not want to go as far as down to 250 kHz

BTW: our I2C bus pullups are 3K3

[Håkon Alseth]

Hi,

 

The baud-rate approximation posted here will also work for I2C:

 RE: UART BAUDRATE register values 

If the current value of .FREQUENCY=0x06200000 is generating a too high frequency, then the next step would be lowering the value to 0x06100000 (or lower) for instance.

 

Are you using nrfx_twim directly? or are you using the "i2c" zephyr driver?

 

Kind regards,

Håkon

[tellg]

We have one product that uses zephyr, but the product we have problems with uses nRF5 SDK and nrfx_twim.

But should probably be fixed in nrfx drivers anyhow

We used the formula to set to 370 kHz, with register value  0x05EB8000UL, which works fine

[Håkon Alseth]

Hi,

tellg said:

We have one product that uses zephyr, but the product we have problems with uses nRF5 SDK and nrfx_twim.

Thanks for clarifying. For nRF5, you can override this by accessing the register directly after initializing.

tellg said:

But should probably be fixed in nrfx drivers anyhow

I agree, I reported this back to the nrfx team just before the holiday period.

tellg said:

We used the formula to set to 370 kHz, with register value  0x05EB8000UL, which works fine

Great to hear! This also cleared up any issues/incompatibilities with the external sensor as well?

 

Kind regards,

Håkon

[tellg]

So far so good, but will test the external sensor a bit more before concluding.

[Håkon Alseth]

Sounds good. Let me know if anything out of the ordinary happens.

 

Kind regards,

Håkon

[tellg]

For ncs, I managed to fix it like this, so that this code runs before main but after driver init:

static int fix_i2c_anomaly(void)
{
    const struct device *i2c_dev = DEVICE_DT_GET(DT_NODELABEL(i2c0));

    if (i2c_dev) 
    {
        NRF_TWIM_Type *twim = NRF_TWIM0; // Use TWIM instance 0

        if (twim->FREQUENCY == NRF_TWIM_FREQ_400K)
        {
            // Set the I2C frequency to 370 kHz
            // https://docs.nordicsemi.com/bundle/errata_nRF52840_Rev3/page/ERR/nRF52840/Rev3/latest/anomaly_840_219.html
            twim->FREQUENCY = 0x05EB8000UL;
        }
    }

    return 0;
}

SYS_INIT(fix_i2c_anomaly, APPLICATION, 0);

 

[Håkon Alseth]

Hi,

 

Thanks for updating.

Your code is good for specifically i2c0, but if you use other instances, you also need to remember to update the "twim" pointer.

One option can be to do something like in the driver:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.4.99-ncs1-1/drivers/i2c/i2c_nrfx_twim.c#L226

 

Then you can access the register similar to this:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.4.99-ncs1-1/drivers/i2c/i2c_nrfx_twim.c#L234

 

Not strictly needed to this scenario, but just something to consider if you're using other i2c instances.

 

Kind regards,

Håkon

[tellg]

Thank you

My only comment is that one cannot use nrf_twim_frequency_set as it only accepts enums of type nrf_twim_frequency_t