10 Replies Latest reply on Sep 21, 2015 6:52 PM by malder

    Edison GPIO boot up configuration

    malder

      Hi

       

      We are starting to use the edison in a range of products, and so we have started producing our own breakout boards. Some generic, some application specific.

      We are ramping-up our first couple of designs but the fact that the GPIO pins have different power-on states is causing some major headaches!

       

      The documentation seems to say (it's not clear at all) all pins are a Hi-Z input on power up.

      That seems to be case - but only 5ms after power on the pins are configured for different purposes.

      We've found some pins are configured for SPI. Some are outputs. Most are inputs but some have pull-downs etc.

       

      The fact the pins have different states while Linux boots makes designing different products around it very difficult. It severely limits what we can use the pins for.

      Furthermore I don't have a lot of confidence that the states won't change as Intel release other breakouts etc.

       

      I assume the 5ms delay means the micro is configuring the pins and I'm hoping it's using some configuration stored in memory.

      So my questions are:

       

      1) What determines the boot-up state of the pins. Is it hard-coded in the micro? Or is it configurable somehow?

      2) If the former, is it at all possible to get a micro image without that? Or to get the source to build our own?

      3) If the latter, how can we change this configuration?

       

      I understand this won't be simple.

      But we have invested a lot of time (very frustrating time) into designing around the edison. And we are gluttons for punishment.

        • 1. Re: Edison GPIO boot up configuration
          PabloM_Intel

          Hi malder,

           

          Some other users have reported this before. The explanation to this is that digital pins are shared by different interfaces (as you pointed out) through muxing, which makes them behave differently at startup when interfaces are loaded during kernel startup. Right now this is being investigated and as soon as I have a more accurate answer to your questions I’ll let you know.

           

          Regards,

          PabloM_Intel

          • 2. Re: Edison GPIO boot up configuration
            malder

            Thanks Pablo,

             

            I'm looking forward to your answers.

            • 3. Re: Edison GPIO boot up configuration
              malder

              Is there any progress on this issue? we have a product which can't be released until we solve this problem.

               

              The pin state changes 5ms after power-on, which suggests to me the micro is making the change, but I'd like to know if it is configurable or hard-coded.

              This would be happening before the kernel starts to boot up wouldn't it?

              • 4. Re: Edison GPIO boot up configuration
                PabloM_Intel

                Hi malder,

                 

                I would suggest to customize the standard Linux image, you’ll need to exclude the packages that you won’t be using and just use the ones you’ll definitely need, in your case the ones related to the GPIO configuration. Then when you’re building the image, you can de-activate the drivers you won’t be using with your module via the menuconfig tool.

                You can check the Edison Board Support Package for further instructions, there you’ll find how to add or exclude packages from the image.

                 

                Intel Edison Board Support Package.

                 

                Regards,

                PabloM_Intel

                • 5. Re: Edison GPIO boot up configuration
                  malder

                  Hi PabloM,

                   

                  I've been trying to go through the kernel source without much luck.

                   

                  I think I have found the files where the GPIO is initialised but they are not included in the source download.

                   

                  specifically the directories...

                   

                  \i586-poky-linux\u-boot-fw-utils-2014.04-1-r0\board\intel\

                  \i586-poky-linux\u-boot-fw-utils-2014.04-1-r0\cpu\tangier\

                  \i586-poky-linux\u-boot-fw-utils-2014.04-1-r0\asm\arch-tangier\

                   

                  etc are all missing.

                   

                  I'm no Linux expert - am I missing something?

                  Is it possible to get the full u-boot source used to build the firmware image?

                  • 6. Re: Edison GPIO boot up configuration
                    malder

                    I was wrong...

                     

                    It is the IFWI bootloader which initialises the GPIO pins. Unfortunately the source does not appear open - is that correct?

                     

                    If not, perhaps you can direct me to some information regarding the SFI configuration.

                    It would appear that the IFWI bootloader uses this to know which drivers to initialise. Can I use the SFI tables to stop the IFWI from initialising the GPIO pins until the kernel loads?

                    • 7. Re: Edison GPIO boot up configuration
                      malder

                      Intel is giving no help at all...

                      I called their office to see if there was anybody I could talk to about the Edison. The reply was, literally, "I'm sorry, but it's company policy not to release that kind of information" !

                       

                      Pablo, in desperation I tried your idea. I compiled a custom image with every extraneous driver and module disabled, and it had no effect on the boot up state of the GPIO pins. No surprise there.

                       

                      We've confirmed it is the IFWI firmware setting the initial state of the pins. But without the source there is nothing we can do to change it.

                       

                      For anybody else starting their design with the Edison, these are the initial states of the GPIO pins (without alternate functions)...

                       

                      GP44: Input with 50K pull-up

                      GP165: Output low

                      GP14: Input with 50K pull-down

                      GP15: Input with 50K pull-down

                      GP45: Input with 50K pull-down

                      GP46: Input with 50K pull-down

                      GP47: Input with 50K pull-down

                      GP48: Input with 50K pull-down

                      GP49: Input with 50K pull-down

                       

                      The mini breakout board user manual has a table which maps these pins to the appropriate headers. There is a column in that table which seems to list alternate functions for these pins (e.g. Accelerometer or gyro interrupts). It would appear that these references might explain the initial state of the pins.

                       

                      But as far as I can tell, they don't belong to the arduino break out or the mini breakout so they must be for some other breakout board/product? Perhaps the phone hinted at in other docs?

                       

                      As far as we are concerned our solution is two-fold:

                       

                      1) Abuse the pins with a super-strong pull-up (5-10K) so they behave as we need them to at start-up.

                      2) Hope Intel doesn't change the IFWI firmware (unless it's to make everything input high-Z).

                      3) Phase out the Edison and go to something else.

                      • 8. Re: Edison GPIO boot up configuration
                        malder

                        OK - this story gets even better...

                         

                        The GPIO states listed in the last post are the state of the pin from 5ms after power up. So on the Edisons I have been testing with, the GPIO has been:

                         

                        0ms to 5ms - Input high-impedance

                        5ms onward - as listed above.

                         

                        But I've just run across one edison which does the following:

                         

                        0ms to 5ms - Input with 2K pull-down

                        5ms onward - as listed above.

                         

                        And one other edison which has the 2K pull-down intermittently. Half the time it is a strong pull-down the other half it is high-impedance.

                         

                        So for the GPIO states - the first 5ms seems to be unpredictable, and the following 30 seconds is uncontrollable!

                        • 9. Re: Edison GPIO boot up configuration
                          PabloM_Intel

                          Hi malder,

                           

                          Unfortunately, the SFI tables and the IFWI cannot be made available to the public given that it’s not open source. As a suggestion, a hardware workaround may be possible by buffering the devices from the GPIO with a muxing that has a delayed select.

                           

                          Regards,

                          PabloM_Intel

                          • 10. Re: Edison GPIO boot up configuration
                            malder

                            Hi PabloM_Intel,

                             

                            Yes - that's what we are looking at - a new board design.

                             

                            We considered using another GPIO pin to control a mux on the level shifters but since we can't trust the GPIO state at startup that doesn't work. A timer could work but it's ugly.

                            Frankly, since we can't use the GPIO pins - we would be better off just putting a micro on the I2C bus and using it for all the I/O. It would give us a full speed SPI bus, extra I2C, heaps of I/O etc...

                             

                            The Edison just becomes something that runs linux and acts as a bridge between the rest of our network and the micro which handles the hardware.