Azure Sphere MT3620 dev kit - SHT31 I2C

Question

Hello,

Has anyone successfully interface an Adafruit SHT31 to the MT3620 RDB over I2C?

I can validate that the SHT31 operates as it was tested, after scratching my head trying to get it to work with the MT3620, on an Arduino. I've uploaded the code which was started from the "I2C_LSM6DS3_HighLevelApp" example but I keep receiving a "bad address" error when trying to write.

I've tried a few scenarios, write and read functions along with the write then read function, and stumped.

Any assistance would be greatly appreciated. Thanks.38585-main.txt

Answer 1

Thanks, Dave, this is helpful. After reviewing the sample code, fundamentally, there is little difference. The underlying code calls are the same that I have in my example. However, there seems to be something going on.

I tried the UART loopback example which worked (sanity check). Then I connected my logic analyzer to the following pins: {"Name": "SAMPLE_LSM6DS3_I2C", "Type": "I2cMaster", "Mapping": "MT3620_RDB_HEADER4_ISU2_I2C", "Comment": "MT3620 RDB: Connect external LSM6DS3 to I2C using header 4, pin 6 (SDA) and pin 12 (SCL)"}.

And ran my SHT31 code (write call only to validate pin output signals) without the I2C device connected: the logic analyzer is picking up no activity on header 4, pin 6 or pin 12. This is an indication that there are no signals being outputted on SDA or SCL (ISU2) in I2C mode.

The app manifest has "Capabilities": {
"I2cMaster": [ "$SAMPLE_LSM6DS3_I2C" ]
} referenced and SAMPLE_LSM6DS3_I2C is used in the i2cFd = I2CMaster_Open(SAMPLE_LSM6DS3_I2C) call.

The SDK and OS on the MT3630 RDB are version 20.09

Answer 2

Hey there @LAVco sorry to hear your struggles.

Are you using the Grove Starter Kit for Azure Sphere with the Grove shield?

https://www.seeedstudio.com/Grove-Starter-Kit-for-Azure-Sphere-MT3620-Development-Kit.html

If so they have a driver pack and include a driver for the SHT31 - I've used and it works just fine. But note, the driver is written to work with the Grove shield as it predates direct I2C support on the Azure Sphere.

I've only had a brief look at your code, not tried, but it looks like in the right direction.

My first question to you is have you granted your application "I2cMaster": [ the_i2c_bus_you_are_using ] capability in the app_manifest.json file?

Without the capability defined the app will behave as you have described.

Also, do check out the where to get support link https://learn.microsoft.com/en-us/azure-sphere/resources/support. For developer, we encourage stack overflow forums

Regards, Dave

Answer 3

hey @LAVco

Check out https://github.com/gloveboxes/Azure-Sphere-Learning-Path/tree/master/samples/environment_monitor_sht31 - even though the README reads like it's the CO2 HOL, the code and the IoT Central template have been amended for the SHT31 sensor. I don't have the time atm to update the README.

But it works, and it's one of my favourite sensors and it had been on my todo list:)

The actual Azure Sphere project is at https://github.com/gloveboxes/Azure-Sphere-Learning-Path/tree/master/samples/environment_monitor_sht31/environment-monitor, you'll see the driver in the embedded folder.

This is the approach I take for drivers

I had a quick check around for the driver on GitHub and found the manufacturers drivers as it turned it was from the same manufacturer I had ported the CO2 driver for (https://github.com/Sensirion/embedded-sht)

Manufacturers tend to take the same approach for their drivers - there tends to be an abstraction layer for you to fill in the missing bits. For I2C drivers you need to implement I2C init, read, write and and platform specific version of delay. That is generally it. I prefer this approach as I know I'm getting the most up to date code rather than hacking on drivers I'm using on Arduino or other platforms.

You'll need to hack the code a bit - mostly to point at the I2C bus you are using for your sht31 sensor.

You will need to update the hardware definition file (see https://github.com/gloveboxes/Azure-Sphere-Learning-Path/blob/master/samples/environment_monitor_sht31/environment-monitor/Hardware/mt3620_rdb/azure_sphere_learning_path.json) and rebuild the hardware definition file.

Then from azsphere command prompt run "azsphere hwd generate-header -i azure_sphere_learning_path.json"

You'll need to update the board referenced in the CMakeLists.txt file as atm it is expecting an AVNET board. Just swap that over to SEEED.

Good luck and let me know how you get on. You can also follow me on twitter at @dglover.

Cheers Dave

Answer 4

Hey @LAVco , how did you get on?

I have created a standalone sample for you - see https://github.com/gloveboxes/Azure-Sphere-Learning-Path/tree/master/samples/environment_monitor_sht31/environment-monitor-standalone.

Clone the https://github.com/gloveboxes/Azure-Sphere-Learning-Path, the sample is there, and that way you will have all the libraries correctly referenced.

Cheers Dave

Answer 5

You can definitely declare more than one resource. Where did you read this?

This is an example of one of my app_manifests.json files

{
"SchemaVersion": 1,
"Name": "AzureSphereIoTCentral",
"ComponentId": "25025d2c-66da-4448-bae1-ac26fcdd3627",
"EntryPoint": "/bin/app",
"CmdArgs": ["--ConnectionType", "DPS", "--ScopeID", "Your_ID_Scope"],
"Capabilities": {
"Gpio": [
"$NETWORK_CONNECTED_LED",
"$LED_RED",
"$LED_GREEN",
"$LED_BLUE"
],
"I2cMaster": [
"$I2cMaster2"
],
"PowerControls": [
"ForceReboot"
],
"AllowedConnections": [ ],
"DeviceAuthentication": "Replace_with_your_Azure_Sphere_Tenant_ID"
},
"ApplicationType": "Default"
}