14 Replies Latest reply on Apr 12, 2017 2:04 PM by Intel Corporation

    edison I2C

    bennnn

      Hi ,

      I have 4 devices on an I2C bus. These devices detect on arduino in 100khz and 400khz modes.

       

      I have used a scope and minimised the skew on the edges by changing the pullup resistors.

      2k seams to be the optimum.

       

      i am using mraa to try to write data to the non-detected chip and it fails to write.

       

      I can succesfuly wite to the other devices on the bus with this code.

       

         mraa_i2c_address(i2c, 0x50); // device address

         mraa_i2c_write(i2c,reg, 2);  // write 2 x byte reg address

         mraa_i2c_write(i2c,data,buffersize);  //  send buffer out the port

       

       

      I have a programmer for this chip that does detect it if I plug it in and i succesfuly programs this DSP chip.

      chip address is 0x38

      I can write to other chips on the bus with mrra succesfuly. the eprom at 0x50 writes succesfuly.

       

      I am using i2cdetect -r -y -a  6  to scan bus 6 on the edison arduino breakout board and the 3 other ic's on the bus detect.

       

      I am ussuming the failed write to the DSP ic is becasue it is not detecting?

       

      I'll upload the scope image of the edges working on the write to the eprom if anyone thinks that will help but they look good enough to me.

       

      Can anyone think of something i'm missing out on here ? I would love to finish this project with the edison but have got stuck here !

       

      Are there known problems in mraa with multiple devices ? is the edison I2C bus week or slow ? I am am using bus 06 and not bus 01

      I read bus 01 does'nt get multiplexed on arduino breakout board or something for mraa.

       

      I can see the attempted wtires to 0x38 on my scope but nothing is returned.

       

      [ update ]

       

      I flashed Edison with latest firmware

      then update like this.

       

      opkg update

      opkg upgrade

       

      and still no 0x38 device detects.

       

      The bus capacitance is approx 40 - 50pf and I am running the edison at the stadard 400khz i2c speed. I have not tried re-building

      the edison firmware for 100khz I2C SCL clock. The device at 0x38 is good for 400khz in its datasheet.

       

      [ / end update ]

       

      my mraa test code below works with another device on the bus. In fact the other three devices on the bus are working.

       

      does anyone have an image I could download that has the 100khz enabled for edison I could try? I dought it will help since

      the edges look good enough at 400khz.

       

      I tried using isoproponol to clean the board in case there was some additional capacitance but I

      have been told 50pf should be fine anyway for 4 devices on an I2C bus.

       

      Any ideas would be much welcome as my project is stuck at this point.

       

       

      /*

      send junk out the I2c port for testing

      */

       

      #include <mraa.hpp>

      #include <iostream>

      #include <unistd.h>

      #include <unistd.h> // for usleep microseconds delay

       

      int main()

      {

          // check that we are running on Galileo or Edison or Joule

          mraa::Platform platform = mraa::getPlatformType();

          if((platform != mraa::INTEL_GALILEO_GEN1) &&

                  (platform != mraa::INTEL_GALILEO_GEN2) &&

                  (platform != mraa::INTEL_EDISON_FAB_C) &&

                     (platform != mraa::INTEL_GT_TUCHUCK)) {

              std::cerr << "Unsupported platform, exiting" << std::endl;

              return mraa::ERROR_INVALID_PLATFORM;

       

          }

       

      unsigned char reg[2];

      unsigned char data[128]; //junk bytes

       

      mraa_i2c_context i2c;

      i2c = mraa_i2c_init(0);

      mraa_init();

       

      // 2 byte reg address for write location

      reg[0] = 0x00;

      reg[1] = 0x01;

       

      for(int z=0;z<10;z++)

      {

          data[z] = z;

      }

       

            mraa_i2c_address(i2c, 0x50); // device address

            mraa_i2c_write(i2c,reg, 2);  // write 2 x byte reg address

            mraa_i2c_write(i2c,data,9);  //  send it out the port

            mraa_i2c_stop(i2c);          // stop i2c

           // }

       

            usleep(1000000);

       

          return mraa::SUCCESS;

      }

        • 1. Re: edison I2C
          toukytrip

          Hi,

           

          On which board do you work ?

           

          For the mini , i use the I2C line as follow :

          - path to set the speed of line i2c-1 : /sys/devices/pci0000:00/0000:00:08.0/i2c_dw_sysnode/mode

          - path to set the speed of line i2c-6 : /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode

           

          so, to check a line, exemple i2c-1 :

          cat /sys/devices/pci0000:00/0000:00:08.0/i2c_dw_sysnode/mode

           

          now, if i remember ,3 modes are availables, (need to recheck the datasheet for corresponding speed):

          -STD , 100 khz

          -FAST, 375 khz

          -HIGH, 385 khz

           

          to set standard mode on line, exemple i2c-6:

          echo "std " > /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode

           

          to set fast mode, line i2c-6:

          echo "fast " > /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode

          • 2. Re: edison I2C
            bennnn

            Wow , thanks toukytrip !

             

            I'm using the arduino breakout board. I'll be using the mini breakout board later if I get this to work !

             

            I changed the speed to 100khz succesfuly with echo "std " > /sys/devices/pci0000:00/0000:00:09.1/i2c_dw_sysnode/mode

             

            unfortunately 0x38 still does not detect.

             

            missing_0x38_a.jpeg

            the edge here should be fast enough ?

            missing_0x38_b.jpeg

            100khz scl

            missing_0x38_c.jpeg

             

            I'll play around with the pullups again and see if there is a way to get the rise time any quicker.

            any other ideas , things I could try ?

             

            this output was from i2cdetect -r -a -y 6

             

            I took off one componant ( the eprom 0x50 ) to reduce the part count to 3 but still 0x38 returns nothing !

            • 3. Re: edison I2C
              bennnn

              could it be the rise is to slow? The max rise time for the part is 300 ns in the data sheet for 400khz SCL.

               

              is I2C rise time calculated from 0v - VCC or to whatever the logic level on is? ( maybe 1/2 vcc ? or 1v ? )

               

              maybe I should take another look at the arduino rise time and see if its any quicker.

               

              I'm getting similar edge rise time on 400khz, about 500ns to VCC or 250ns to logic level on. I was thinking slowing down the SCL would make the part more forgiving of the 500 ns rise time.

               

              Maybe i'm not looking at the wrong thing here and i'm missed something ?

               

              part i2c rise time.png

              • 4. Re: edison I2C
                Intel Corporation
                This message was posted on behalf of Intel Corporation

                Hi bennnn,

                Thanks for reaching out.

                That's a weird issue. According to the information about I2C (Section 4.2) of the Edison Hardware Guide: http://www.intel.com/content/www/us/en/support/boards-and-kits/000005808.html, it shouldn't have problems with the rise time, so I think that it isn't the problem.

                When a I2C device is not detected, we normally recommend to the users to supply the I2C sensors with an external power supply, so you can try it and let us know if it works.

                Have a nice day.

                Regards,
                Leonardo R.

                • 5. Re: edison I2C
                  bennnn

                  Hi Leonardo,

                   

                  The part is running on its own power , 3.3v logic level set on IOVDD pins.

                   

                  It detects with arduino uno and logic level shifter and with similar rise times so I think your right it must be something

                  else.

                   

                  I can change the address of the chip. last two bits of the 7 bit address with jumpers but still not detected. the 8th bit sets read / write.

                   

                  if I use i2cdump 6 0x38 I get nothing.

                   

                  I have tried without external pullups to set the internal pullups at 2k.

                   

                  cd /sys/kernel/debug/gpio_debug/gpio27

                  echo "2k" > current_pullstrength

                  cd /sys/kernel/debug/gpio_debug/gpio28

                  echo "2k" > current_pullstrength

                   

                  I have tried using external pullups with differnt resistance ( 2k seams to give the best edge and works best with other devices on bus )

                   

                  cd /sys/kernel/debug/gpio_debug/gpio27

                  echo "50k" > current_pullstrength

                  cd /sys/kernel/debug/gpio_debug/gpio28

                  echo "50k" > current_pullstrength

                   

                  I have tried using pullups to 3.3v frm edison arduino board and my own 3.3v on device board. no I am using none with 2k pullup set on the edison.

                   

                  Can you think of anything else I can try ?

                  • 6. Re: edison I2C
                    toukytrip

                    bennnn,

                     

                    Maybe check the pinmode ? need set to "mode1"....

                     

                    cat /sys/kernel/debug/gpio_debug/gpio27/current_pinmux

                    cat /sys/kernel/debug/gpio_debug/gpio28/current_pinmux

                     

                    echo "mode1" > /sys/kernel/debug/gpio_debug/gpio27/current_pinmux

                    echo "mode1" > /sys/kernel/debug/gpio_debug/gpio28/current_pinmux

                    • 7. Re: edison I2C
                      bennnn

                      nope.. pinmux is mode1

                       

                      pinmode_screen.png

                      • 8. Re: edison I2C
                        Intel Corporation
                        This message was posted on behalf of Intel Corporation

                        Hi bennnn,

                        That's weird, We will investigate more about it, and I'll let you know when we have updates.

                        Have a nice day.

                        Regards,
                        Leonardo R.

                        • 9. Re: edison I2C
                          Intel Corporation
                          This message was posted on behalf of Intel Corporation

                          Hi Bennnn,

                          Have you tried to connect only the I2C device directly to the Edison? Please try it without any other device and without the logic level translator. There have been cases where the logic level translator is the root cause but I don't think this is the case, but you can try it.

                          We also found this thread: https://communities.intel.com/thread/104994, this user had a similar issue, and he found a workaround to make it work using the MCU. It might work for you too.

                          I hope you find this useful. 

                          Have a nice day.

                          Regards,
                          Leonardo R.

                          • 10. Re: edison I2C
                            bennnn

                            Hi Leonardo,

                             

                            I'm only using the i2c level level translator on the arduino Uno. The parts are 3.3v logic so fine direct to edison intel arduino breakout set to 3.3v

                             

                            I will hook up the 0x38 I2c part direct to edison with lab power supply and adpater board when I get time and post results here.

                            I'm not sure this will make a differnce since all the parts detect on both arduino Due and Uno ( one is atmega and other is ARM cpu so differnt platforms )

                             

                            thanks for the link to the lower level code  ( mcu library workaround ) I'll try it if I can understand it !

                             

                            If that works then maybe the problem is with mraa library?

                            • 11. Re: edison I2C
                              Intel Corporation
                              This message was posted on behalf of Intel Corporation

                              Hi Bennnn,

                              Great! Let us know when you have updates about this.

                              And, I don't think it is a problem with MRAA, because you don't have issues with the other devices that you are using.

                              We will be waiting for your updates.

                              Regards,
                              Leonardo R.

                              • 12. Re: edison I2C
                                Intel Corporation
                                This message was posted on behalf of Intel Corporation

                                Hi bennnn,

                                Do you have any updates about this?

                                Regards,
                                Leonardo R.

                                • 13. Re: edison I2C
                                  bennnn
                                  hi, I'm trying to build the code in the MCU SDK eclipse. It builds and sppears to run ,
                                  but no messages on the consile and no binaries are built for me to run on the Ediosn.
                                  the 0x38 device detects without any issues on arduino UNO ( atmel ) and arduino DUE ( arm ) on my 3 i2c part design so
                                  really no point in putting together a single chip test of the one 0x38 device. If I can't use it with other devices then I can't use
                                  the Edison.
                                  ok, before I do more work on running the MCU SDK code , I found this.
                                  if you look at the known limitations it rules out a few things for me.
                                  1, My application will also need 1 x SPI port.
                                  2, "The maximum message size for interprocess communication between the CPU and the MCU is currently limited to 255 bytes."
                                  There is 256 byte limit on I2C byte transfer? I have more than this to be loaded to My DSP.  Nearer 4008 bytes in chunks.
                                  there are a series of scipts I should upload in order to setup GPIO for possibe testing with MCU SDK, but in the instructions it olnly talk about CYGWIN example.
                                  I am on OSX and I can't find the scripts.
                                  Unless the 'Known Limitations' note are out of date then it seams the MCU SDK is another rabbit hole that not going to get me very far
                                  anyone any other ideas ? is there something wrong with the Intel Edison I2C implimentation ?
                                  Anyone else having trouble detecting multiple standard 7bit I2C addressed devices with Edison ?
                                  • 14. Re: edison I2C
                                    Intel Corporation
                                    This message was posted on behalf of Intel Corporation

                                    Hi bennnn,

                                    There have been some users with issues detecting I2C sensors, and we are not sure why this happens. I gave you the MCU suggestion because it worked for some users, and I thought that it might be helpful for you.

                                    Unfortunately, we don't have some sensors to test them and validate them.

                                    If you find a way to solve this, please feel free to post it here, it would be very useful for the community.

                                    Regards,
                                    Leonardo R.