10 Replies Latest reply on Feb 25, 2016 5:20 PM by nsrb

    Edison SPI Issues

    EasyAs314159

      I have a custom board I am working with that feeds SPI data from the Edison to an LED driver on the Edison's CS0. However I am not seeing any data being fed to the LED driver and the CS0 line appears to be completely inactive. My code is as follows and generates no runtime errors:

       

      import mraa

      spi = mraa.Spi(0)

       

      txbuf = bytearray(1)

      while True:

      for x in range(256):

      txbuf[0] = x

      spi.write(txbuf)

       

      The SPI lines feed through an ADG3304 (http://www.analog.com/media/en/technical-documentation/data-sheets/ADG3304.pdf) and the LED driver is operating at 3.3V. I have already tested the LED driver with another SPI master and it is working correctly.

       

      Does anyone have any ideas on what might be the issue?

        • 1. Re: Edison SPI Issues
          Frederick Blais

          Are you using any level translator? (for the 1.8V on Edison to 3.3V for your SPI device)

          I suppose you saw this example : mraa/spi.py at master · intel-iot-devkit/mraa · GitHub

          Is it possible for you to test shorting MISO and MOSI for tests? (maybe hard if everything is soldered on your board)

          • 2. Re: Edison SPI Issues
            EasyAs314159

            I am using an ADG3304 to level translate between the 1.8V and the drivers 3.3V. Also since I forgot to mention it in my first post I am running mraa v0.6.1

             

            The test code I wrote was based on the SPI example in the github repo.

             

            I removed the level shifter and installed a jumper between the MISO and MOSI lines on the 1.8V side coming from the Edison and the mraa/spi.py example generates the "We have an error captain!" message.

             

            Also just out of curiosity I thought I would try bitbanging the SPI however I can't seem to access GPIOs 109-111, 114, or 115  via mraa so I'm wondering if that is a symptom of a configuration issue somewhere?

            • 3. Re: Edison SPI Issues
              Frederick Blais

              I have an Arduino breakout and a custom board, I'll do tests on both tonight and tell you what I got.

              • 4. Re: Edison SPI Issues
                arfoll

                If you get nothing on spi likely the muxes aren't set correctly or the pinmode is incorrect. Why that would be is interesting, is your custom breakout very special? Can you try on the standard miniboard or arduino breakout just to confirm first?

                 

                If you want to bitbang (not a good idea) you need to use either gpio_raw in mraa or better use the mraa numbers eg 114 -> mraa 24  - handy conversion table here - https://github.com/intel-iot-devkit/mraa/blob/master/docs/edison.md.

                • 5. Re: Edison SPI Issues
                  EasyAs314159

                  There is nothing particularly special about the board we are using, the SPI pins on the Edison go straight through the level shifter to the driver.

                   

                  I set the Edison up to treat CS0 pin as a Gpio pin and toggle it on and off and it looks like there may be an issue with my level translator. On the +1.8V side CS0 flips between 1.4V and 1.8V which suggests the Edison is having trouble driving the pin low. On the +3.3V side I am seeing a constant 0V.

                   

                  I am going to read through the datasheet for the level translator and see if I am missing something.

                  • 6. Re: Edison SPI Issues
                    Frederick Blais

                    I managed to get the spi.py test working with my Arduino board by shorting MISO and MOSI. I'm also running version 0.6.1. I had 0.5.2 at first but it did not work with that version.

                    spi = mraa.Spi(x)

                    x is supposed to be the bus number. However I can put any number there and it still works.

                     

                    I also have a custom breakout board with only VSYS and GND connected. MISO and MOSI are shorted at 1.8V straight out of the DF40 connector and it works too. I think that your problem is not related to SPI. Do you have the Arduino or Mini breakout to test your Edison module?

                    • 7. Re: Edison SPI Issues
                      arfoll

                      Yup there's only one CS/bus on edison so we basically chuck the argument out of the window. There should be a small INFO message in syslog telling you that you asked for an invalid bus num.

                       

                      EasyAs314159 just don't do that on the arduino breakout and then do an Aio read... hardware CS is there for a reason!

                      • 8. Re: Edison SPI Issues
                        nsrb

                        Have the same issue, logic Analyzer shows that CS0 is inactive when transaction are running. If I init CS as GPIO and control it manually it works but in this case SCK have one addition clock, some long paused period. I think that hardware CS will pulled down after this clock, but how to make hardware CS0 work?

                        I tried  init with mraa.Spi(0), mraa.Spi(1), mraa.Spi(2) - nothing help CS still not works.

                        My SPI init is:

                         

                        spi = mraa.Spi(0)

                        spi.bitPerWord(8)

                        spi.frequency(int(SPI_FREQ))

                        spi.lsbmode(True)

                        • 9. Re: Edison SPI Issues
                          nsrb

                          Ok, I digged into sources of mraa and understood that for controlling CS0 should be file /dev/spidev5.0, but I have only /dev/spidev5.1 , but I routed only CS0 on my board =( because I thought default should be 0

                          • 10. Re: Edison SPI Issues
                            nsrb

                            Ok I soldered FS0 and FS1 to solve issue. Please write somebody when CS0 will be supported