1. factory reset - 10s holding RST button on PowerDock = nothing happens
2. having no expansion modules I connected Ethernet cable with its RX's and TX's directly to expansion header corresponding pins on PowerDock = no ethernet connectivity
3. tried the same with serial pins connecting it serial port = no serial connectivity

I believe that Omega2+ is OK, but I'm not so sure that is the case with PowerDock (unsuccessful factory reset was the first alarm). How can I find out which one is broken or to recover an Omega2+?

One option is to buy another dock and Ethernet expansion and try to connect to Omega2+? The second option is to acquire 3.3v power source and connect Omega2+ to it and try to factory reset the Omega2+? Or to connect Ethernet signals via Ethernet cable to a switch?
Are there any options that enables me to test device without acquiring more new devices?

Any help is appreciated.
Regards,
Denis

You could complete your profile ... maybe there are ppl in your region with a better omega infrastructure and could help you out?!

1. tried the same with serial pins connecting it serial port = no serial connectivity

As long as the Omega2+ isn't dead, serial-pins should work. You did use a 3.3V-level serial-port? And connected RX to TX and TX to RX?

1. having no expansion modules I connected Ethernet cable with its RX's and TX's directly to expansion header corresponding pins on PowerDock = no ethernet connectivity

Not a good thing to do...
https://community.onion.io/topic/1184/ethernet-expension

@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!

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...

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.

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

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.

Here is how I added the wires:

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.

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?

@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.

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.

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)