nRF52840 I2C timing spec.

[Poki Huang]

Hi 

About nRF52840 I2C data read (CLK rate 400KHz)

1. Could you help check below three I2C items(tHD;DAT, tHD;STA, tSU;STO) can follow I2C standard(NXP) spec. or need follow nRF52840 spec.?

Since our measurement can pass standard but fail nRF52840

2. About data fall time(tf), nRF52840 datasheet no define this item, and I2C standard define min. value is 20*(VDD/5.5V), and our measurement fail I2C standard

But I check some other device, they didn’t define min. value, so could you help check if nRF52840 can accept min. value=0 ?

Thank you~~

Poki

[Poki Huang]

Hi 

I add another question

3. About I2C SCLK Tlow timing, I2C standard is min. 1.3us, but we measure about 1.23us

I see the link "devzone.nordicsemi.com/.../148194 discuss this issue but I want to confirm again

Can you modify this timing? If can't, the SCLK 1.23us timing will be ok for all slave devices?

Thank you~~

 

[Vidar Berg]

Hi,

1. You should make sure that the NXP I2C requirements are met. The el. spec. for the nRF52's TWIM module shows the timing characteristic of the peripheral itself, which should also be within the allowed timing ranges specified by the original I2C specification.

2. Looks like you are slighty outside of I2C spec on this paramater. Have you tried to increase the IO drive strength as suggested in the PS here Pullup resistor (ie set the drive strength to H0D1 for the TWIM pin configuration instead of S0D1).

3. I wasn't able to open the case you linked to, but I assume it's related to [219] TWIM: I2C timing spec is violated at 400 kHz? The answer is yes, you can change the FREQUENCY setting as explained in the errata document to ensure correct low period.

Best regards,

Vidar

[Poki Huang]

Hi Vidar:

I want to let you know again that we are discussing nRF52840 I2C SDA read data spec., not I2C SDA send data to device spec.

1. So you mean about these three I2C items(tHD;DAT, tHD;STA, tSU;STO) that nRF52840 datasheet list spec. is to promise that nRF52840 send data can meet those spec. right?

So for nRF52840 read data spec. we can follow I2C standard(NXP) spec., so our below measurement result is pass right?

 

2. For data fall time(tf), the I2C standard spec. need > 20*(VDD/5.5V) , so for our case VDD=2.1V, the spec. need > 7.63ns

But this data fall time(tf) spec. didn't list at your nRF52840 datasheet, that mean you don't concern this timing right?

If yes, so below our measurement 0.3899 is ok for nRF52840 right?

Thank you~~

Poki

[Vidar Berg]

Hi Poki,

1. Yes, that is what I meant. So the measured timings look good as far as I can tell.

2. Yes, I would not expect this to be a problem for the nR52. But I misread your measured value earlier, I read it without the decimal point so I thought you were above max. and not below Min. So rather than increasing the drive strength as I suggested, you should use the standard drive.

Best regards,

Vidar

[Kirk Wayland]

Yes, you are definitely in violation of published spec for LOW SCK minimum.  It is 1.3 usec.
This can cause the SDA line to get stuck in the LOW state.  When this occurs, only a complete power cycle will recover.  (Not a reset, a power off/on)

There is a way to recover the SDA stuck low in code.  It involves:

1. Set the two pins as GPIO (Disable the TWIM)

2. Read the SDA line and see if it is low.

3. If so, then clock the SCK.

4. Repeat 2 and 3 nine times if necessary.

5. Once the SDA line is HIGH, then enable the TWIM again.

6. Perform transfer.

This needs to occur for every transfer, and is documented in the errata.

While this will recover the SDA line, it does not prevent.  To do so, you need to slow the I2C LOW SCK to 1.3usec, which is 390Khz.

Be sure to use a scope to verify

Good luck