This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

I2C clock stretching on nrf52840

Hello !

I would like to know if the nrf52840 is affected by the errata https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_149.html#anomaly_832_149 or something similar ?
(I did not find it in the 52840 errata)

I am struggling to communicate with a 100KHz i2c device which require clock stretching to work. The communication often hang forever.
It sometimes work, the difference seems to be the lenght of the first clock after a stretch.

A non working screenshot :

A working screenshot:


If this is the same issue as the 832 errata, is there a known workarround ?

Thank you for your help.

  • Hi,

    The same applies to the nRF52840, but the documentation (product spec) should have been updated to reflect this, so no specific errata is made.

    The TWI hardware and driver should be able to operate in two modes, with and without EasyDMA. Have you tried to disable TWI0_USE_EASY_DMA and/or TWI1_USE_EASY_DMA?

    Best regards,
    Kenneth

  • Hi Kenneth,

    It took some time because we are not directly using the sdk, but I finally managed to use the twi without easy DMA.
    Now I use nrfx_twi.c, (slightly modified to be able to compile with the rest of our codebase)

    However, I can still see the same bug, the 1st clock after a stretch is sometimes 4 times smaller than it should be.
    The device I am communicating with (CY8C95x0A) really does not like that and behave like it is missing the shortened clock.

    (I can provide some screenshots if required)

    Am I missing something ? Any workarround would be appreciated.

    Best Regards,
    Mathieu

  • Hi,

    It was worth a test, but then it looks like this timing is indeed in hardware on both the legacy and Easydma, and can't be changed no. I assume you have two options, either use a bit bang software I2C implementation and/or look into whether a different serial interface may be used (and/or switch direction of the interface in some way).

    Sorry for this, but it is the first I have heard that this have caused an third party device to actually fail.

    Best regards,
    Kenneth

  • Hi,

    Any plans to update the specs/errata to show that TWI and TWIM share the same issue ?

    Anyway, I adapted the bigbang driver from the sdk (deprecated/twi_sw_master.c) to my codebase.
    It also had a bug on the 1st clock after a stretch, the fix was trivial though.

    	// Pull SCL high and wait a moment for SDA line to settle
    	// Make sure slave is not stretching the clock
    	transfer_succeeded &= twi_master_wait_while_scl_low(bus);
    	TWI_DELAY(); //hack


    The clock stretching is now working as expected.
    I am making this public in case it can help someone else.

    Best regards,
    Mathieu

  • Hello, sir.

    We're having the same problem with our io extender. We're trying to communicate using the bit bagging approach, but it's not working. We checked the clock signals and they're all good, but the slave isn't giving ack bits.

    please look once  i sharing the signals

    D:\DeviceDownload\nRF5SDK1702d674dde\nRF5_SDK_17.0.2_d674dde\components\drivers_nrf\twi_master\deprecated

    I'm using the SDK 17.1.0, and I'm not sure if this driver requires any adjustments to those files to make it work?

    can please suggest the what could be the issue with this?

Related