Why nRF52832 output wrong TWI wave?

[zzzh]

Hi,

I was trying to communicate with an I2C device, which's address is 0x7C

But I always got NRF_DRV_TWI_EVT_ADDRESS_NACK event, so I took a check on the TWI wave:

Looks like the signal on SDA is correct but the SCK signal is 1 cycle later than normal, that make 0x7C as 0x80.

Why this could happen? is it an issue missed in errata?

Note: I noticed there's DMA issue in errata so I choosed TWI instead of TWIM

[Einar Thorsrud]

Hi,

Can you show us the code you are using when you see this? Also, do you get the same behavior when using TWIM? Assuming you use the driver you only need to set TWI0_USE_EASY_DMA to 1 in your project sdk_config.h to use it.

Regarding the DMA erratum, i assume you are referring to 109? This does not have any practical consequences if you are using the TWI driver from a recent SDK as it incorporates a workaround.

[zzzh]

Hi, Einar,

I used the same code as in nRF5_SDK_15.0.0_a53641a\examples\peripheral\twi_sensor, the difference is I used it in BLE\nrf5_SDK_for_Mesh_v2.2.0_src\examples\light_switch\server after some changes.

To avoid DMA issue of 109 in errata, I did not try TWIM.

[Einar Thorsrud]

Hi,

I am not able to see that. Looking at the plot (where I assume SDA is the top line and SCL the lower line) all seems to match with the I2C protocol as far as I can see. There are clearly several '1's in the beginning (rising SCL with SDA high), so I don't see how you can interpret it as 0x80 ("10000000").

Could it be that this is just a classical I2C confusion about whether the read/write bit should be included in the address or not?

[zzzh]

Sorry, it's not 0x80, but 0xf8, I said it wrongly

[Einar Thorsrud]

I see. Then this is probably just a confusion about the read/write bit. The lowest bit is the read write bit (1 = read), so when you want to write to your device (address 0x7C) you will see 0xF8. When you want to read from it you will see 0xF9. That is according to I2C spec.

A typical mistake is to think that the address includes the r/w bit. If that is the case here, you should instead use the address 0x31 (which is 0x7C >> 1).

[zzzh]

Good guess, but it's 0x7C with the last bit being 0 (write)

[zzzh]

Got it, this is probably the case.

Though, I don't think it's a mistake, it's just a different way of understanding, look what slave datasheet shows.