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 looked closer at the logic trace and it does not match the description. I do not see any problem with it, except for the fact that the slave nacks the transaction. After the start bit the bit pattern is 11111000 (0x7C<<1 = 0xF8) followed by a 1 (nack). So it seems you write what you intend to, but for some reason the slave nacks it. Where do you get the number 0x80 from?

(Regarding erratum 109 you should not worry about it if you are using SDK version >= 13.0.0 as the workaround is implemented in the driver).

[zzzh]

To avoid using TWIM, I changed TWI0_ENABLED to 1 in nrf5_SDK_for_Mesh_v2.2.0_src\examples\light_switch\server\include\sdk_config.h 

Yeah, it looks like 0x7C on SDA, but if you read it per SCL wave as I2C protocol says, it's 0xf8, that's why it can't get ACK.

[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]

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.