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?
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?
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
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
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
Hi,
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.
But should probably be fixed in nrfx drivers anyhow
I agree, I reported this back to the nrfx team just before the holiday period.
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
So far so good, but will test the external sensor a bit more before concluding.
Sounds good. Let me know if anything out of the ordinary happens.
Kind regards,
Håkon
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);
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);
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
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
Understood. I was thinking about the direct register access through "dev_config->twim.p_twim", which allows you to write to the .FREQUENCY member.
Kind regards,
Håkon
Also the i2c_nrfx_twim_config struct is declared in a .c file, so not accessible
Yes, you're right. My apologies!