Working with this omega2S is very frustrating
-
Working with this omega2S soldered to my board is very frustrating, the smallest thing and it stops working. This is my 4th one bricked in 2 days, i dont even know why its bricked, I was just using it and then suddenly no more WiFi, so im now dead in the water with this thing.
There needs to be some kind of omega2s cable that can plug into a omega2S development board socket and then the other end plugs into your PCB so its easy to debug, if it gets bricked you can easily de-brick it using the development board end of the cable. Now its almost impossible to debrick, i dont even know why it was bricked in the first place and there is no way to debug it on my PCB. Im just at the mercy of this thing, the slightest breeze or if you look at it too hard then its bricked again WTF!! Then waiting days ordering parts and such to get it resolved, this way is just not acceptable.
Anybody has a good way to develop a product using this surface mount omega2s soldered to your own PCB? From what i been reading, If it gets bricked the only way out seems to be un-soldering all those pins and trying to debrick it using some other development board, and then soldering it back, its totally crazy.
Thanks
-
@nsmith I feel your pain, not becasue there is anything specific about the Omega that makes it problematic, but rather that most IoT devices are more fussy than your average PC due to their constrained resources. Imagine taking a 80286 and building a custom board. I'd bet you'd struggle to make it even boot.
That said, I approach any development board by building in some rescue functionality. Specially all my custom boards using the Omega2S, or any other SoC (inlcuding RP2040), I include headers for UART, ETH and reset button. While I don't document the pinouts of the headers, I can use them to rescue my devices. In production we drop these headers as we would not repair a production device, we'd either trash it or if the issue was really unusual we'd reflow the device in order to remove the Omega2S and fit it it to a dev board with the aforementioned headers.
-
We were able to use Omega2S on cutom PCB without any hardware problem.
The only issue was SPI driver issue (software issue).
However, we could still use the made custom boards for other purposes and ran well for a long time.Here's our hardware design repository.
https://github.com/dumtux/omega2-4g-gatewayAnd this is our PCBA supplier, where we made PCBs.
https://pcbcrew.com
-
When you say "bricking", you mean not destroying it due to some HW mishap, but a software issue that prevents it from booting?
I have a few 1000 Omega2S out in the field and so far only ever had to software-level unbrick one (I actually burnt a few more due to PSU issues in one production charge, and soldering parameter errors in another, but these are different stories).
From that one I learnt that all you need to unbrick from any level of software brick, including ruined u-boot (which IMHO can't be repaired in the devkit) is
- a way to apply power only to VDD_FLASH (A7) but not to the other VDD pins (C17, C18), to activate the SPI flash chip but not the MT7688 SoC (nor any other part of your circuitry)
- access to the SPI lines (A8..A12)
- a SPI flash programmer (anything from cheap $3 aliexpress up to Segger - in my case, a colleague had the latter and knew how to use it)
Only the first bullet point might be difficult (but usually manageable by cutting some tracks) if your PCB design does not provide for it. Accessing A8..A12 should always be possible; if you have to do it more than once, building an apdapter with 6 pogo-pins helps a lot.
With such a setup, you can write every single byte of the SPI flash chip inside the Omega2S, and with that, reflash any part of it that might be bricked.
That way, you don't need to unsolder the Omega2S completely to unbrick it
PS: if you can pull up GPIO38, have Ethernet and the serial console, and not bricked u-boot, but only openwrt, then unbricking is even simpler via the built-in recovery http server, see docs.
