I am having trouble getting the i2c-6 bus to work at all on the mini breakout board. I am using two devices on the bus, a sunfounder PCA9685 and a px4flow camera, with addresses 0x40 and 0x46 respectively. Initializing the devices using
flow = new mraa::I2c(6);
upm::PCA9685 *pwm = new upm::PCA9685(6,0x40);
results in the error
terminate called after throwing an instance of 'std::runtime_error'
what(): writeByte: mraa_i2c_write_byte_data() failed
When I do i2cdetect -y -r 6 it shows no devices
root@edison:~# i2cdetect -y -r 6
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
I have tried connecting one device at a time, but that doesn't work either. The devices themselves are fine since they both work perfectly when connected to the i2c1 bus. The reason I need to use the i2c6 bus is that I have another device (MPU9255) that only works when it is the only device on the i2c1 bus. Connecting all 3 devices on the i2c1 bus results in the PCA9685 and the px4flow working but not the MPU. For some reason writing to a particular register on the MPU fails when other devices are connected to the i2c1 bus.
I have had the i2c6 bus working before but it has since stopped.
If anyone has suggestions on how to fix the i2c6 bus or the problem with connected multiple devices with the MPU on the i2c1 bus, I would be very grateful.
Thanks for your interest in the Intel Edison Platform.
I would like to know which Edison board are you using, I mean the Edison Arduino board or the Edison breakout board. Also, I'll continue investigating regarding this issue.
I'll be waiting for your reply.
Thanks for your patience. I was investigating and I would like to share these links regarding other users that have had issues with the I2C and have solved them, please take a look at them:
Also, in this link you can find useful I2C tools that can help too: https://m2aglabs.com/2015/04/10/i2c-interfacing-on-intel-edison/ I2C Interfacing on Intel Edison.
Moreover, since the PCA9685 and a px4flow camera work in the I2C-1 I would like to suggest you to connect the MPU9255 through SPI interface and test if it works.
Hope this information helps.
Thanks for the reply Yermi.
I think my i2c-6 bus might somehow be broken. The SCL and SDA lines are stuck at 1.57 and 1.7 volts respectively. I have tried changing the internal resistors on the i2c-6 SCL and SDA to pulldown. I would expect this to make the lines go to zero but they remain at the same voltage.
Also, I am using a I2C library (I2Cdevlib) to pull data from the MPU, would this still work if I switched to the SPI interface, or would I need different code?
I'm not sure that the I2C port is broken, I would like to know if you can send a byte through the I2C-6 and use any Logic Analyzer (in case you have one) in order to check if this I2C port is working fine. Also, I'd suggest you to check this https://terojaakkola.gitbooks.io/intel-edison-notebook/content/breakout_board_cheat_sheet.html link and configure your I2C-6. As a remainder, be sure you are powering the I2C devices with the correct voltage, if you can share how you are powering and connecting them, it will help us.
Regarding your question about I2C library, it will not work using SPI interface.
We'll be waiting for your reply in order to know you could test the I2C port following my suggestions.
Ok I gave up on the other Edison this post was about, but I have a spare which I am now using. On the new Edison, all three of the I2C devices were working fine for about 7 hours today, and now mysteriously neither of the i2c lines (on the new edison) are working. Since this is the second time this has happened with the same setup I think there may be something weird going on.
My setup is as follows:
An 11.1v 3s lipo powers the Edison via J21 and four electronic speed controls (ESC's). The ESC's have battery eliminating circuits that output 5v on the 3-wire leads (gnd, 5v, pwm on each), which are all plugged into the PCA9685. This grounds the PCA and also provides 5v on V+, which is connected to the PCA's VCC. The V+ also powers the px4flow. Both the PCA and px4flow SCL and SDA lines are connected to the Edison's i2c-6 (J17-7) and (J17-9). Pin J20-2 (3.3v) on the edison powers the MPU, whose SCL and SDA are connected to i2c-1 SCL(J18-6) and SDA(J17-8). The MPU ground is connected to ground on the PCA which also shares ground with the px4 and the ESC's and therefore the Edison.
Sorry if that is unclear, don't hesitate to ask for clarification.
I can't think of anything I am doing blatantly wrong, the only thing that seems iffy is having the lipo power the ESC's which draw tons of current and also the Edison which draws far less current, but then again most quadrotors have batteries which power the flight controller and ESC's at the same time so I'm not sure.
I'm at a university so I could probably find a logic analyzer. How would I send a single byte through the i2c-6 (or 1) bus? I looked at the link for configuring i2c-6, which I tried, but when I ran configureIO.sh I got a the following errors:
./configureIO.sh: line 3: echo: write error: No such device
./configureIO.sh: line 4: echo: write error: No such device
./configureIO.sh: line 5: echo: write error: No such device
./configureIO.sh: line 6: echo: write error: No such device
./configureIO.sh: line 9: echo: write error: No such device
./configureIO.sh: line 10: echo: write error: No such device
./configureIO.sh: line 11: echo: write error: No such device
./configureIO.sh: line 12: /sys/class/gpio/gpio214/direction: No such file or directory
./configureIO.sh: line 13: /sys/class/gpio/gpio204/direction: No such file or directory
./configureIO.sh: line 14: /sys/class/gpio/gpio205/direction: No such file or directory
./configureIO.sh: line 17: /sys/class/gpio/gpio236/direction: No such file or directory
./configureIO.sh: line 18: /sys/class/gpio/gpio237/direction: No such file or directory
./configureIO.sh: line 19: /sys/class/gpio/gpio212/direction: No such file or directory
./configureIO.sh: line 20: /sys/class/gpio/gpio213/direction: No such file or directory
./configureIO.sh: line 23: /sys/class/gpio/gpio214/direction: No such file or directory
I've never had to do this before though, both i2c lines usually just worked.
Ok the new Edison's i2c is working. I think there was just a connection issue between the module and breakout board. Taking the module off and putting it back on fixed the issue I was having. However on my other Edison the I2C-6 is still not working, I've checked to see if it was just a connection issue but it isn't.
I will find try to find a logic analyzer today to test the i2c-6 bus. Would a 2-channel oscilloscope work to test this?
We're happy to know that your other Edison is working fine and just was a connection issue. Regarding the i2c-6 test in the other Edison, yes, that oscilloscope works, please take a look at the following link: http://www.electronicproducts.com/Test_and_Measurement/Benchtop_Rack_Mountable/Using_an_oscilloscope... Using an oscilloscope to debug the I2C protocol, and in case you have any question don't hesitate to ask.
Ok I tried testing the signals from i2c-6 with an MPU9250 connected, but I am not sure what the correct procedure is to send a single byte so that I can see it clearly on the oscilloscope. Are i2cget or i2cset good ways to send bytes to a device for testing? I tried those, but I wasn't able to get a clear enough signal to identify the single clock cycles or parts of the data sequence.
When I ran either i2cget or i2cset it was hard to tell if the signal changed, however when I did i2cdetect -y -r 6 I saw a quick but definite change in the signal. Also, for some reason when I ran i2cdetect -y -r 1, the signal on the i2c-6 lines changed according to the oscilloscope.
Do I have to send a repeated i2c signal continuously to see it clearly? It seems to be going by too fast even when I use the autoset option, and I have tried adjusting the timescale etc. I am using a Tektronix TDS 3012 two channel digital oscilloscope.
When we send a message using the I2C protocol, this message consists in some frames of data that include the start bit, address (I2C device), read/write bit, ACK/NACK bit (indicate if the address or data was received), data (byte), stop bit, please take a look at this link for more details: http://www.circuitbasics.com/basics-of-the-i2c-communication-protocol/ I2C protocol.
So, in order to test the communication between the Edison and your I2C device, you can use MRAA library in order to send/receive the message to/from your I2C device, you can use these functions:
i2c = mraa_i2c_init (i2c_bus); //specify the i2c bus number
mraa_i2c_address (i2c, i2c_device_address); //specify the I2C device address
mraa_i2c_write_byte (i2c, byte); //specify the byte
uint8_t data = mraa_i2c_read_byte (i2c);
I'd recommend you to take a look at this link: http://www.i-programmer.info/programming/hardware/9137-exploring-edison-i2c-measuring-temperature-an... I2C Measuring there you will find a useful example of how to test i2c communication as well as how to interpret the signals.
Additionally, you could compare the i2c communication between your two Edison in order to check if there are any difference.
Hope this helps.
Aren't the first four lines of code you gave essentially the same as what I originally posted?
The following line command 'flow->address(0x46);' is what fails with the original error I posted. Correct me if I'm wrong but isn't this the same as
mraa_i2c_address (i2c, i2c_device_address); //specify the I2C device address
The i2c-6 bus is not recognizing any devices.
Yes, that code is basically the same, and I have shared that because I would like to know how your Edison behaves with the code I have tested. I'm aware that your I2C-6 is not working and any device is recognized yet, however, have you checked the I2C-6 pins on your Edison in order to know if when you run that code the Edison is sending the message?
Also, we would like to suggest you to re-flash your Edison (https://software.intel.com/en-us/flashing-your-firmware-edison Flashing your firmware) with the latest image in order to discard that any old configuration is affecting this I2C port.
Sorry for being slow to reply. I am actually having trouble reflashing the edison. Unfortunately I have broken off the main mini usb port, so I can only connect via serial or wifi. Is there a way to flash the Edison without this usb port? I tried configure_edison --upgrade but that didn't seem to work
Also is it possible that physical shock could have messed up the i2c busses?
Don't worry, we are here to help you. I have found this information in order to flash the Edison board without using the USB port, you can take a look at these links for more details: https://software.intel.com/en-us/getting-started-with-ap-mode-for-intel-edison-board Flashing your board and https://gist.github.com/skvark/794217634c5024da9052 Flashing Intel Edison using only serial connection and wifi, however, the latest Edison image is too big for the partitions of the Edison and with these methods you will get an error regarding the space, that it is the issue I think you have posted in the last link. Currently, I'm unaware of other method that can accomplish it.
Moreover, could you share more details regarding how your USB port has been broken? I'm requesting this because depending on it the I2C could be affected.