9 Replies Latest reply on Jun 29, 2015 8:03 AM by Intel_Peter

    Edison's SPI bus problem

    Youssef

      Hey,

       

      I have been working on configuring Edison's SPI bus to control an analog to digital converter chip (ADS1299) through the mraa library.

      While my program is running, I am monitoring the SPI pins (SCLK, MOSI, MISO, and CS1) and it seems that SCLK, MOSI, and CS1 are working correctly. However, the MISO pin only shows noise.

      Is there usually a quick fix for this kind of problems?

       

      In my program, I am only trying to read ADS1299's register #15, which translates into sending 0x35 - 0x00 - 0x00.

      Here is the program that I am running: (Eclipse IDE platform)

       

      int main(){

           mraa::Spi* spi;

       

           spi = new mraa::Spi(0);

       

           spi->frequency(4000000);

       

           uint8_t data[] = {0x35,0x00,0x00};

           uint8_t rxBuf[3];

       

           if(spi->transfer(data, rxBuf, 3) == MRAA_SUCCESS){

           printf("Received: %i - %i - %i\n",rxBuf[0],rxBuf[1],rxBuf[2]);

           }

          

           usleep(10000);

       

           delete spi;

       

          return MRAA_SUCCESS;

      }



      Any help would be appreciated.

      Thanks,

       

      Youssef

        • 1. Re: Edison's SPI bus problem
          Intel_Peter

          Hello Youssef,

           

          I've experienced a similar behavior on my Edison when running mraa/spi_max7219.c at master · intel-iot-devkit/mraa · GitHub.

          I noticed an improvement on the noise by adding a pull up resistor on the MISO pin.

           

          The image bellow is the reading of the example above without a pull up resistor.

           

          withoutpu.PNG

           

          The image bellow is the same example but using a pull up resistor.

           

          withpu.PNG

           

          Why don't you try it on your Edison and let us know if you see any improvement.

           

          Peter.

          • 2. Re: Edison's SPI bus problem
            Youssef

            Hey Peter,

             

            Thanks for the reply. I just got the chance to add a 10 Kohm pull up resistor to my circuit. It seems that the problem persists.

             

            Here is what i get when i run my code: The Red signal is the MISO and the Blue signal is the Clock. Can you think of any other cause of this problem?

            Screen Shot 2015-06-08 at 12.14.50 PM.png

            Thanks,

             

            Youssef

            • 3. Re: Edison's SPI bus problem
              Intel_Peter

              I tested your code I got the following output.

               

              spitestoutput.PNG

               

              Although it don't see any noise (This time I'm using a pull-down resistor) my output doesn't look at all like yours.

              Is the bellow the code that you are running?

               

              #include <unistd.h>
              #include <stdint.h>
              #include "mraa.hpp"
              int main()
              {
                      mraa::Spi* spi;
                      spi = new mraa::Spi(0);
                      spi->frequency(4000000);
                      uint8_t data[] = {0x35,0x00,0x00};
                      uint8_t rxBuf[3];
                      if(spi->transfer(data, rxBuf, 3) == MRAA_SUCCESS)
                      {
                              printf("Received: %i - %i - %i\n",rxBuf[0],rxBuf[1],rxBuf[2]);
                      }
                      usleep(500);
                      delete spi;
                      return MRAA_SUCCESS;
              }
              

               

              Peter.

              • 4. Re: Edison's SPI bus problem
                Youssef

                Yes, this is the code i'm running. Since I am not getting the correct return value on the MISO pin, I just wanted to make sure that edison's side of the SPI communication runs correctly.

                However, I might be wrong, but since Edison is sending 3 bytes on the MOSI pin, shouldn't the CS pin stay low during all three pulses? I see that it goes up during the last byte.

                • 5. Re: Edison's SPI bus problem
                  KurtE

                  I am a little rusty here, not doing much with Edisons right now...  I have found SPI is currently problematic (complete system hang, maybe still power management from previous release...)... At least for me.

                   

                  One thing I found with some devices (in particular some TFT displays), is when you ask them for information, they are touchy when it comes to the CS pin.  That is they will stop sending back data if the CS pin is not held active during the complete transaction.  So I ended up controlling the CS pin myself.   You might give it a try and see if it works better for you.

                  • 6. Re: Edison's SPI bus problem
                    Youssef

                    Hey Kurt,

                     

                    Thanks for the reply. I have also read on other forums that I might as well keep the CS pin low if I'm not using more that 1 slave.

                    • 7. Re: Edison's SPI bus problem
                      KurtE

                      Hard to say.  Also don't know which board you have.  Example if you have the Arduino board, it has it's own DtoA converter with it's own CS, so that might get confused.  But my guess is if you are adding an AtoD, you are probably using mini board or the like.  In my cases I simply assert CS when I need it and deassert it when I don't...

                       

                      In my reading through the spidev IOCTL control stuff, my impression is the intention is that when you do a Transfer function, the CS is asserted and will stay asserted for some period of time after your last transfer.  The timeouts are configurable, also there is a field in the IOCTL structure where you can set to say to set the CS high now... But my impression from looking at the SPI code for the Edison (2.0 beta code base) was that none of this was implemented.  Not sure which if any processors actually do this.

                      • 8. Re: Edison's SPI bus problem
                        Youssef

                        Hey guys,

                         

                        Thanks for the help. I just want to make sure im on the right track here since this is my first time working with spi buses.

                        I am currently using the mini Edison board and trying to configure the needed pins to their required functions.

                        I am configuring IO11, IO12, and IO13 to have spi functionalities. In addition I am using IO2 and IO4 for Chip select and Reset outputs.

                         

                        I am running this script each time Edison turns on to do the configuration:

                         

                        echo 111 > /sys/class/gpio/export          

                        echo 115 > /sys/class/gpio/export          

                        echo 114 > /sys/class/gpio/export          

                        echo 109 > /sys/class/gpio/export          

                        echo 263 > /sys/class/gpio/export          

                        echo 240 > /sys/class/gpio/export          

                        echo 262 > /sys/class/gpio/export          

                        echo 241 > /sys/class/gpio/export          

                        echo 242 > /sys/class/gpio/export          

                        echo 243 > /sys/class/gpio/export          

                        echo 258 > /sys/class/gpio/export                             

                        echo 259 > /sys/class/gpio/export                             

                        echo 260 > /sys/class/gpio/export                             

                        echo 261 > /sys/class/gpio/export                             

                        echo 226 > /sys/class/gpio/export                             

                        echo 227 > /sys/class/gpio/export                             

                        echo 228 > /sys/class/gpio/export   

                        echo 229 > /sys/class/gpio/export         

                        echo 214 > /sys/class/gpio/export           

                        echo low > /sys/class/gpio/gpio214/direction

                        echo high > /sys/class/gpio/gpio263/direction

                        echo high > /sys/class/gpio/gpio240/direction

                        echo high > /sys/class/gpio/gpio262/direction

                        echo high > /sys/class/gpio/gpio241/direction

                        echo high > /sys/class/gpio/gpio242/direction

                        echo high > /sys/class/gpio/gpio243/direction

                        echo high > /sys/class/gpio/gpio258/direction

                        echo high > /sys/class/gpio/gpio259/direction

                        echo low > /sys/class/gpio/gpio260/direction

                        echo high > /sys/class/gpio/gpio261/direction

                        echo in > /sys/class/gpio/gpio226/direction 

                        echo in > /sys/class/gpio/gpio227/direction 

                        echo in > /sys/class/gpio/gpio228/direction 

                        echo in > /sys/class/gpio/gpio229/direction                    

                        echo mode1 > /sys/kernel/debug/gpio_debug/gpio111/current_pinmux                  

                        echo mode1 > /sys/kernel/debug/gpio_debug/gpio115/current_pinmux

                        echo mode1 > /sys/kernel/debug/gpio_debug/gpio114/current_pinmux

                        echo mode1 > /sys/kernel/debug/gpio_debug/gpio109/current_pinmux

                         

                        echo 128 > /sys/class/gpio/export

                        echo 250 > /sys/class/gpio/export

                        echo 218 > /sys/class/gpio/export

                        echo high > /sys/class/gpio/gpio250/direction

                        echo in > /sys/class/gpio/gpio218/direction

                        echo mode0 > /sys/kernel/debug/gpio_debug/gpio128/current_pinmux

                        echo in > /sys/class/gpio/gpio128/direction


                        echo 129 > /sys/class/gpio/export

                        echo 252 > /sys/class/gpio/export

                        echo 220 > /sys/class/gpio/export

                        echo high > /sys/class/gpio/gpio252/direction

                        echo in > /sys/class/gpio/gpio220/direction

                        echo mode0 > /sys/kernel/debug/gpio_debug/gpio129/current_pinmux

                        echo in > /sys/class/gpio/gpio129/direction

                         

                        echo high > /sys/class/gpio/gpio214/direction

                         

                         

                        Is this script setting up my environment correctly?

                        Furthermore, i have read in the Intel Edison Compute Model Hardware Guide that Edison may function as Master or Slave. So should I do something to configure it as Master before starting my program? In addition, to configure the SPI mode I should modify the SSP Control Register (CTRL1) for mode 1. But how do i do that? I am aware that Mraa provides a function for this matter however im not sure if im using it correctly.

                        I need Mode 1 with MSB and here is how i am initializing SPI in eclipse:

                         

                        mraa::Spi* spi;

                        spi = new mraa::Spi(0);

                        spi->lsbmode(0);

                        mraa::Spi_Mode SPI_MODE1;

                        spi->mode(SPI_MODE1);

                        spi->frequency(400000);

                         

                        Thanks,

                         

                        Youssef

                        • 9. Re: Edison's SPI bus problem
                          Intel_Peter

                          I'm sorry Youssef, I'm confused, you said you are using the Mini Breakout Board but when talk about the configurations I believe you are refering to the Arduino Expansion Board. Could you clafiry which one are you using?

                           

                          For this post I'm going to assume that you are using the Mini Breakout Board.

                          The configuration you just posted is for the Arduino Expansion Board, so if you use it, you are going to get a few errors, however that's to be expected and you can ignore them

                           

                          . You could check which of this commands are giving you an error message and delete them since they are not needed.

                          Regarding the your question about how to set SP1 through MRAA, I'd suggest you to take a look at: http://iotdk.intel.com/docs/master/mraa/classmraa_1_1_spi.html

                           

                          Peter.