When connecting GPIO’s to a Relay control board such as the Freetronics 4 Channel Relay Driver the Gli fails to boot.
After doing some analysis of what is happening on boot, I can see that when power is applied to the GLi router the GPIO pins default Output High, there is 2.7V present at each pin before the boot sequence pulls them Low.
My question is, are the pins defaulting High at the hardware level or is it apart of the boot sequence that they default High and are pulled Low somewhere during the remainder of the sequence?
My other question is, why if the GPIO pins is High on startup and connected to a MOSFET (the driver board) does the GLI not finish its boot sequence? I was thinking it’s to do with current draw, although it would be a small draw I have noticed that the boot sequence is effected more (almost no LEDs are present) when all four of the available GPIO’s are connected to the driver board. However after trying to prove or disprove this theory I was testing the board voltage and noticed that with or without the GPIO connected the board held the same voltage so that tells me that it’s not a current draw issue but I could be wrong.
Hopefully someone has put the GPIO’s to use and can point me in the right direction.
Also another question I have been trying to figure out is what are the 5V and 3.3V output specs i.e. how much current can each output provide.
I have tried multiple driver boards now and with the GPIO’s connected on startup the device fails to boot, if I connect them after the boot sequence is finished everything works fine and I can use the GPIO’s as desired.
So after continuing my fault finding I have found that I can access the Gli Gui etc via the WiFi interface and the Tether works as expected however I cannot get connectivity through the LAN Port. The LAN Port connectivity is what I need to be working for my current project.
When testing this issue with an LED in place of the MOSFET, the router functions normally, the only difference electronically between the two is that the LED is ~ 11M OHMS and the MOSFET is ~ 11K OHMS between the Gate and Drain.
Any help would be greatly appreciated as I cannot understand why having a GPIO connected to a MOSFET on startup would cause a Network Interface to not initiate.
Do you have a resistor between the port and the mosfet? If not, the mosfet gate acts as a capacitor as the mosfet switches on, so there can be a large current flow for a short time. That might cause the issue you are seeing?
I have the schematic of the board that I want to use and it does have a 1k resistor before the mosfet but it also has a 10k resistor between the 1K resistor and the Gate to earth which makes sense as I’m seeing 11K to earth when testing between input(x) and earth. Do you think removing the 10K resistor would stop the current draw on startup?
After doing some reading on the requirement of the resistors before the MOSFET and what function they provide, I’m more than assuming that I cannot remove them, however, I’m thinking that if the resistor to ground was say a 1M instead of 10K, that could fix my issue and still provide the protection from all the factors that may cause a voltage to be present at the gate during a GPIO Output Low state.
We ran into something similar when prototyping our own project. Main issue is that the GPIOs are hardwired as configurations for the bootloader as @alex_zheng pointed out. For a full explanation, google the AR9331 datasheet and you’ll find the definitions of what those GPIOs are used for detecting (memory type, etc).
Now key part is you are trying to drive relays, so essentially you’re only using the GPIOs as outputs. In our case we had two GPIOs as outputs and two as inputs, which made things far more complicated as we could not guarantee the state of those inputs at the time of power up.
Since you’re only using them as outputs, all you need to do is a) make sure you put isolation between the AR150 and your actual relay driver and B) be aware that your relays may be in unexpected states from the time the AR150 powers on until it finishes booting and your code can cleanly set the GPIOs as required.
A is easy. If you have no electronics experience at all an opto-isolator would be the easiest way to go. They are cheap and plentiful. For example something like this: Opto-Isolator board
They’re basically ICs with an tiny LED and photo-transistor inside. So from the AR150’s perspective it’s just driving LEDs which you said yourself has already been proven to not be an issue.
If you need to minimize B, you can also do that by recompiling the kernel to set the GPIO states for you. In our tests we found doing it this way made the proper states come into effect within about 1-2 seconds of power on, where as waiting for user code took about double to triple that depending on startup script ordering and what else had to be loaded first.
As I run into the same problem: In my case only GPIO14 was causing the boot problems:
When GPIO14 is connected with the relay driver board during power up, the AR150 will not boot, the serial console does not show any output. When I disconnect the pin, power up the device and connected it again everything works as expected – but the system is not really reboot safe…
Also I looked into the AR9331 datasheet and could not find any reference to GPIO14 regarding detecting memory type or similar.
