Typically what is most useful in a situation like this is actually to run gdbserver on the embedded board, and run GDB itself (either bare or with a GUI driver) on your development machine where it can get at your sources.
But if you're actually building on the board or just want to run GDB locally, then yes, you can do that too.
It's likely you are facing one or possibly the combination of two known issues.
One is that because an incompatible 32 megabyte SPI flash was used, accessing the whole of it requires putting it in a mode incompatible with boot, so unless something resets the flash chip when the CPU does, a warm boot will fail. Most other vendors avoided this by operating their 32-megabyte flash in 4-byte address mode all the time (but that would have required different strapping for the 16 meg and 32 meg versions).
Another is that if you have anything connected, say a debug serial port, the data lines itself will keep the MT7688 alive enough that it won't do a clean power on reset . Potentially in this case you have a similar leakage path where an I/O is keeping your flash chip alive enough during the power interruption that it isn't losing the boot-incompatible 4-byte address mode state. Or you could have residual charge on a capacitor.
If you want something more OS independent you might look at the reported memory, since there seem to be differences (64, 128, or 512) - see /proc/meminfo or similar
@Andrey-Mor said in Omega2 WIFI off issue:
@Chris-Stratton Is "logic level serial" means PC serial?
I don't know but for me hw reset doesn't work (hw reset pin connects to "minus" for about 10 secs)
For most people today "logic level serial" means a little bare-PCB USB adapter or cable ending in discrete wires, like might be used with a pi or Arduino.
What you cannot use is a traditional RS232 level adapter or port, typically terminating in a D-sub connector. If you have that, you'd need an inverting level translator.
The hardware reset will work if done right.
You could also connect a logic level serial to the module and get a root shell that way
Do you only care if you are connected to WiFi, or do you also care if your packets can go anywhere upstream?
ie, how do you want to handle the case of being connected to a router, when the cable modem upstream of it is down?
The underlying issue here has been covered many times before.
The Omega 2+ has an ill-chosen flash chip, which cannot expose its full capacity unless operated in a 4 byte mode which is incompatible with the configured expectation at boot.
There is no actual working poweroff command, and there never has been one. However, programs that reboot without putting the flash chip back in a boot compatible mode end up hanging in a tight loop at boot, giving the impression of being sort of "off".
Also note that unexpected reboots, such as triggered by a watchdog will also result in a hang, rather than a successful boot.
As the Omega 2 (non +) flash chip fits entirely in 3-byte addressing mode, it should not experience this problem.
Flash chip commands can be found in the relevant data sheets, as well as the U-Boot and Linux Kernel sources.
First step in debugging would probably be to explore what was ending up in the overlay.
One likely culprit is upgrading large amounts of system software (python, etc) or installing many new packages.
The other is having some ongoing task that creates log files or data objects
There are almost certainly ways to make this work, but they may take some non-trivial engineering.
Indeed, this is a bad idea.
A complex Linux system with many undocumented corners and unresolved bugs is the last thing you'd want for a flight computer. In the case of the Omega 2+ even simply compared to other boards with the MT7688 chip, there's also the issue that an error in the choice of the companion flash chip on the module means that if the MT7688 experiences an unprepared reboot (for example from a glitch, or a watchdog) without the flash chip power cycling, a disagreement of addressing mode means that it will hang and be unable to boot.
Actual flight controllers are quite simple computers. A few years ago they were typically 8-bit ATmegas or STM8's, though fortunately that era is now in the past. Today they are typically simple ARM Cortex M0, M1, or M3 parts, from the likes of STM, Gigadevices, Nuvoton, or Asia-only vendors relatively unknown in the west. These run with internal flash and ram and have the rich I/O that @ccs-hello mentioned. For these purposes they run simple main-loop style bare metal firmware, drastically simpler and more responsive than what you would get from a multithreaded architecture. If you're interested in experimenting with this the realm of tiny featherweight platforms, there are a number of published open source replacement firmwares for toys like the H8mini, CX10, etc - ironically, the smaller (and therefore twitchier) the aircraft, the faster the control system needs to be.
If you do choose to fly a system like the Omega 2+, it should be limited to optional features, for example, you might use it to log data that you'd like to have, but the loss of which would not cause the aircraft to crash.
A missing C file wouldn't typically be the result of a missing library. On a platform like this libraries (to link against) are .a files, and the error messages are from the link stage, not the compile stage.
Your error rather indicates that the build process (probably a Makefile) is pointing to a C source file called gpioRead.c that either didn't get copied to the build machine, or isn't where it is supposed to be. You should examine the Makefile, and also examine the source directory and figure out what the mismatch is.
Also note that if you move code around you can run into different platform specifics - Linux for example cares about capitalization. OSX in contrast preserves it but will match across differences (which can actually cause its own problems). And windows, well, nevermind.
The flash is not a BGA - you can clearly see all 8 contacts in the picture, and if you hold the MT7688 in reset it will stay out of the way of your programmer.
But you have to remove the shield.
Unfortunately, JTAG does not seem to be available without removing the shield either.
If you want to do low-level work you'd likely be better off with a Linkit Smart or an ACSIP module than an Omega2, in both cases where removing the shield is both less necessary, and substantially easier.
@cas said in LinkIt Smart 7688 fw on Omega2+ hw:
That's where the boot up sequence terminated. After a little while the O2+ LED turned off. I thought I'd bricked it.
You've perhaps run into the fact that the Linkit and Omega2 use different serial ports and baud rates for their consoles. Your boot log stopped right at the point where Linux switches from the inherited serial configuration to its own.
An odd thing about the Linkit kernel is that it decides which serial port to use based on which on-chip hardware it finds configured (and does this in a way that gets easily confused if you enabled more than one in uboot).
Best guess: it's still on the port you are connected to but now at 57600 baud.
The Omega2 uses an MT7688. The AR9331 was used in the now discontinued original Omega.
@William-Scott said in Programming Serial(UART) in C or C++:
@Arun-Kapur Suggest you take the advice of @Maximilian-Gerhardt and closely read the docs. Not explicitly stated is the UART is available as a character device in the file system. As such you can write to it and read from it in C(++) as with any other character device. IMHO, it's level of complexity, or lack thereof, does not warrant a separate library.
In actuality, correctly using the Omega's UART is a bit complex, requiring quite a bit of configuration, especially as the defaults are a bit unusually less appropriate than on many other systems.
A bad firmware will not prevent the MT7688 chip from producing serial output on initial boot. If you trigger a reset while connected, you should at least see something.
You may want to attempt a USB recovery in U-Boot.
@Kris-Kelvin said in Does the micro SD share interface with SPI GPIO?:
my attempt of connection to FW_RST was fall to the factory reset by some reason
What does that even mean?
Try saying it again, specifically and clearly - what exactly did you do, what were you expecting, and what exactly happened?
@Eleudson-Queiroz said in Onion-BLE integration:
@Fahad-Munawar-khan, I'm found this project https://docs.onion.io/omega2-project-book-vol1/bluetooth-audio-speaker.html
That is not about BLE but rather about the classic bluetooth audio scheme.
The author seems a bit confused, perhaps because the hardware may have dual purpose.
@Jakub-K False claims are false, regardless if there is no alternative.
The MAC is stored in an everyday, easily modified flash partition.
In contrast, true hardware unique ID's are not supposed to be alterable - but not all processors have them.
The initial question posting specifically requires something not alterable.
Changing the MAC address of the running adapter might be ephemeral, but an easily made change to the flash partition where the MAC address is stored is permanent.
So no, the MAC address is NOT an immutable unique ID!