Problem Adding Additional I2C Slaves to Azure Sphere

I believe the grove sensors have a pullup resistor.  Do not know if is required on the Avnet Azure Sphere. 

Sean

The primary I2C bus on the Avnet Azure Sphere Starter Kit has 4K7 pullup resistors to the 3.3V rail

1) Please confirm which TFMini Lidar module you are using? I assume it is this I2C version (not the UART version)

2) Are you powering the TFMini board from 3.3V or 5V rail?

3) Via which connector are you attaching the TFMini board? (Grove?)

-Peter

Thanks for the reply.  I have some new developments, but here are the answers to your questions:

1)  I2C Version definitely.  Confirmed using it with Arduino Wire library.

2)  I am powering using a 5V secondary power source tying the grounds together.  The TFMini datasheet shows it requires a 5V source but has 3.3V logic.

3)  I am just using jumper cables to attach the board.

I added 4.7K pullup resistors to the lines after studying an I2C grove board.  I figured it couldn't hurt.  I found, though, I had to make the connections with the board completely powered down - a reset of the board after connecting wouldn't work - it had to be unplugged entirely and then everything hooked up.

So, now it does recognize the on board accelerometer while hooked up.  I still haven't been able to talk to the TFMini, yet, but that is due to me fumbling through its means of communicating through I2C.

Thanks for your help.

Sean

I was able to remove my added 4.7K pullup resistors and get the accelerometer to work after all.

However, I cannot access my slave device.  Here is the code:

void seanWriteI2C() {
 uint8_t cmdBuffer[3];
 cmdBuffer[0] = 0x01;
 cmdBuffer[1] = 0x02;
 cmdBuffer[2] = 7;
 int32_t retVal = I2CMaster_Write(i2cFd,0x10,cmdBuffer,3);
 if (retVal < 0) {
  Log_Debug("ERROR: seanWriteI2C: errno=%d (%s)\n", errno, strerror(errno));
 }
 else {
  Log_Debug("Sean:  Worked!\n");
 }
}

The I2CMaster_Write throws an error that it can't find the address. 

I call this right after the i2c.c file shows the acceleration values.

The address is definitely correct as it works on the Arduino.  Not sure why its not finding it.

-Sean

Sean

According to the TFmini I2C datasheet, the maximum rate for the I2C clock is 400 kbps.

I recommend reducing the Azure Sphere I2C setting from 1MHz to 400 kbps to accommodate this.

Change line 210 of i2c.c as follows:

-Peter

Thanks for this research.  I hate to burden you with my woes to that extent, but it is appreciated.  I've been giving it the old college try all day, but its slow due to frequent need of reboots due to the Network Adapter dropping out on me or weird things like the LPS22HH suddenly not being found and not coming back until I cycle everything including the PC.

In the code, however, I believe I2C_BUS_Standard is the slower of the 2.  Standard is 100KHz - Not 1MHz.

However, I gave it a try regardless, but unfortunately have the similar results of it not wanting to detect the accelerometer when the TFMini is connected.

I have got it to successfully talk to the TFMini twice out of about 20 tries now, but have no clue what conditions allowed it as all I did was cycle power once again.

When I did get lucky and it detected the accelerometer, the code continued.  I found that the reason it wasn't finding my TFMini address was due to how it was compiling/casting the I2C value of the TFMini.  I changed how I managed that value by declaring a variable as "const uint8_t" and it made it to the "Sean:  Worked!" code below.

void seanWriteI2C() {
 const uint8_t myLIDAR = 0x10;
 uint8_t cmdBuffer[3];
 cmdBuffer[0] = 0x01;
 cmdBuffer[1] = 0x02;
 cmdBuffer[2] = 7;
 int32_t retVal = I2CMaster_Write(i2cFd,myLIDAR,cmdBuffer,3);//guessing here, using 2 for the stuff byte plus the address byte
 if (retVal < 0) {
  Log_Debug("ERROR: seanWriteI2C: errno=%d (%s)\n", errno, strerror(errno));
 }
 else {
  Log_Debug("Sean:  Worked!\n");
 }
}

Unfortunately, it went back to not detecting the Accelerometer on the next deployment.

The reason it doesn't see the Accelerometer changes, too.  Sometimes it executes and reports in the output "ERROR: platform_read(write step): errno=16 (Resource busy)" when its trying to read its register in the initI2C.  Sometimes it says "Request Timed Out".  Sometimes it says "No device or address".

Very strange, that's for sure.  I'll keep at it forever, though, because allowing to connect to all my existing I2C sensors I've collected over the years will be a very good thing.

Thanks,

Sean

Sean

Doh! You are too polite - I stand corrected, the default was 100 kHz not 1 Mhz

It would be good to view this with a logic analyzer...

-Peter

PS: You could try sending a soft reset to that TFMini module before you do the first measurement
It appears this is done with a single 0x06 byte write, to the slave 0x10 address 

Okay, I've now at least got order to the chaos.  I can do the following:

1. Deploy and get an error during execution stating "Operation Timed Out" when its looking for the accelerometer id upon init.
2. Deploy immediately again and get an error during execution stating "Resource Busy" when it attempts to look for the accelerometer id upon init.
3. Cylce the power on the TFMini.
4. Deploy again and the accelerometer ID is found and I can write a command to TFMini.  However, I still haven't pulled off a successful read.

I can do this sequence again and again and it works every time.  So, I suspect it has to do with the TFMini somehow buggering up the I2C bus.

So, I'm trying your soft reset suggestion.  I have placed the following code in the initi2c:

// Initialize TFMini
 uint8_t my_reset_value[1] = { 0x06 };
 I2C_DeviceAddress my_TFMini = 0x10;
 result = I2CMaster_Write(i2cFd, my_TFMini, my_reset_value, 1);//send soft reset
 if (result != 0) {
  Log_Debug("ERROR: TFMini Soft Reset Fail: errno=%d (%s)\n", errno, strerror(errno));
  //return -1;
 }

With this code, I get the error response that states "errno=0 (No error information)".

I wonder if I should put an asterisk in front of *my_reset_value.  When I do, I get the error response "(Bad Address)".

I feel I'm inches away.  Any thoughts?

See ya',

Sean

Sean

Two observations:

1) According to the definition of that I2CMaster_Write() function, this returns number of bytes successfully written, or -1 for failure

2) I'd suggest that your my_reset_value be defined as follows:
uint8_t my_reset_value[0] = { 0x06 }; 

-Peter