nRF51422 communicating with SAA1064 via TWI/I2C

RE: nRF51422 communicating with SAA1064 via TWI/I2C

Michel — Wed, 18 Sep 2013 12:41:56 GMT

I noticed the missing TWI stop bit. That's no problem indeed.

I'm using the development boards (PCA10006 and 7). With a battery powered supply of 3.2 to 3.3V. The supply to the SAA is 5V.

Looking at the datasheet of the SAA the SDA and SCL should be at least 3.0V which should not be an issue because the supply of the nRF is 3.2V.

While writing this reply I don't know what I changed, but it's working now. I will take a closer look at the changes the last few hours.

For now thanks for helping.

RE: nRF51422 communicating with SAA1064 via TWI/I2C

Håkon Alseth — Wed, 18 Sep 2013 10:42:03 GMT

I see that my code-snippet seems to be corrupted, but it seems that you have gotten the "essence" of what I was trying to show.

I had a look at the datasheet for the display.

Have you checked that the VDD of the nRF-device is > 3.0V to ensure logic high on SDA? If you're using the eval kit, it's 3.3V and not configurable.
Have you scoped the analog lines to see if the signal is clean?

BR Håkon

RE: nRF51422 communicating with SAA1064 via TWI/I2C

Michel — Wed, 18 Sep 2013 10:23:55 GMT

Thanks for you reply. The test mentioned above didn't work. Only a ACK is received on the address of the MPU-9150. On the addresses where I expect the SAA I get a NACK even not after bitshifting the address.

RE: nRF51422 communicating with SAA1064 via TWI/I2C

Håkon Alseth — Wed, 18 Sep 2013 05:46:18 GMT

Hi,

The address on the bus will be shifted >> 1 when it's inputted to the NRF_TWIx->ADDRESS register. Have you tried sending (TWI_ADDRESS<<1)?

Also, if you loop through, you can check the ERRORSRC to see if you "hit" the right address, will be something like this:

for (uint8_t i = 0; i<=0xff; i++) { retval = twi_master_transfer(i, dummy, sizeof(dummy)); if (NRF_TWI1->ERRORSRC) // Clear error source reg by writing '1' to error bits NRF_TWI1->ERRORSRC = NRF_TWI1->ERRORSRC; else // Set breakpoint here or similar actual_address = i; }

Have you scoped the TWI-lines to see if there is any NACK/ACK on the bus?

A side note regarding TWI/I2C: The I2C name was trademarked until recently, but the actual bus-implementation was not protected. Therefore you could avoid paying fees by calling it a TWI-module.

BR Håkon