@Allison-K my technical knowledge is not enough to do all this. Do you have an 'opkg install gpio' for your package that will allow gpio to work with Python3 automatically without all your fixes ? Inexcusable Omega not providing this.
The LD1117S33 (if authentic) needs minimum of input 0.1uF and output 10uF capacitors.
Also, do not use thin power supply wires. I recommend minimum of 22 Ga.
Okay, I added 47uF and 220uF capacitors to my circuit (on Vin and Vout of the LD1117 respectively) and swapped all the wires for 22 gauge. And... it works! Boots up completely and was able to setup wifi through web config and so on. Thank you!
Resolved with wifisetup
Connected to PuTTy via USB and did wifisetup
Everything is back to normal, except for DNS issues.
It does not recognize omega-xxxx.local. I have to enter IP addresses. I can live with that for now.
@Tiago-Couto I looked over your log file. Your kernel panic is happening ~31 seconds, just as the Wifi is turning on - this is at the time of the Omega's highest power load. How are you powering the Omega2+, ie what is your power source and how is the Omega2+ wired to the source?
The worst part is that sometimes they work, sometimes they don't.
That's the problem I have with my 2+'s wired up to AMS1117's. They will normally run for 24 to 36 hours and then fail. Don't know if they get too hot, run out of memory or receive a power spike. When I reboot them sometimes they boot up and sometimes they don't. If they don't bootup after a few tries I leave them for perhaps 30 to 60 minutes and generally they do bootup. Bit of a mystery.
My Omega 2+ had a similar problem in that it would not reboot after it had been running a while (10 or 15 minutes was enough). After sitting unpowered for a while, it would happily boot again and run without apparent issue.
Guessing that there was an intermittent thermally sensitive connection somewhere on the board that affected start up, I reflowed the solder on all exposed connections with an SMD hot air tool and the problem seems to have gone away. So with a sample set of one, it looks like a manufacturing defect in my case.
My Omega 2 (not plus) didn't have this particular issue.
Both had problems during boot when running from inadequate power. The symptom of that problem is running normally through startup, as monitored on the serial port, to the point where wifi was first brought up, about 18-20 seconds into the boot sequence. At that point they would reset and repeat this process indefinitely.
Hopefully the OP will not mind if I widen the scope of this thread a little.
I saw a post that referenced "safe mode" and "dd". I have used dd previously with Pi's but I haven't been able to find details of the Omega in Safe Mode.
Now we have SD cards working could someone advise the procedure for cloning our Omega's as I hate the way the upgrades work and I'm confident many users will be wasting lots of time restoring work they have already done.
I have a serious serial I/O problem that has me baffled. I just picked up on a tidbit in your final paragraph. In reference to the first Omega serial port it is at a 3.3V level. That is no surprise as the device runs at 3.3V. However, this may be at the core of my problem.
I'm getting garbage from the device over the serial port. In the first case I used a breadboard expansion to a serial-to-USB converter. I highly suspect the Omega could not drive the converter adequately as the breadboard signals are true device signals, and the converter was overdriving the Omega serial receiver. On the Omega I connected to both serial ports with the same effect, to no surprise.
In the second example, garbage abounds as well. However an expansion dock is in use and is powered up by 5V only being connected to Tx1 and Rx1. Bi-directional garbage. Is this interface also at 3.3V?
I'd appreciate a reply. FYI, here are my next steps. Somewhere, somewhere, somewhere in the docs find what these interfaces are spec'd at. Put a scope on the Tx1 port to check signal level and quality.
Here's another data point which points to a drive level issue. In one test config I have a sensor device driving the Omega Rx1 twice a second with perhaps 60 characters each message. Only a small percentage of the characters get through at random times, and are unrecognizable.