GPIO connections may affect Omega operation
I recently spent a couple of hours debugging a boot problem with the Omega, and I thought it would be a good idea to pass on what I discovered.
I am using the following circuit to control high-brightness LEDs connected to the Omega's GPIO pins:
The circuit works fine, allowing around 180mA to flow through the LED when the connected GPIO pin is driven high (and 0mA when the pin is driven low). However, when the circuit is connected to GPIO1, the Omega refuses to boot when power is removed and reapplied. If the circuit is connected AFTER the Omega is connected to power, the Omega boots properly AND will reboot when the reset button is pressed. The problem only occurs when power is applied after the circuit is connected.
Each of my four Omegas exhibited the same behavior, and after I checked and rechecked my circuit and connections multiple times, I considered the possibility that the voltage level of the GPIO1 pin was affecting the boot sequence. So I checked the recently unveiled Omega schematic, and I see (on the schematic's last page) that GPIO1 apparently is being polled to see where the Omega's boot code is located. GPIO is pulled high via a 10k resistor (the node labeled "LED1" is connected to GPIO1 on page 1 of the schematic):
My circuit's impedance is low enough that the pin is at a low logic level on power-up, and the Omega doesn't boot. I haven't played with the other similarly connected nodes in the above diagram, so I can't say if other GPIO pins are also vulnerable to this problem.
I expect that this behavior will be spelled out in user documentation, but as yet I haven't seen this mentioned elsewhere.
I found this behavior as well and remembered seeing this post today.
Any official answer on this? For now, I'm going to attempt to use GPIO0 and GPIO2 and avoid GPIO1 for now. EDIT: Not GPIO2, will use GPIO6 (closest physically on the board to 1)
Further information is am finding: I moved from GPIO0 to 7 as well for my other input. GPIO0 makes the LED 'glow' when off. No bueno.
I am also seeing this issue on gpio1. Preventing boot. I also have issues with gpio8 and gpio12 which is seemingly known. This is unfortunate because I am using the omega as a remote, and I'd like as many inputs as possible.
I know this is an old topic, but I think it might be resolved now.
I was also seeing this problem affecting GPIO13 (RX0). Since that GPIO belongs to the console serial port, it meant that if I ever rebooted with my console serial adapter connected, the Omega would not boot. At that point, the only way to get control of the Omega would be to disconnect the serial adapter and then power cycle it.
I am happy to report that my issue [at least] has been fixed with the firmware release 0.1.9. After installing that firmware, my device now reboots with the serial port adapter connected. So maybe these issues are also resolved for the other GPIOs mentioned above? Perhaps someone else can confirm.
The MT7688 does indeed have its startup mode configured by "strapping" of pullup/pulldown resistors on various GPIOs - the data sheet gives details.
An additional issue is that if you connect a USB-(logic level) serial adapter, the transmit line from the computer may actually "power" the chip and board just enough (through the data line) that you do not get a clean power-on-reset when you connect the actual power source.
I labelled the pins that configure startup mode for the MT7688 in red in the annotated pinout I made some time ago for the Omega2.
I made this pinout because I found it hard to determine which pins to use for what without having the complete per-pin functionality visible at a glance, and the red labels to remind me not to connect something which can pull up or down voltage during startup. Hope it's useful for others as well ;-)
Very helpful! Thanks.