14 Replies Latest reply on Feb 26, 2015 9:50 AM by KurtE

    SPI (Adafruit 2.8" TFT) not working on R2 Beta - Arduino breakout board

    KurtE

      As I mentioned in the main R2 thread, my Adafruit ILI9341 based displays is not working properly with the R2 Beta.  There appears to be differences on how the signals and the like start up.

       

      I found this true with all three versions of code (Arduino, native MRAA compiled code on the latest mraa, and Eclipse code compiled and remote debug again using MRAA).

       

      I found neither the display code starts up properly (screen blank), but also the Touch screen code (STMPE 610), also failed to init.   I think I have the STMPE (locally) maybe fixed, but it took doing a transfer of (0) without the CS selected, in order to get the clock signal back to a known state.  That is before that when I started the first transfer to get the version, the clock would do one transition from high to low, which signaled the first bit and then nothing, but the device saw this and got completely misaligned.  So making sure that CS was not asserted and then output 0, fixed it...

      SPI = mraa_spi_init(0);   // which buss?   will experment here...
      mraa_spi_frequency(SPI, 1000000);
      mraa_spi_lsbmode(SPI, false);
      mraa_spi_mode(SPI, MRAA_SPI_MODE0);

       

      m_spiMode = MRAA_SPI_MODE0;

       

      _gpioCS = mraa_gpio_init(_cs);
      mraa_gpio_dir(_gpioCS, MRAA_GPIO_OUT);
      CSHigh();

       

      mraa_spi_write(SPI, 0x00);

       

      // try mode0
      if (getVersion() != 0x811) {

       

       

      This required adding the transfer.

      So far that has not worked yet to get the display working.  May be issue with current MRAA and beta where you create an SPI object and it assumes you are going to use the CS pin.  But if you are going to use 2 devices, this can not work.  Fix before was to after create SPI object for display, was to create a GPIO object for the CS pin, which mapped it back to mode0.

      But to make this work, have to create SPI object for touch device first (who sets up stuff) and while doing so, asserts the displays CS... Then I create the display SPI which hopefully fixes it.  If I create display first then the SPI one will screw things up.  Want two SPI objects, as they each have their own speed...

       

      arfoll - Would be nice to be able to create SPI object without initing CS pin.  Could use mraa_spi_init_raw but that assumes I know exactly the hardware...

      Options:

       

      create a new mraa_init_spi_software_spi() - which does not initialize the CS pin.  Would need to modify the hardware call off for init pre to pass flag though

       

      Add call to say: mraa_spi_disable_cs() - who knows the cs pin for the spi and switches back to gpio mode.

       

      Add call to query the CS pin and caller does what is necessary... Like if it ain't theirs, revert back to GPIO mode...

       

      I prefer first option as it should create cleaner signals.  Will probably try out on my own new branch and if it helps, issue pull request.

       

      May be a few days, also trying out prototype Teensy LC ($11 Teensy will release next month), would like to get their faster ILI9341 driver working on it and see how close can get the speed to their $19 Teensy 3.1 which is an order of magnitude faster than on Edison.  Would need to look it up again but probably at least 30 times faster?

        • 1. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
          Stan_Gifford

          Hi Kurt, I have not had time to look any deeper as yet but I find that the OLED I tested via arduino code under previous release now no longer works under R2.

           

          I havn't had a chance to investigate further (in case it is a 'Some klutz (me) dislodged a hookup cable' problem).

           

          When I say no longer works, previously the OLED would work - just very slowly - now I get absolutely nothing!

           

          Did your Adafruit ILI9341 work with previous version?

           

          All the best

           

          Stan

          • 2. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
            KurtE

            yyes was working until reflashe'd

            • 3. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
              Stan_Gifford

              That's Kurt for that.

               

              The big question then (directed to Intel guys) is. According to the release notes, any improvements to SPI did not make it in this release - however based on Kurt's and my observations, something changed in SPI because code that worked before now does not work (unless a MRAA change has snuck in???)

               

              Reason I mention a MRAA change is that a while back there was a MRAA release that nuked I2c - wonder if same thing may have happened.

               

              Stan

              • 4. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
                KurtE

                My guessing is that SPI is probably screwed up somewhere internal for this build.  Or some process is doing something in particular to the SPI clock pin during this release.

                Could someone at Intel Please take a look at this!

                 

                What appears to be happening, is at the beginning or after nothing has been output to SPI for a bit of time, the first byte appears to be screwed up.  That is if you look at the Logic Analyzer output for part of the init for the Adafruit.

                Edison SPI beta2 - 1.jpg

                You can see some of the start up.  The first blip on the left is when I tried outputting a 0 at the beginning without CS selected to get the clock right then...

                Then I start the display init.  The code then delays a bit (.12 seconds), then tries to turn the display on.

                 

                Within the groups, the outputs appear OK.  Example:

                Edison SPI beta2 - 2.jpg

                But then after the delay, when it tries to output the turn the display on (0x29), the clock bit gets screwed up as you can see below:

                Edison SPI beta2 - 3.jpg

                I did not double check the bytes after this in that group, but I think they are correct as it is able to query some of the displays parameters right after this.  Note in the first image, the 2nd marked gap in time, the first byte there appears to be screwed up again in the same way, where the clock is simply held high during that cycle.

                 

                I will double check that some of the stuff I am doing in between is now screwing things up, but it was working fine before I updated to the new release, and it is not working with either my MRAA nor my Arduino code bases, so I am pretty sure it is the release.

                 

                Kurt

                 

                Edit: Note: in case it helps, I do bracket places in my SPI code base (that these came from) with a Begin/End Transaction like calls, that might keep an internal mutex, such that if I have multiple threads, trying to talk to SPI (example the display and the touch screen), only one can at a time.  Also the begin also tries to make sure that SPI is in a valid state for it.

                So it includes:

                
                
                
                
                mraa_spi_frequency(SPI, SPI_FREQ);
                
                
                
                    mraa_spi_lsbmode(SPI, false);
                    mraa_spi_mode(SPI, MRAA_SPI_MODE0);
                
                • 5. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
                  JPMontero_Intel

                  Hi KurtE,

                   

                  We will take a look at this behavior. Thank you for reporting this.

                   

                  Regards,
                  JPMontero_Intel

                  • 6. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
                    KurtE

                    Thanks JPMontero_Intel,

                     

                    I am sort of wondering if it might be power management stuff.  That is, the driver file: intel_mid_ssp_spi.c, I notice these lines were added in this release:

                    (about line 1590):

                     

                    
                    
                    
                    
                    pm_runtime_set_autosuspend_delay(&pdev->dev, 25);
                    
                    
                    
                        pm_runtime_use_autosuspend(&pdev->dev);
                        pm_runtime_set_active(&pdev->dev);
                        pm_runtime_enable(&pdev->dev);
                        if (!pm_runtime_enabled(&pdev->dev))
                    
                    
                    
                       
                     dev_err(&pdev->dev, "spi runtime pm not enabled!\n");
                    
                    
                    
                    

                    I have built the image, and it runs (on my mini board).   Will try to ifdef these lines out and see if the functionality changes...

                     

                    Probabably tomorrow...

                    • 7. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
                      KurtE

                      Not sure now, I built the kernel (no changes) flashed it on my Edison with Mini breakout board, and it is not showing the same stuff happening on the SPI line.  I have not reset it back up yet to use level shifters and hook up to display yet.  So not sure if the lines I mentioned above?  Or maybe something with Arduino board, like the AtoD processing?

                       

                      Maybe should try to reflash the one on the Edison.  Would be nice to do without full Flashall, which deletes everything.

                       

                      Edit: I reconnected a display up to the Mini Edison breakout board.  (PJRC Store)  Which is a nice cheap $8 version of the ILI9341 display and confirmed that

                      it is running fine on this board.  Guess I need to verify again on Arduino board.

                      • 8. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta
                        KurtE

                        Another update: I updated my Arduino board with the same kernel I built that worked on the mini breakout board.  Same problem after.  So it appears to be specific to Arduino board.  Maybe how SPI is used for other stuff?

                        • 9. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta - Arduino breakout board
                          KurtE

                          Questions that I am trying to understand:

                           

                          I know on the Arduino breakout board there is an ADS7951 chip that does the A2D conversion.  I know the chip is connected to the Edison through SPI (cs0),  Which driver is this?  Also is there other kernel code pieces that interact with it?

                           

                          I understand that there is a set of Muxs on the Arduino board, that connect either the SPI line or a different GPIO line to the IO lines that make up SPI (10-13), so if these pins are not configured to do SPI, the signals on these pins will not change... They obviously could not simply use ones line GPIO109 to these pins and when standard IO pin leave as mode0 as the A2D  would need this as Mode1 to work, which would cause the signals on the Arduino pins 10-13 to change...

                           

                          The A2D driver, does it only do stuff to SPI pins when the user calls to do an AtoI converson?  Or do things happen for other reasons?  If other reasons, will be interesting to see how that interacts with other devices using non hardware CS pins.

                           

                          Still learning!

                          • 10. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta - Arduino breakout board
                            David_J_Hunt

                            Kurt,

                               The ADC driver is the ADS7955 driver, TI_ADS7955_ADC in the kernel config. The driver file is drivers/iio/adc/ti-ads7955.c. You could try disabling it in your kernel config and test, but I don't believe it does anything on the SPI bus unless an ADC read is requested...

                            Rgds,

                            Dave.

                            • 11. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta - Arduino breakout board
                              KurtE

                              Thanks, I may have to try this.  As far as I can tell, there have not been any changes to the ADC files for this build.

                              I downloaded zip files from HippieHackers github of the kernel, for both versions and am using meld to compare, which is pretty nice.

                               

                              Not sure yet best next test.  Maybe revert back some of the spi files.

                              Like there is a one line change to platform_spidev.c

                              There are changes in intel_mid_ssp_spi.c, like:

                              writing/reading another register (SSCR2) about some delay if speed_hz > 625000

                               

                              Also how CS is asserted. (I think to handle CS can be high or low active)

                               

                              More interestingly: The pump messages function, works differently at end talking about suspend as well as the probe function also added some autosuspend calls... 

                              • 12. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta - Arduino breakout board
                                KurtE

                                tried backing out partial change in

                                +static void pump_messages(struct work_struct *work)

                                +#ifdef KJE  

                                +    pm_runtime_mark_last_busy(dev);

                                +    pm_runtime_put_autosuspend(dev);

                                +#else

                                +    pm_runtime_put(dev);

                                +#endif      

                                 

                                likewise in: intel_mid_ssp_spi.c

                                +static int intel_mid_ssp_spi_probe(struct pci_dev *pdev,

                                +    const struct pci_device_id *ent)

                                 

                                +#ifdef KJE

                                +    pm_runtime_set_autosuspend_delay(&pdev->dev, 25);

                                +    pm_runtime_use_autosuspend(&pdev->dev);

                                +    pm_runtime_set_active(&pdev->dev);

                                +    pm_runtime_enable(&pdev->dev);

                                +    if (!pm_runtime_enabled(&pdev->dev))

                                +        dev_err(&pdev->dev, "spi runtime pm not enabled!\n");

                                +#endif

                                +    pm_runtime_put_noidle(&pdev->dev);

                                +    pm_runtime_allow(&pdev->dev);

                                 

                                Built and flashed.  SPI appeared to hang out to dry.   Reversed ifs and rebuilt/flash and spi continued, but with same issue

                                • 13. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta - Arduino breakout board
                                  KurtE

                                  Ok I am more sure that this is power management issue.  Today I tried changing:

                                  drivers/spi/intel_mid_ssp_spi.c

                                   

                                  changed the function: intel_mid_ssp_spi_probe

                                  The line:

                                  pm_runtime_set_autosuspend_delay(&pdev->dev, 25);

                                  to

                                  pm_runtime_set_autosuspend_delay(&pdev->dev, 500);

                                   

                                  Now when I run my Eclipse version of graphic test it comes up.  Stil misses some characters, probably some other timeout...

                                  But my guess is that Suspend/Resume is happening and probably need to do something when resumed...

                                  • 14. Re: SPI (Adafruit 2.8" TFT) not working on R2 Beta - Arduino breakout board
                                    KurtE

                                    JPMontero_Intel and Tingleby@Intel

                                     

                                    Questions about SPI with this beta:

                                    a) as I mentioned in above post, there is a power management issue with the SPI (Only seeing on Arduino board?) where first bytes get eaten if nothing has been output for awhile.  I will try changing my above from 500 to some real large number.... See if that works for now. But probably need something.  Maybe the resume function needs to either delay?  Or set some state or output a null character.... To get the SPI pins in the right state.

                                     

                                    b) I think there is some support in the drivers for the spidev requests to say if it should touch CS line.  Would be good to add a transfer function to MRAA that allows the caller to pass this in.  Note: not sure if underlying system will keep track of this, that is if I assert I want pin 10 to remain asserted, will ADC know this and wait until I release it?

                                     

                                    c) As far as I can tell nothing that special about the CS pin associated with spidev.  It look like in platform_spidev.c that is simply sets/clears an IO pin (111).  Could more of these be created?

                                    Example for TFT display Adafruit uses Arduino pin 8 for 2nd CS pin,  Could we create a second spidev object that for example uses pin(49?),  Where else would we need to define this?  Maybe a pin table elsewhere that says mode 1?

                                     

                                    Just thoughts.

                                    Kurt