In the nrfConnect SDK I can see just one example for a I2C sensor - BH1749
I want to modify this for other I2C sensors.
However the README does not explain how to make the connections. The nrf9160 datasheet does not seem to help much.
Can you suggest which pins to use and how to modify the configuration files.
For an initial test I'd like to use a BME280 in I2C mode.
Thx.
Hi, Paul!
In chapter 1.2 of the nRF Connect SDK tutorial - Part 3, simon explains how the BME280 can be used with the nRF9160. I suggest trying out his approach.
Please reach out if you face any difficulities!
Best regards,
Carl Richard
Thx Carl
I found ../ncs/zephyr/samples/sensor/bme280 in the SDK.
Then added nrf9160dk_nrf9160ns.overlay in the boards folder:
```
&i2c0 {
bme280@77 {
compatible = "bosch,bme280";
reg = <0x77>;
label = "BME280";
};
};
```
When trying to build this I get
```
error: #error Your devicetree has no enabled nodes with compatible "bosch,bme280"
```
I don't understand how to check that the following is valid for nrf9160dk
```
| BME280 | Board |
| SCL | P0.31 |
| SDA | P0.30 |
| GND | GND |
| VIN | VDD |
```
Regards.
PS. Being that the DK has two Nordic chips on it, please note that I want to do this with the 9160 without using the nRF52840. The DK board has pins labelled PO.30 and PO.31 but it's not clear how these are connected.
OK. We have and error initialising the I2C device:
```
const struct device *dev = device_get_binding(BME280_LABEL);
produces dev == NULL
```
I have downloaded and searched through various documents to check the pin numbering for I2C but found nothing so connections are as above (PO.30 and PO.31).
Are any other hardware links etc needed?
Regards
Hi again!
Could you try to use P0.10 and P0.11 instead? These should work just as well for I2C.
P0.30 and P0.31 are used for I2C communication with the I/O expander of the DK and are thus not available for use when that is enabled. Apologies for not informing you earlier about this. I was not aware of it myself.
Best regards,
Carl Richard
Thx Carl,
Just changing the overlay did not fix it.
in prj.conf would this still be correct?
```
CONFIG_SENSOR=y
CONFIG_BME280=y
CONFIG_I2C_1=y
CONFIG_I2C=y
```
Regards.
I see. It should not be necessary to change the prj.conf.
Are your sure that the correct adress for the sensor is used in the overlay? If you're using a different board for the BME280 than the one in the tutorial the address may be different aswell. I believe the address is available in the documentation of the sensor board, but if it isn't you could use this unofficial I2C scanner sample.
Best regards,
Carl Richard
Thx Carl,
OK. I checked the config against that example, also made sure that the connections were OK, including setting VDD to 3.3v. I checked at the datasheets for BME280 (its address is 0x76) and tried a second module in case the first one was not working.
I wanted to verify the I2C_1 is accessible on PO.10 and PO.11 but could not find that in the user guide.
So I'm stuck now.
I'd like to be able to look at what's happening during the call to device_get_binding() but I don't understand enough about all the driver magic that relies on.
Regards
Thx Carl,
OK. I checked the config against that example, also made sure that the connections were OK, including setting VDD to 3.3v. I checked at the datasheets for BME280 (its address is 0x76) and tried a second module in case the first one was not working.
I wanted to verify the I2C_1 is accessible on PO.10 and PO.11 but could not find that in the user guide.
So I'm stuck now.
I'd like to be able to look at what's happening during the call to device_get_binding() but I don't understand enough about all the driver magic that relies on.
Regards
Hi again!
The sensor is appearently not communicating properly with the nRF9160. Are you able to probe the pin P0.10 and P0.11 to see if there are any activity at all? If no activity, could you try using I2C_2 instead? There may be some interference with UART_1. In addition, could you have a look at what Jan Tore mentions in this comment about the BME280 on nRF9160?
I2C can access any of the GPIOs to that should not be an issue. You can read more about available GPIO on the DK here.
Best regards,
Carl Richard
Many thx Carl.
Switching over to I2C2 fixed it. Sensible values coming back from the sensor.
Regards, Paul
Good to hear!
I guess UART1 or some other _1-peripheral is active somehow.
Best regards,
Carl Richard
