Omega2+ unreachable when Wifi shut down

[dgluhak4]

@Luciano-S.
Thx for reminder there is SD card slot. Will investigate available options.

[WereCatf]

@dgluhak4 said in Omega2+ unreachable when Wifi shut down:

@WereCatf
This was my last resort after previous unsuccessful attempts. But I did not use 3.3v level serial port but serial port via USB adapter. Connecting was done by pairing my port RX with Omega2+ TX and vice versa.

USB-based serial-port is still a serial-port and it still has a voltage-level, so my point stands: what was the voltage-level? If it's a 5V-adapter, then you just fried your Omega's serial-port!

[MookieDog]

@WereCatf I am having the exact same problem with my Omega 2+: wifi is gone, taking all connectivity with it. I only have a power dock, so there is no ethernet available.

As per this thread, I tried connecting a USB serial port to the power dock's TX1 and RX1 pins. I get no response from the Omega2+. I know that my USB serial connection is wired for 3.3V, and I know that the serial converter board works.

I am pretty sure that the button on the power dock is not a reset button, but a button to manually tell the PMIC (power management IC) on the power expansion board to start working, as per the PMIC data sheet. That would explain why pushing it for 10 seconds didn't do anything resembling a reset operation.

I did make a bit of progress though. To get around the lack of a reset button, try the following:

1. remove the LiPo battery (if any was connected)
2. power down the Omega via power switch
3. insert a jumper wire between the RST and GND connections on the expansion board connector. This should act the same as pushing the reset button on expansion boards that actually have a reset button.
4. power on the Omega
5. wait about 10 seconds
6. remove the jumper wire, allowing the system to boot
7. wait for system to boot (flashing LED transitions to solid LED in my case)

At this point, I can now see the Omega2+ acting as a wireless access point again using its default SSID: Omega-XXXX.

Sadly, I cannot connect to the Omega via that access point. The authentication fails every time using the default password "12345678".

In addition, the serial port still doesn't work for me.

Am I missing something obvious here? It wouldn't be the first time...

[WereCatf]

@Robin-Hodgson The serial should work. Try swapping RX and TX around.

[MookieDog]

@WereCatf Tried that. Tried every baud rate between 9600 and 115200. Nothing. Should I be seeing boot messages spewing out of the serial port?

[WereCatf]

@Robin-Hodgson Yup, you should.

[MookieDog]

@WereCatf I am connecting to the Power Expansion board TX1 and RX1 connectors. My assumption is that these signals connect to the Omega2 TX1 and RX1 signals, but I can't find a schematic for the power expansion board.

I am using a generic CP2012 USB to serial board, where I know that its TXO means TX Output and RXI means RX Input, so I am connecting CP2102TXO to Omega RX1, and CP2201RXI to Omega TX1. But like I said, I swapped them and it didn't help.

I just broke out the big gun: during boot, the oscilloscope shows no serial activity on the expansion board TX1 (or RX1, for that matter). When I type in my own serial terminal, I can see myself sending chars that arrive on CP2102TX0.

[MookieDog]

@WereCatf I just ohmed the connection from the Omega RX/TX to the expansion board RX1/TX1. They are connected as one would expect.

My scope shows no serial activity during boot from the Omega.

[MookieDog]

@Robin-Hodgson OK, some more progress. After reading a bunch of docs, it turns out that there is a simple explanation, although not a simple fix.
The Power Expansion board breaks out TX1 and RX1. However, those are NOT associated with the UART device in the Omega 2+ that is used to access the console. The console port is located on RX0 and TX0. Sadly, those connections are not available on a Power Expansion board.

I hooked my scope to TX0 on the Omega, and do I see it chattering away during the boot process.

My takeaway is that the Power Expansion board is not the board you want to get started with. It has no reset button, and it provides no console serial access to the Omega. If you make a mistake that involves losing the WiFi connection, the Power Expansion board will not be your friend anymore

I will try to solder some wires to TX0 and RX0 because I'm still confused why a factory reset results in a system that puts out the default access point SSID again, but is not authenticating the default WiFi password.

[MookieDog]

@Robin-Hodgson Well, crap. I take it back: grounding the RST signal to the GND signal on the Power Dock expansion connector seemed to help, but it does NOT reset the Omega to factory defaults. I finally got a console serial connection to the power dock by soldering some wires to the header where the Omega2+ mounts. Poking around in the file system makes it very clear that the Omega is not back to what came from the factory. For example, the file /etc/config/wireless is not reverted back to the original version since it contains references to the router in my house. Or maybe I don't need factory defaults, I need a reflash of the entire factory firmware so I can start over. Is that possible?

[WereCatf]

@Robin-Hodgson You can flash firmware from a USB-drive and that will also wipe out any current settings, but you still need working serial to do that: http://community.onion.io/topic/1154/omega-2-usb-firmware-install-after-brick-resolved

[frederic raducki]

This post is deleted!

[MookieDog]

@dgluhak4 Success! After getting control of the console serial by adding the wires to the Power Dock, I found that typing "wifisetup" would allow me to re-enter the required data for the Omega2+ to re-establish the wireless connection to my router. My system is responding normally again, and I can finally get back to the Omega configuration page:

Here is how I added the wires:

[dgluhak4]

This post is deleted!

[dgluhak4]

@MookieDog
Finally!
I followed MookieDogs's instructions and was able to recover my Omega2+.
In short:

1. solder RX0 and TX0 on PowerDock to extend Omega2+ serial0 (console serial) RX and TX lines
2. cross connect RX0 and TX0 line with respective TX and RX on 3.3v level serial port. I used Raspberry PI serial and minicom.
3. on Raspberry PI (or another Omega) use serial port with "minicom -b 115200 -D /dev/ttyAMA0" command
4. now you are able to connect to Omega2+ console and configured it as you wish. I did manual factory reset using info on https://docs.onion.io/omega2-docs/factory-reset.html

All thanks go to MookieDog.

[György Farkas]

@dgluhak4 OFF
Excuse me if my post is entirely off-topic.

Omega2+ v0.1.9-b150 without Dock

Raspberry Pi 2 Model B V1.1
up-to-date Raspbian Jessie
minicom version 2.7 (compiled Jan 12 2014)

Formerly I also tried this 3.3V logic level 'Null Modem' connection between my O2+ and a RPi .
(Omega_RX0---RPi_TXD0, Omega_TX0---RPi_RXD0, GND---GND)

I always got garbaged characters up to the 'console [ttyS0] enabled' line(s):

   ____       _             ____
  / __ \___  (_)__  ___    / __ \__ _  ___ ___ ____ _
 / /_/ / _ \/ / _ \/ _ \  / /_/ /  ' \/ -_) _ `/ _ `/
 \____/_//_/_/\___/_//_/  \____/_/_/_/\__/\_, /\_,_/
 W H A T  W I L L  Y O U  I N V E N T ? /___/"

Board: Onion Omega2 APSoC DRAM:  128 MB
relocate_code Po)‹¥ÉY device id 2°LN¡È•¹‘Ìlash: MX2µÌ²µ¶³MQ¡ø*** Warning - âX-¤(ª(   QÍ¥¹Èefault env©¹Ë««åÑ)
o628_MP (Port5<->Îïî婅C(ªTOOÏÏÏÏϏêêêêêêêR5=¹¥½¹žmega2 UBoot ÖY®®ÖËK¢ršr‚ršR5µµ[------------------­KKKKKKKKKKKKKKKË©©©©©   ¤Ôš%
AUÌreq = 575 MHڅCQ.W«+E•‘Úemory size = L&RJ•Ñ•Í)Resetting MT7¶™œTRVI¨øInitializé·©Šu²ÂÂ:A%=æystem.C+5¡Æomponent: SPI Flá.–¨ˆѕéžct 18 2016  T5

…C%%%%%%%%¥IIIIIIIIIIIIIIIIIIII‰RRRRRRRR5©‘old Reset buttïî æﲐ[K•ßptions *
***ªªªªªª•••%%%%%%%%%%%%%%%%%%%%¥IIIII¨H¨H¨H¨Hõ½Ñ˜inux from Flash Î
                                                                    %UQ RESSED.
## Booté·)«+u•Ât bc050000 ...
                               R[XVÈ*Օé@  MIPS LED…¦Z«áµi.4.42                                                                                   K
   Uncompreó®–ëZ•É¹•±’mage ...…݁Çontrol                                          ©Šr’j     )   Load Address: 800°˜˜˜L*¹ÑÉ偠oint:  80°˜˜Ar¢r¢’B’2
[    0.00°˜˜˜W Të“Ñ…± MU set to 跐¬Ë‹É½±5[    0.000°°°Ý “k¢åÁ•é@MediaTek MT·œHW–KŠ*½éd5§tarting kernel ®®®ŠŠÃ[    0.000000] Linu¸»Y®®ÕË         Ë
[    0.0°˜˜˜LW$¬ë‹½¹Í½±•[early0] enabledp0000000) ———¡h4:¥Ù¥¹Øinux mems©½Y¤-
[  ˜KLL&&&RAUÁ@revision Z.')ʲªªBj%AMe4KEc)
[    0.00°˜˜˜W *
                5¥j…¡¥¹•
is Onion Omega2+
[    0.000000] Deteò[Z«Gáhysical RAM m‚‚BªÍ…‰±•¥
ېHL  ‚‚‚‚‚ê@memory: 08°˜˜˜LLH($&           [    ‚‚‚º2™™™™™u5[    0.000°˜˜W¤ê˅‰±•ôone start foòYX,’ë‹S5[    0.000000ݐQX.+Ûemory node rangr¹
ѱäegister=000´˜˜˜YC¡+elistsr‚‚‚‚‚‚ꁤeadback ErrCtl råVkѕÉõa004000fpagesº ³²µ±™C¡+r‚‚‚‚‚‚ꁗernel command ìZ«§½¹Í½±•õètyS0,115200 ¹ë‹™ÍÑåÁ•õæq+É
[    0.000000] Íåíïò¹L¦SS“iê)šŠ‚º’ZÂvailable (3012ː­–˫ŁÆode, 143K rwdata¬“‰Zåodata, 208K init, ±NÓ
                                                                                                          %Íͱ@5520K reserved, °)ÒV+Ւ•Í•Éٕ‘¥
                                                                                                                                              [    0®°°°
                                          D•Ù¥•Ñɕ•5[    0.00000°W¤(UjŠëk³éA580MHz                                                                   6
[    0.000°˜˜W¤,ëkµÍ½Õɍ•}Áɽ‰•é@no matching cloã­®«É•ÍÌound                                                                                          1
[    0.0746³NW¤ê«¹ÑµÆache hash tabìå Y‹É¥•Íé@1024 (orderº °¬ ´˜NJ+ѕͥ¬ [X¯•‘±•}¹Íé@6590553²¶´ î³C¡+r‚‚‚‚Š’êæched_clock: 32 âZ¯.RJʂj!é±@resolutioë
                                                                       [    0.0¸˜Nꁙountpoint-cache ha󴐺X,«*¹ÑÉ¥•Íé@1024 (oräY.'  E‚ʲåѕͥ     6
[    0.133428] mô““)úÁ¥½b0000600.gpio: òYVkѕɥ¹f2 gpios•Íé@0xffffffff, mἕ‘±•}¹Íé@19112604462750°˜˜[®Hø[    °®±°¦‚êáinctrl core: é·Z¯­,+K•‘àin‹
[    0.138966] mt762±uÁ¥½c0000600.gpio: regi³ºY®–ëš’:Á¥½Í5[    0®±´´´°˜W¤‹Ýi21_gpio 10000¶°°®ç°ZK’•¥Íѕɥ¹f2 gpios
[    0.150¹LMW¤-¦¬©‹Ýi21 10000900.i5±½­Í½Õɍ•MIPS re-start ·‹çupport                                                                                 )
[    0.189000] UÄР´X.WJ‹«*¹ÑÉ¥•ÍéA256 (order: 0¬ ´°¹¶±^®Ö+©Hh‚rŠÊ¢²‚šj©DP-Lite èX.WJ‹«*¹ÑÉ¥•Íé 256 (order: 0, 4096 ±^¯Ö+©Hø[    0.200945§Q+ë
                                                                                                                                                        0
[    0.2³·°²´®WWj¡™Íé@version 4®° ¨²°˜N       ŠzšŠJ‚¡¥±±¥Á˜ougher
[    0.2´™SR™™ÍÉt version 2.2 ¨§PŠ–BšU55Ie¥@(LZMA) (RÔRSQJ$¥¨êŠRõ%•{I%Qe¥@(c) 2001-2006 Re䐤X/        ”卹                5¡•‘‚‚‚ª‚‚‚r‚ݵéAError appk
[    0.2962´MW¤ª–++Ãé@8250/16550 driöY. E‚½ÉÑͱ@IRQ sharing äZ®–«E5[    0.3038±˜W¤¬Ëk½±•¶ttyS0] disablå²C¡+rš‚º’¢¢êc0000c00.uartlite: tô^*R¨ª*ê
[    r’ºÊª‚‚jät2880-piní].$®•kEɱé@could not reqõY.ìò¥¥¹b8 (io18) from grï].$®W”Ë닁Ålaim for 100°M&&&       ݵ5[    0®²·³´¸NW$.—   ‚j‚¥¹µÕááinctrd
[    0.316025] console [ttyS0] enabled
[    0.323020] bootconsole [early0] disabled
[    0.323020] bootconsole [early0] disabled
[    0.331702] 10000d00.uart1: ttyS1 at MMIO 0x10000d00 (irq = 29, base_baud = 2500000) is a 16550A
[    0.341199] 10000e00.uart2: ttyS2 at MMIO 0x10000e00 (irq = 30, base_baud = 2500000) is a 16550A
...

Was your serial communication fully perfect?

[Ken Conrad]

@György-Farkas Looks like a serial baud rate mismatch. The default setting for the Omega is 115,200. Check the Serial setting in Putty or your terminal program to be sure it is set to the same speed.

[Chris Stratton]

@Ken-Conrad said in Omega2+ unreachable when Wifi shut down:

@György-Farkas Looks like a serial baud rate mismatch. The default setting for the Omega is 115,200. Check the Serial setting in Putty or your terminal program to be sure it is set to the same speed.

Not really. The baud rate is correct in the sense of high level settings, or it wouldn't be "mostly" working. If it is a baud rate problem, it's a problem in the behind-the-scenes divider settings used to achieve the desired baud rate, or the clock source - of one device or the other. Devices with slightly wrong baud rates may work fine, until they encounter a device with a baud rate that is slightly wrong in the other direction. But if the baud rate were wrong enough to be a different user-level setting like 57600 or 115200, you wouldn't see any correct characters at all.

But it also could be electrical noise - I've seen this type of issue more often with long cables, including long power cables where some of the supply ground current may actually end up flowing in the serial cable's ground.

Or (less likely with the observed patterns, but still possible) it could be a buffer servicing problem - software on one end or the other not dealing with things in time.

[Ken Conrad]

@Chris-Stratton - Although it sounds like you disagreed, I think we agree that a mismatched baud rate setting in the communication program can cause this problem. Yes, it happens most often at lower speeds that are close but not the same. Yes, György Farkas's data does show that the hardware link is working, the UART is working, there is evidence of transmitting and receiving, etc, all true, but little comfort when he wants a readable command line. Checking Puttys' baud rate setting is easily done and in my experience, most often the cause of this garbage data.

Another possible cause for this problem is a miss setting in the Operating system for the serial port, which should be the same as the device's settings - Baud rate - 115,200, data bits- 8, parity - 8, stop bits - 1, and flow control - None.

I appreciate your explanation for other causes for the garbage data. Thankfully, in normal practice those are far less common.

[Chris Stratton]

No, again, user level baud rate and line settings cannot cause this problem.

What could would be having a serial device that when commanded to 115200 produced due to implementation issues perhaps 105000 instead; but that's only something that can be fixed in the hardware or driver software, not by changing a user setting (user baud rate setting are not actual numbers that can be fine tuned, they are enumerations from a limited set of defined choices)