You can directly connect VDD_FLASH to +3.3V. I have >1000 24/7 working devices in the field that are wired like this, so I'm quite confident
The reason for having that pin separate is that if you find yourself in a situation where you need to directly re-flash the SPI flash chip (e.g. after a failed attempt to update uboot), you can apply power via VDD_FLASH to the SPI flash chip without powering the SoC (MT7688).
This allows to re-program the flash using an in-circuit SPI flash programmer. The diode allows this without changing anything on the board (no jumpers required). I guess the 50Ω resistor is there for noise reduction.
If you wire VDD_FLASH to 3.3V directly, there's no way (except cutting traces on the PCB or unsoldering) to get a ruined uboot re-flashed. For my devices, I decided I will never touch uboot once they are produced…
The HW reset thing is another story - this extra circuit is needed to make the SPI flash reset (by interrupting its power supply during HW_RST) to ensure the address mode is right for the MT7688's startup.
If I recall the details correctly, address mode needs to be 3-byte during boot, but the firmware might later switch it to 4-byte. If then a reset occurs, the SPI chip is in 4-byte mode and the MT7688 tries to boot with 3-byte, which fails and leaves the device inoperable until power-cycled.
I imagine any hardware that is running an OS is going to take more time to power up that you need.
If the Omega had a sleep mode that'd be the way to do it but as yet, that's not an option.
What is the reason you need such quick power up? Is there some other way to tackle the requirement?
@Mark-Fisher the example code might be for the C version of LVGL?
As far as I recall, they had pretty sparse documentation for the micropython port. But that might have changed, I haven't looked into it in quite some time.
I agree with @crispyoz, your best bet is to go straight to the source and try posting on the lvgl forum. Let us know how it goes!
Hello @crispyoz thank you for answer. thats solve my problem but temporary.
But ı found solution permanent. If bme280 connect correct in omega device and if you install packages i2c packages.
in the node-red flow just click your bme280 and change bus 1 to 0. That will change to i2c-0 permanent.
how to know bme280 connect correct in omega device ?
in terminal write i2cdetect -y 0 if you see 76/77 that's means you connect correct.
@eblasband Yor device is full and therefore the file system has been flagged read only in order to prevent corruption of the file system.
Do a factory reset then start afresh.
Familiarise yourself with the df command so you can understand your available resources. IoT SOCs have limited resources, you need to manage them diligently. Consider using an SD Card so you can place your files on this file system.
@Nagarjuna-Reddy See the product pages for more info
North America Model: https://onion.io/store/omega2-lte-na/
Global Model: https://onion.io/store/omega2-lte-g/
And there's volume discounts, get the latest pricing here: https://onion.io/quote/
@Nagarjuna-Reddy It is very difficult to help you if you do not provide technical information about your circuit.
Are you using a USB to TTL converter? What happened to ttyUSB0 and ttyUSB1?
Have you looked at the system log to see if something is wrong?
@Nagarjuna-Reddy I see that you published in another post, and I think you were able to make your custom board start correctly, you should post the solution here, so that other people can get feedback from the experience.
@Nagarjuna-Reddy So it seems the underlying issue is that your DHCP server is either not accessible or is not providing dhcp service correctly. Using static IP is a fix but your IP, routing and DNS should be provided by your DHCP server on your network.
mt76 has taken huge steps in reliability and stability since the early Omega2 days. I‘d say for at least 2 years now it is as good as any of the proprietary drivers and it fully supports the official Linux wifi architecture (mac80211/cfg80211)
So, by 2018 and onwards, „unstable mt76“ is an outdated story.
@dbell The message suggests there is an issue with your wifi connection, try changing to a different channel.
In /etc/config/wireless you will have a section like this:
config wifi-device 'radio0'
option type 'ralink'
option variant 'mt7628'
option country 'US'
option hwmode '11g'
option htmode 'HT40'
option channel 'auto' <---------------------------
option disabled '0'
option device_mode 'apsta'
option op_mode 'preference'
Try changing to a static channel, channels 1, 6 and 11 are 3 common choices as they have no overlap.
You can use these commands:
uci set wireless.radio0.channel=11
uci commit wireless
service restart network
@CAP-33 Omega2+ is not that hot to burn your fingers. Your top output looks like a standard firmware, but it is possible that loadable modules can impact upon the load. Are you running Onion's latest firmware with no customisation? if not then this would be my first step, then see if this fixes the issue.
How are you powering the dock?
The best way to troubleshoot this is to bring everything back to standard. Standard firmware, powered from USB port of your computer.
If after this it is still very hot, I think it may be a faulty device.
Looks like your connection to Community was lost, please wait while we try to reconnect.