Original poster is right. looks like a bug in the boot ROM. It wants 120,000 baud rate, not 115200.
Context: Omega2+ in mini-dock, Win10 64 bit, trashed file system, want to go back to factory firmware. Wifi connectivity also trashed.
Holding the reset button down for 10 seconds does not work, still trying to boot from the micro SD card
So I wanted to update the firmware from a USB stick, following the procedure in the documentation.
I inserted the USB stick.
Holding down the reset button while turning power on, the serial port disconnects soon after power-up. Only way to recover is disconnect and reconnect USB, but this forces a power cycle. No good in the mini-dock.
Tried the same process in a Linux system, silent failure this time but still no luck.
Move to a Power Dock 2, soldered on a SparkFun Serial Basic card (CH340). Made sure it was jumpered for 3.3V! Pins 1 gnd 5 Tx 6 Rx (seen from serial card end) .
Note - you can't do this with a mini-dock etc. because your external serial card will be fighting with the internal serial converter chip.
Now it comes on with reset button held, but screen full of trash for 40 seconds then a normal boot.
Then I came across this comment, inspiring me to try 120000 baud rate instead of 115,200. Works!
Procedure - set PuTTY for 120,000, power on holding reset button until fast blink, zip over to the keyboard and hit 2 quick as a bunny, system loads from USB stick and then does normal boot. Switch PuTTY back to 115200, hit enter and the prompt shows up.
Don't know why it skips the log-in or why it needs a carriage return. But that has been my experience with this system using the hardware serial port.
There seems to be no other way to unbrick a non-WiFi capable Omega2, except maybe if you have an Ethernet dock. Probably same problem trying to use a micro-SD card.
I'm not sure when stty started accepting high values, but maybe I was working with an older version at the time. I just tried stty with high values, and it accepts them (I did firmware upgrade recently).
I think I can explain what is going on (even without reading the source code). The driver (or stty) is accepting the high values, but the high baud values (low divisor values) are inaccurate at these values as they do not appear to be using the high speed feature (I read the high speed register after setting uart to high value using stty- still set to 0 which uses x16).
If you calculate what the divisor latch should be for 921600, it is 2.7 I think, round up to integer of 3 and you get 833333 baud, which is close to what you are seeing. The opposite effect of what I was going through- you have an accurate micro, and the omega is the one which has a problem.
The solution is to set the high speed mode to 3 which uses the sample_count and sample_point registers. The x16 is then eliminated and you are dealing with divisor values with more precision.
In my case, 1000000 baud is the max I can do from my micro (the next value up for my micro is 1200000, which does not work). I don't know why it doesn't work faster, but my micro is running on internal osc w/usb corrections which should make it good, but still not crystal good. I don't know how accurate the omega clock is, but that is another error source. At these higher rates, the sample_count starts getting lower (0x28 for 1000000) and you start losing accuracy there, too.
I think my uart.sh script is mostly readable, so you can see what I'm doing to get 1000000 baud. If you cannot understand it, I can explain it a little better if needed.
I am guessing you are programming in python with pyserial installed. It seems that the readline() would return a empty line, and therefore its printing nulls. This is because of the timeout being passed with 1. The print statement adds a newline at the end, so it will keep printing newlines. This is why you would see your text momentarily.
You may want to use print(data, end="") if you don't want to add newlines at every print statement.
You may want to check if there is data on the returned readline() before passing to print(data), as it would keep printing empty strings.
@Arun-Kapur I don't see any problem with the C code I have pointed you to.
I have personally tested the C code to work as expected on my Omega2+ for UART1 on 115200 Baud (8N1 standard config, non-blocking).The receiving side is a USB-Serial converter on my Windows 10 system. Connections are already listed in the documentation (GND, RX1, TX1).
It does not say that your file does not exist - this message says that ash cannot find any executable in bin named foghorn1.wav, which should be run. The same way when you write eg. ls - ash then looks for a proper executable in bin and if no results are yielded, returns an error message.
If you want to run a file from current directory, you'd need to write ./my-file, but it only works for executables, which - clearly - a music file is not.
I dont see what the converter has to do with not finding and playing a file
I bought SDS021 and would like to extend it's life. As per product sheet this sensor can be putted into sleep mode. Sleep mode can extend life of this sensor. According to vendor information SDS021 laser will last up to 8000hrs (~1 year) of continious work.
Do you know how to put SDS021 into sleep mode via python and wake? I do not need to have air quality delivered every second. Would like to start script from cron hourly.
Looks like your connection to Community was lost, please wait while we try to reconnect.