I guess I have just found a bug on Omega2+ uboot
I am using serial ttyS0 as console. But at the boot time, i am seeing corrupted characters while uboot messages. After a while, it became correct..
here is the putty screenshot while uboot getting up;
then here is the putty screenshot where communication baud became correct;
I measured serial line communication timings and I saw 8.37usn bit time while data corruption, which means 119474 baud. normally bit timing should be around 8.68usn for 115200 baud. then it became correct.
If I enter putty 118200 as baud, everything is ok.
What do you think about this issue? Is this should be corrected?
@optech I have over 500 Omega2 devices deployed and I'm probably ranked >500+ customer of the devices so let's look at the potential causes of your issue. Here is my top 3 things to check:
Baud rate should be 115,200
Ensure your power supply is compliant to the required spec (Number 1 cause of irratic issues)
Please post your putty configuration settings
Use a decent USB cable.
optech last edited by optech
@crispyoz I have an opinion the cause of this issue.. i will tell you possible cause why i catch this issue after I answer your comments.
- Baud rate is set 115200 on Putty. But I am getting corrupted data while boot sequence when baud is set to 115200.
- Power supply output is measured as 3.27V on stable load. SMPS design is 8.25W. It works stable even in heavy load.
- My putty configuration is:
- I get same problem even I connect usb2serial converter directly to pc(zero cable). Here is the usb2serial converter pic that I use:
By the way, I am working on a custom hardware design.
The usb2serial converter, which i use, is CH340 based. so i think this chip has lower communication baud timing error tolerant. So I can catch this problem. I dont know if i get same problem with FTDI based usb2serial chips.
But issue is exactly related with uboot ttyS0 baud timing shift. it is set to 119400 baud(8.37usn bit time). I measured it with a logic analyser from Omega2S+ uart0 output(TX).. So nothing can change this timing problem except changing firmware uart baud setting.
What do you think so now?
By the way, you can see on my first post(on second pic), data became to flow correct after ttyS0 device is reinitialized by omega2p firmware (probably to correct baud as fine setting).
@crispyoz I have just clone git repo from omega2-bootloader project and change ttyS0 baud rate to 111147 baud. compile and load it, then it works well in putty at 115200 baud
I guess clock divider value set wrong in uboot.. It just a guess..
@optech that's interesting, I've never needed to make any modification to the boot loader in order to get reliable console access. My guess is you have a hardware issue.
optech last edited by optech
@crispyoz if you try this with a CH340 based usb2serial converter you will probably see same issue... if you use FDTI based chips maybe it is the cause of you dont have any problem.
But i can clearly say that, Omega2p main firmware and uboot firmware set ttyS0 baud slightly different. main firmware set for 115200 but uboot set 119470, meaning 8.7us and 8.37 us bit timing respectively. No hardware issue can cause this stable problem outside of omega2p hardware, it is always same even in micro second based timeline.
I have a robotdyn board that uses CH340G for USB.
It can print at 2,000,000 baud that agrees with the CH340 specs.
CH340G requires an external 12MHz xtal (11.98-12.02) while some other CH340s do not. Just pointing to a possible h/w or design flaw in the USB converter.
Please see the image that it writes 2M baud/1s interval. Even if the interval is changed to 5ms, I don't see any garbage.
I'm using MCP2200T with 12Mhz oscillator on my custom boards never had any issues.
Actually i dont mean that CH340 cannot communicate for 115200 baud or more. CH340 is a good chip. But just I wanna mean that uart communication is an asynchronous serial communication type and need to be interpreted by time samples. For example if one bit take 104.16us, then it means 9600 baud but IC designs uses some error tolerances for bit timing samples. For example, an IC can accept 105us as 9600 baud but another IC can interpret it different and can generate corrupted data to usb line.
The usb2serial converter which i use, probably have just a CH340 chip and crystal inside... So if CH340 have a problem inside the converter, this interpretation may be wrong also.
But it is so clear that uboot ttyS0 baud timing is slightly different from main firmware of omega2+. You can see yourself if you have a logic analyser easily.
I made same the bauds for uboot and main omega2+ firmware as changing uboot sources.. If you want I can send it to you also, to check... In my uboot binary, ttyS0 baud timing is about 8.7us for uboot as same as omega2+ firmware..
I purchased CH340G based 3v3 compatible adapter.
Sorry, it took so long to reach me due to lock-down, so the delay.
When I connect the adapter to Omega2, I get junk characters while it is still in uboot. Same observation as yours.
The Robotodyn board I mentioned in the earlier post has an 8-pin DIP switch that allows to configure to:
- connect CH340(onboard) to 328P or
- connect CH340 to 8266 or
- connect 328P to 8266 to communicate using Tx/Rx among those two or
- isolate all 3.
In the earlier post, I was using(1) above.
This time, selected (4) and connected the external CH340G adapter to the Tx/Rx of 328P. The external CH340 behaves identical to the built in CH340. No junk even at 2M baud.
I am happy somebody approved the problem which i see.
The main reason is Omega2S uboot has around %3.6 uart baud error and CH340 do not tolerate it.
Solution is "uboot uart baud seettings should be same as omega2s firmware uart baud settings."
luz last edited by
@optech Depending on the higspeed mode used, the MT7688's UART may not be very precise at high baud rates. If you have a look at the MT7688 datasheet on page 157ff, you see that for 115200 there's a divisor of 14 (down from 26Mhz) for the UART clock (which is divided by 16 to get to the baud rate) when highspeed_mode=0.
So the effective baud rate you'd get is 26E6/14/16 = 116071.
I don't know what mode is used in uboot (and linux tty driver, for that matter), but I would not be suprised if it was the simple non-high-speed mode.
Apparently, FTDI chips (I only use those, because of no driver hassles for those on macOS) are a bit more tolerant than others to inprecise baud rates. So I never experienced this in my daily work (I have >1000 Omega2 based products in the field). However, for a project I had to calculate the exact sending time for a byte stream @ 9600 baud - which turned out to need adjustments exactly due to not quite precise baud rate…