11 Replies Latest reply on Mar 9, 2015 11:48 AM by MPayne

    Trouble with GPIO 48 and WiFi

    r3n33

      Hi all

       

      I'm using the latest Yocto image and have tested multiple Edison boards.

       

      When I attempt to export GPIO pin 48 to Sysfs using the following command my WiFi connection to the Edison is broken/extremely laggy:

       

      echo 48 > /sys/class/gpio/export

       

      The only resolution I've found is to reboot the system. Is there a known issue with GPIO 48 and the WiFi?

      Can anyone else replicate this problem with a wifi/ssh terminal connection to their Edison?

       

      TIA

       

      -Renee

        • 1. Re: Trouble with GPIO 48 and WiFi
          KurtE

          not sure, but ran into issue like this when experimenting earlier with tft display on mini breakout.  I should probably go back Nd see if this was one of the pins I tried with cs or dc pins

          • 2. Re: Trouble with GPIO 48 and WiFi
            Andre.M

            are you sure you dont need to set the pin mode via pinmux and is your pin floating or what is connected?

            • 3. Re: Trouble with GPIO 48 and WiFi
              r3n33

              I do believe you must export the GPIO pin to Sysfs before you can alter the pinmux. The pin is not floating but going to the Sparkfun Dual H Bridge block as AIN1. SparkFun Block for Intel® Edison - Dual H-Bridge - DEV-13043 - SparkFun Electronics

               

              Also to note.. This behavior is observed even when the pin is floating on a mini breakout board. 

              • 4. Re: Trouble with GPIO 48 and WiFi
                r3n33

                I just heard back from Intel Support and they were able to reproduce the same issue last week. It has been reported as a possible bug and currently under review.

                 

                The timing coincides with the release of the Sparkfun Dual H-Bridge so I wouldn't be surprised if everyone with this module has a little trouble. A quarky work around I found last night was to run iwconfig after exporting GPIO 48. There will be a bit of a delay in the WiFi connection ( while something is polled/reset? ) but the connection was usable after the export thus allowing my development to move forward.

                • 5. Re: Trouble with GPIO 48 and WiFi
                  mmi

                  I have the same problem using GPIO 44 with a sketch (Edison + minibreakout board).

                  Starting the sketch, ssh connection gets lost because wifi is down.

                  A workaround is to restart wifi immediatedly after starting the sketch (i wrote a small script for this).

                   

                  This happens also with Ubilinux and Archlinux, both use the Yocto kernel.

                  • 6. Re: Trouble with GPIO 48 and WiFi
                    r3n33

                    I don't know if I should re-post on my thread since it was marked answered but...

                     

                    The problem described still exists in the 05-15 Yocto image and I'm not sure how to keep track of the issue to know if a resolution has been discovered. Will Intel post a response here or is there some webpage/code tracking system where I watch the issue?

                    • 7. Re: Trouble with GPIO 48 and WiFi
                      oloynet

                      +1

                       

                      I agree with you, a code tracking system could help to see opened issues on Edison and don't waste time with the same problems


                      For this problem (GPIO 48 - pin 7 on Arduino board), I found the issue was reported in a PDF (This can be done better)

                      Intel Edison Board Support package PDF revision 007 on February 2015 linked from the Intel Edison board software download

                      • 8. Re: Trouble with GPIO 48 and WiFi
                        r3n33

                        Thank you oloynet!

                         

                        For linking the document and answering my question. Now I know to check the BSP release notes in the future. That will definitely save me some time down the road.

                         

                        =)

                        • 9. Re: Trouble with GPIO 48 and WiFi
                          MPayne

                          There are some changes on the way that I think will address some of this.

                           

                          More to the point of this issue: I show it as being fixed in the mainline, though it is after we made release 2 public.  It should be available in the next release.

                          • 10. Re: Trouble with GPIO 48 and WiFi
                            KurtE

                            I hate just jumping on band wagon, but again it would be nice to know which things are fixed and how soon can we expect a drop that includes them.

                             

                            Example SPI issues - Both delays in bytes as well as new issue with power management.  Can we expect a drop soon that will address some of this, or should I punt for now and for example if I wish for TFT output, use a secondary processor like Teensy 3.1 (or LC)...

                             

                            As others have mentioned, When we post something like a new bug, where there is a response like, it has been reported to developer.  The thread is marked as answered.  Instead it would be good if it was marked as some other state like, Pending or ... And it is later marked as Answered, when really the answer may come a lot later (fixed in release...).  Obviously a better approach would be to have something like github issues like web site, where the issue is entered and there is status information, like, status , maybe some type of priority,... And then the forum messages, could be answered as this is now issue # xxx .

                            • 11. Re: Trouble with GPIO 48 and WiFi
                              MPayne

                              Yes, I agree.  I don't think you're bandwagoning - it's a valid issue to me as well.  I'm confident the work we are implementing right now is going to address a lot of what you are talking about.  The unified installer is an example of one such pain point that the community requested to be solved, and that we are beginning to roll out post release 2.  There are more on the way, but I can't be specific until a couple more approvals happen.  I recognize your frustration and also the irony of me saying I can't be specific right now.  I am confident it will be solved very soon.

                               

                              The SPI latency stuff - again, I agree.  This one I have been personally pushing on (I have even talked to a few of you one on one about it).  I am also confident on this one getting fixed very soon, but I'm bound by the same problem of the previous paragraph (we need a couple more internal commitments before we can talk about it and/or commit to the public).

                               

                              Don't worry about giving us honest feedback.  There are lots of folks across multiple teams who watch these forums and enact plans to address issues.  It helps the process more than you probably think it does.