Omega2+ Shuts Down and Doesn't Restart
-
My project requires having an Omega running for a long time uninterrupted. However, after running some python scripts for a day or so, my Omega2+ will "shut down". I can't access the Wifi AP and the LED is off.
I'm powering the Omega using one of these AMS1117 boards https://www.aliexpress.com/item/USB-micro-5V-3-3V-AMS1117-USB-3-3V-3-3V-module/32654618916.html?spm=a2g0s.9042311.0.0.2a834c4d0C2XhB
The Omega successfully gets through boot up and starts the scripts with no problem. I know it might be a power related issue but shouldn't the Omega restart after losing power? Is there a way to force the Omega to boot back up after a loss of power like this?
-
@Collin-Palmer You're not alone. I've delivered four systems to a client that will be deployed on buoys. I've observed this phenomena on several subsystems, and it scares me. My systems will run weeks to months prior to O2+ shutdown.
My fully assembled systems use Expansion Docks (ED - don't laugh!), however I've also observed this while using a Breadboard Dock (BD). I'm considering using the BD as a device on which I'll monitor serial port 0 from another device and wait and wait and wait. When the day arrives, observe the last messages sent out of the device to the monitoring device.
I've considered building a monitoring circuit into the system that will determine when current flow stops resulting in a relay (or FET) opening and closing to restart the O2+. However, this is for a client that wants 24/7/365.25 operation and every new device I add that uses the precious battery charge is evil.
--Bill
-
@Collin-Palmer There was another very interesting thread that may apply to your situation. See it here --> http://community.onion.io/topic/2482/omega2-losing-power-powering-off-unexpectedly
--Bill
-
Wrong choice on that AMS1117 based power supply, especially if you get it from Ali or fleaBay. They lack the output BIG capacitor and/or the output wiring/connector to Omega2+ is insufficient.
-
maybe create a method to data log the power [volt/amp] supplied to the omega2. you would then have a record of what was being supplied immediately prior to shutdown. maybe heat build up over a day or so affect the output of the power supply. maybe the script you are running affects the load on the omega2. i suspect that 200mA max of supply [if it is that] might be not enough under some conditions. maybe what ever you are using to supply power to the board is turning off/sleeping at some point because the omega2 is not using enough current.
-
Agreed, and I plan to add a big cap on the regulator output and make better connections between the regulator and the Omega in the next version. But shouldn't the Omega reboot after a momentary loss of power?
-
No, Omega2 will freeze when it encounters the brown-out condition. It has something to do with its internal SPI EEPROM initial 3-byte/4-byte boot configuration.
BTW, that Aliexpress link's AMS1117's 200mA spec is not good for Omega2.
-
@Collin-Palmer If you've ruled out that it's not a hardware issue...
Are you using Onion firmware or custom firmware?
I ask because the Omega2+ specifically needs a patch in order to be able to power up again after being restarted. See the patch here: https://github.com/OnionIoT/source/blob/lede-17.01/target/linux/generic/patches-4.4/481-mtd-add-spi-flash-reset-code.patch
-
@Collin-Palmer said in Omega2+ Shuts Down and Doesn't Restart:
my Omega2+ will "shut down". I can't access the Wifi AP and the LED is off.
If you find your board in the state you described again, before you do anything with it try probing the SPI lines with a logic analyzer. If you see activity it means that your Omega2+ suffered an unexpected reboot and the SoC primary bootloader is trying to load U-Boot using 3-byte addressing, but the SPI flash is still configured to use 4-byte addressing. (refer to Omega2 reboot for more info on this issue). If this is the case you have to power-cycle the board in order to get it to boot again (which resets the SPI flash addressing to 3-byte mode)
