8/24/2018 12:32 PM | |
Posts: 5 Rating: (0) |
I'm trying to set up a project where the temperature is read in from a BMP280 grove sensor using the IoT2020. I'm running the standard Yocto Linux Example_Image_V2.2.0. First I connected the sensor using I2C (address 0x77). Running i2cdetect -r -y 0 shows the sensor is detected fine at address 0x77:
I then build the bmp280 example for c++ from the Intel iotdk UPM example using: g++ -o bmp_280 -I/usr/include/upm -lmraa -lupm-bmp280 -lupmc-utilities bmp280.cpp which compiles fine, but when run produces the error:
After this point, running i2cdetect again runs slowly and shows that the sensor is no longer present:
The output is the same whether or not the sensor is connected and requires a reboot to restore the I2C interface. The python example does the same thing. When the sensor is not connected and I run the compiled application, the interface is unaffected. I have tried different voltage jumper positions and Vcc for the sensor (i.e. 5V and 3.3V) both with the same result. I have tried another BMP280. Same result. I then tried to use the BMP280 in SPI mode where I get the error:
I have triple checked all connections, and tried the MOSI/MISO pins both on the ICSP header and on digital pins 11 and 12. Same result. I have also tried this with the included mraa-0.7.5 and upm-0.3.2 and also with the updated mraa-1.9.0 and upm-1.6.0 from the intel-iotdk respository (http://iotdk.intel.com/repos/3.5/intelgalactic/opkg/i586) with the same result. I would really like to get this working with the I2C interface, but I can't work out what is wrong here. Can anyone please advise or confirm whether they observe the same issue? |
Last edited by: R!k at: 8/24/2018 12:34:09 PMLast edited by: R!k at: 8/24/2018 12:49:02 PM |
|
8/25/2018 10:35 PM | |
Posts: 5 Rating: (0) |
On closer inspection, this issue seems to arise when mraa_i2c_read_bytes_data is called to read 26 bytes from the calibration register. However, reading from a single register appears to work, Another user reported a similar issue on the github page for the standard Yocto image where it seems the sensor is somehow "unhappy" with having so many registers being interrogated and subsequently blocks the I2C bus. My suspicion is that the default I2C bus rate is too high for some sensors, including the BMP280. Is there any way to change the I2C bus rate on the IoT2020? I've googled around since my last post and can only find documentation for the Galileo gen 2, which uses a different I2C driver so the instructions do not work on the IoT2020. The only other option I can think of is to replace any single instance of mraa_i2c_read_bytes_data() with multiple calls to mraa_i2c_read_byte_data(), which is a little inelegant... |
8/25/2018 11:33 PM | |
Posts: 16 Rating: (1) |
Hi, is this helpful for you ? https://github.com/intel-iot-devkit/mraa/blob/master/docs/galileorevh.md |
8/25/2018 11:49 PM | |
Posts: 5 Rating: (0) |
Thanks. I came across that link previously and tried the boot parameter in the boot config but I think the IoT2020 uses a different i2c driver (galileo uses "intel_qrk_gip_i2c" , whereas the example iot2020 image uses "Synopsys DesignWare I2C adapter"). Does this stem from IoT2020 using a different I2C chip from Galileo? If not, I guess it might be possible to rebuild the image using the intel_qrk_gip_i2c driver. EDIT: I've also opened an issue on the github project for the example image. |
Last edited by: R!k at: 8/25/2018 11:52:12 PMLast edited by: R!k at: 8/26/2018 12:09:17 AM |
|
8/26/2018 12:22 AM | |
Posts: 16 Rating: (1) |
Hi, I have a other solution for you. I must test it self tomorrow. But for this you need few hardware. When its work, I show it tomorrow here. Ocean |
8/27/2018 1:44 PM | |
Posts: 5 Rating: (0) |
It seems that this issue is due to the BMP280 sensor itself. According to this post when reading multiple bytes (burst read) if the message is terminated with the wrong ack and stop bit sequence, the sensor hangs. Unfortunately it seems as though the BMP280 uses a terminating sequence that is incompatible with MRAA. The solution to this is therefore to write a custom i2c read bytes function with the correct terminating sequence. |
This contribution was helpful to2 thankful Users |
Follow us on