I guess I have just found a bug on Omega2+ uboot

optech

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).

optech

@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..

crispyoz

@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

@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.

tjoseph1

Hi,

I have a robotdyn board that uses CH340G for USB.
https://robotdyn.com/uno-wifi-r3-atmega328p-esp8266-32mb-flash-usb-ttl-ch340g-micro-usb.html

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.

CH340G@2000000Baud.png

Thanks

crispyoz

I'm using MCP2200T with 12Mhz oscillator on my custom boards never had any issues.

optech

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..

tjoseph1

@optech
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.

Thanks.

optech

@tjoseph1
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

@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…