I recently had a need to use the UART interface on an MSO5074 and found this to be a challenging exercise.
There were two issues:-
1. The data out of the MSO5074 was corrupted from time to time.
2. There was no response to commands sent to the unit.
The corrupted data out of the MSO5074 was found to be caused by varying widths of the Low going data bits in the serial data stream.
At 115200 bits/sec, the nominal bit width is 8.68us. Some of the Low going bits from the UART interface were down to 3us width.
The over all packet timing was correct, just the width of the low going bits varied.
So depending on when the receiving equipment clocks the data in, it may see either a "0" or "1"
This was solved by feeding the data through an external Pulse stretching circuit to set the minimum bit width correctly.
The second issue of no response to commands was tracked down to an open circuit on the PCB trace from the UART interface connection point.
The Data IN to the MSO5074 goes via a series resistor. This resistor had been left off the circuit board.
Since the resistor is mounted on the back of the board, this meant completely dismantling the unit to bridge the gap on the trace.
After solving these issues, using the UART interface to talk to the MSO5074 was straight forward.
I found that "U Boot" can be easily interrupted by holding a keyboard key down from when the MSO5074 is powered ON.
** Edit. Added Pulse stretching Circuit. **
Accidentally now of course 
Lets hope this is not a new manufacturing technique; But I'll check if it is missing on mine as well. For the moment, I mostly care about getting data out of the scope. I'll do some measuring. I wonder though what the cause of this would be. The serial driver is from xilinx and is 'bog standard'. and should be fully functional. They may have hacked the serial ports however to work better with their HMI.
We also noticed that they changed something to make serial not work with more recent kernels, but I can't remember if this was already done with 1.2.3, or if that came after. I thought it was part of the Rigo201 change. I'm still on 'root'
@TopLoser, you are using serial extensively as is Dave; how come your scope is not suffering from this clock stretching need?
Right, so I did some more investigation herein, and I don't think it's a clock stretching thing. If it where, the results would be consistent. So I ran a few experiments; very simply after logging in with ssh to the scope; while true; do printf "\x<hex>" > /dev/ttyPS0; done
for <hex> i used a various number of characters.
So I can repeatedly print a whole bunch of characters, no problem at all. And some, are just offset/weird. Looking at the traces however, se even see the pattern actually change while looking at it.
I mean, the nice thing about sending repetitively the same character, is that you can see it really nicely 'standing still' on the scope. Not so much.
So looking at RigolDS6, we see two characters going over the line, Data:" and Data:G<S>; however I was sending " and #. Looking at my output from the USB-uart adapter, I do indeed see " followed by an unknown character. I had chosen this character range (\x21\x22) as I already noticed # was going wonky.
Looking at DS7, i was sending \x74, or the letter 't'. Perfectly fine, the serial console shows it as a repeating t. Everything is butts and butter. (I'll do some math and counting to see if those timings are actually right).
Now, when I changed to \x75, as can be seen in DS10, I actually get ] on the serial console. And only ]. _almost_ always perfectly repeating. Matter of fact, whenever I find a character that is wonky, it is constantly wonky. But not all characters are wonky. Make sense?
Looking at DS9 and DS8 though this is what the scope shows in combination with DS10. So a few ms it's u, a few ms it's } and a few ms it's _.
What's worse, which I couldn't capture on the scope (can't record gifs) is that the sent characters are actually heavily fluctuating. So if anything, it looks like dropped bits maybe?
Now looking at the characters that we see, 0x5f 0x75 and 0x7d.
So in binary that's:
0101 1111
0111 0101
0111 1101
So it's not an obvious shift happening, but we do see some bit flipping AND a shift happening?
like 0101 1111 shifted by a few would be 1111 0101 and flipping the sign bit, maybe forced somehow?) we see then what we would expect? It is really really far fetched though? A nibble shift + correction for the sign bit on a char?
But the last one shows even more signs of the shifting, as this is only shifted by 3 bits.
So this doesn't look very much like a pulse that's not wide enough, but bits being shuffled ....
Reading up a bit, it could be that somewhere some part gets confused about the start/stop of the signal, so that would explain the random shiftness. But it's quite 'reliably' reproducable. Power on, send \x75, perfect crap.
Measuring the signal, I geta bit time of 3.4 microseconds for 'a' bit, and 5 microseconds for the next bit. (DS11).
Fun fact, while poking, probing and proding, the ] switch to a ] on my console. Restarting the spam of \x75 makes it appear as a ] again though. So i'll go re-read post
https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2114902/#msg2114902 (#619)
So I have re-read the post, and he does indeed also claim 'varying bits' and bit times that are too small. I wonder what they messed with to cause this? I'll try installing an older version to see if this is a software 'fix' or not. Also I'm thinking it is related to the HMI. They had a problem with it likely, where not happy with signals and just hacked the serial driver to work with their HMI. That it broke serial input didn't matter too much to them, as all they care about is the HMI, UARt is not officially supported.
HOWEVER, if that would be true, why is it broken at the u-boot console, and why do some serial converters not care? And how is the hardware serial peripheral spitting out such junk?! I'll go read the manual to see what the hardware is even capable of doing and see if I can build one of this bit extenders ...
Home
Help
Search
Login
Register
