Problem Adding Additional I2C Slaves to 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

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

That's funny!    It was successfully writing the single byte all along.

I copied the if statement from the line above and paid no attention.  Happens after this many hours of beating my head against the wall.

Now to get it to read.  The chapter continues.

Thanks for the second set of eyes on it!

See ya',

Sean

Sean

For that read data command you were originally trying to send, I'd recommend using the I2CMaster_WriteThenRead() command

The format of this command is:

ssize_t I2CMaster_WriteThenRead(int fd, I2C_DeviceAddress address, const uint8_t *writeData, size_t lenWriteData, uint8_t *readData, size_t lenReadData);

and the values that you need to send are as shown in the datasheet:

Thanks.  I've been working this function this afternoon.  I have some Arduino code that works with the TFMini which confirms the 0x01, 0x02, 0x07 values as well.

I'm successfully get a return value with the following:

int32_t retVal = I2CMaster_WriteThenRead(i2cFd,myLIDAR,&cmdBuffer[0],3,incoming,7);

But the return value (retVal) is 10 versus the expected 7.  Also, the first 7 array elements of "incoming" are zero'd out after the call.

Weird...but I'm close!  I'll post the working code if I get it.

I think the erratic behavior before was due to sending bad commands and the TFMini pulling the I2C bus low.  Things are much more stable now that the I2CMaster_ commands are coming back successful.

See ya',

Sean

Sean

The MSFT documentation of that I2CMaster_WriteThenRead() library function is located here:

https://docs.microsoft.com/en-us/azure-sphere/reference/applibs-reference/applibs-i2c/function-i2cmaster-writethenread

Take a look at it's use also in the Weather Station Hackster.io project posted last week:
https://www.hackster.io/gatoninja236/azure-sphere-weather-station-d5a2bc

Good Luck - you are very close now! :-)

-Peter

Success!!

Thanks for all your help, Peter!

Here is the working code example that allows one to add on their own I2C sensor to the Azure Sphere.  It is to be placed and called within the i2c.c example code from the AvnetStarterKitReferenceDesign.  This is for use with the TFMini.  The cmdBuffer should be changed to match another devices command bytes per its datasheet.

float readDistance() {
 //Routine to output the distance to the console
 uint16_t distance = 0; //distance
 uint16_t strength = 0; // signal strength
 uint8_t rangeType = 0; //range scale
 I2C_DeviceAddress myLIDAR = 0x10; //your I2C devices address
 uint8_t incoming[7]; //an array of bytes to hold the returned data from the TFMini.
 uint8_t cmdBuffer[] = { 0x01, 0x02, 7 }; //the bytes to send the request to retrieve distance
 
 int32_t retVal = I2CMaster_WriteThenRead(i2cFd,myLIDAR,&cmdBuffer[0],3,&incoming[0],7);
 
 if (retVal < 0) {
  Log_Debug("ERROR: seanWriteI2C: errno=%d (%s)\n", errno, strerror(errno));
  return -1;
 }
 else {
  Log_Debug("Success:  Read Distance!\n");
  for (int x = 0; x < 7; x++)
  {
   if (x == 0)
   {
    //Trigger done
    if (incoming[x] == 0x00)
    {
     Log_Debug("Problem:  Distance data not valid-");//for debugging
    }
    else if (incoming[x] == 0x01)
    {
     Log_Debug("Data valid:     ");
    }
   }
   else if (x == 2)
    distance = incoming[x]; //LSB of the distance value "Dist_L"
   else if (x == 3)
    distance |= incoming[x] << 8; //MSB of the distance value "Dist_H"
   else if (x == 4)
    strength = incoming[x]; //LSB of signal strength value
   else if (x == 5)
    strength |= incoming[x] << 8; //MSB of signal strength value
   else if (x == 6)
    rangeType = incoming[x]; //range scale
  }
  float the_return = distance / (12 * 2.54);
  Log_Debug("Distance=%f Feet\n",the_return);
  return the_return;
 }
 return -1;  //if we get this far, it failed.
}

I feel like I just whittled a life size bear from the Angel Oak.

After 30 years of programming, pointer syntax still confuses the crap out of me.  My issues all along were primarily pointing to the wrong areas in memory which would send the device or Azure into a chaos.

The data is rolling up to here:  https://raisingawesomedriversafetymonitoring.azureiotcentral.com/details/device/a7y9e6/measurements

I'm curious?  Can anyone access this link?

See ya',

Sean

Sean

That's great to hear! Thanks for the feedback and sharing the working code

Right now I see the following message at the azure iot central link you provided

https://raisingawesomedriversafetymonitoring.azureiotcentral.com/details/device/a7y9e6/measurements

-Peter

Sean

That's great to hear! Thanks for the feedback and sharing the working code

Right now I see the following message at the azure iot central link you provided

https://raisingawesomedriversafetymonitoring.azureiotcentral.com/details/device/a7y9e6/measurements

-Peter