Author Topic: Hacking the Rigol MSO5000 series oscilloscopes  (Read 321138 times)

0 Members and 6 Guests are viewing this topic.

Offline mabl

  • Regular Contributor
  • *
  • Posts: 113
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #975 on: March 13, 2019, 05:56:32 pm »
That is how the backup script should look like. Did your patch succeed now? You can run it from the command line too, but it will not give as much output.
 

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 1533
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #976 on: March 13, 2019, 05:59:53 pm »
Hi,

Current best practice:

  • Patch the scope to have all licenses. For that download the patch from here. Again rename and copy to usb drive. This time the upgrade might take a bit longer, it should ask you to reboot, if not something failed, but it is probably not fatal for your scope, no worries. Reboot.


I renamed it to DSO5000Update.GEL put it to the stick, do local upgrade....Message "No package found" appears.

For windows it´s still a txt format while the "original" GEL file will be displayed as a GEL.file .
Maybe that´s the reason it doesn´t work on the scope too ?


Offline mabl

  • Regular Contributor
  • *
  • Posts: 113
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #977 on: March 13, 2019, 06:02:42 pm »
I renamed it to DSO5000Update.GEL put it to the stick, do local upgrade....Message "No package found" appears.

For windows it´s still a txt format while the "original" GEL file will be displayed as a GEL.file .
Maybe that´s the reason it doesn´t work on the scope too ?

Ah the poor souls using Windows. Sure it should have the .GEL extension. Under windows folder options you can prevent it from hiding file extensions somehow.
 
The following users thanked this post: Martin72

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 1533
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #978 on: March 13, 2019, 06:20:39 pm »
Thanks !
Now I got a GEL. file…... 8)

Offline NED88

  • Contributor
  • Posts: 9
  • Country: gb
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #979 on: March 13, 2019, 08:50:36 pm »
That is how the backup script should look like. Did your patch succeed now? You can run it from the command line too, but it will not give as much output.

Yes, it did :-)

I've attached another screenshot of the terminal output but for DS5000Update_patch_01_01_04_04_usb.GEL (renamed of course).

 

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #980 on: March 13, 2019, 09:59:03 pm »
I just realized, you may also want to start udhcpc -i eth0 & somewhere :) probably before your ssh line. If your appEntry fails to start or crashes or whatever, the devices will be without an IP, so ssh will be up and running, but you won't be able to access it.

appEntry does its own network management (wtf much?) but that doesn't conflict.

Hi oliv3r.

Thanks for the suggestion above - I'll try it out and see if it works... :)  Would I expect udhcpc in the list of processes by running ps -al  in the terminal?


I have a few additional questions for this thread/forum  ;)

1) Regarding the ssh command (I'm using Terminal on the Mac), it keeps saying "Warning: Permanently added '<IP address>' (ECDSA) to the list of known hosts." - is this anything to worry about?

2) Does anyone know if there a terminal command (on the scope) that can check the FAT-formatted partition on a USB memory stick (I usually use fsck but can't see the msdos version)?

3) I'm not sure if this is the correct Rigol MSO5000-related thread to post this question...  So, I decided to use the Measure menu to add Frequency, Period, Undershoot and Overshoot measurements in order to calibrate the four passive probes supplied with my MSO5104.  I managed to get both the Under/Overshoot down to ~0.6060% for channels 1, 2 and 4 using the 1KHz square wave (from the probe compensation terminal) and those three channels now show a good flat square wave.  However, channel 3 is showing a bit of overshoot (0.6711%) that I can't get rid of - is this normal and/or is it possible to rectify it??  Not sure if it's a software or hardware problem either.  I have attached, below, a screenshot of the measurements and I did run the SelfCal function beforehand.

0) Rigol do not use udhcpc, but it is part of busybox, so you can use it if you want. appEntry does its own network thing (maybe using qt, but not they may have rewritten it (reused from DS1074z) codebase
1) I think your system is not saving the signature locally, so everything you connect, it's asking you to do this. Also, the signature matches an IP, so everytime the IP changes, you will be asked (until you've used all available IPs :D
2) umount /dev/sda1 && fsck -a -f /dev/sda1 you mean?
 

Offline NED88

  • Contributor
  • Posts: 9
  • Country: gb
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #981 on: March 14, 2019, 01:21:11 am »

2) umount /dev/sda1 && fsck -a -f /dev/sda1 you mean?

Yes exactly that - but I get the error message as shown at the bottom of the attached image.  |O
« Last Edit: March 14, 2019, 02:51:21 am by NED88 »
 

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 1533
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #982 on: March 14, 2019, 06:23:43 pm »
Thanks !
Now I got a GEL. file…... 8)

And now I got all options.... :D
Everything works fine, still no overshoot issues, good.
Before, the 40ps risetime pulsegenerator on 70Mhz BW:



After, with 350Mhz BW:



(tomorrow a shot with the same voltage resolution (forgot it) )

Big thanks for such an easy thing to do.

 
The following users thanked this post: luma

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 1533
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #983 on: March 15, 2019, 05:12:27 pm »
Quote
(tomorrow a shot with the same voltage resolution (forgot it) )

Done, posted there to keep this thread clean:

https://www.eevblog.com/forum/blog/new-rigol-scope/msg2270838/#msg2270838

Offline tv84

  • Super Contributor
  • ***
  • Posts: 1839
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #984 on: March 15, 2019, 06:03:22 pm »
Quote
(tomorrow a shot with the same voltage resolution (forgot it) )

Done, posted there to keep this thread clean:

https://www.eevblog.com/forum/blog/new-rigol-scope/msg2270838/#msg2270838

Cleaning is deleting!
 

Offline BitBug

  • Newbie
  • Posts: 4
  • Country: ca
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #985 on: March 15, 2019, 07:16:48 pm »
It amazes me how these companies will rush a basically good piece of hardware to market with this many firmware bugs... and with only half-assed beta testing (if any)... This is generally where the community decides to take matters into their own hands, and makes it a fully open-source project. Can anyone say, "OpenWRT"?

You've dumped all the firmware... Clearly, some people are using IDA Pro to reverse engineer some of that code. You could amp-this-up by using FLIRT signatures in IDA for code pattern recognition of known libraries (I did this for an STM-based Set-Top-Box using all their code libraries). Once all the "canned" code is identified, what's left is custom-written code/drivers - and you can figure-out what they're doing with some work... I'm sure this was the same basic process that resulted in the OpenWrt Project (maybe we should call it the "OpenScope Project"?)

It's only a matter of time before we, as a community, pick a relatively inexpensive "base" piece of DSO hardware and make it our own (as in, we maintain the firmware/software - they just compete on the best hardware). What DSO engineering company wouldn't want to be "chosen" by our community as the first hardware "base"? ...Certainly not Rigol - they just want to sell their hardware... and I'm half thinking (at least, in part) this is Rigol's modus operandi when it comes to the ease of hacking their scopes. I'm actually really surprised that a entire source code tree hasn't mysteriously "appeared" on the web to force some companies' sales into the stratosphere... and it would!

Once you force the issue, these DSO engineering companies will work/compete on making a better hardware platforms for our "OpenScope" software...

It's only a matter of time... and the first DSO engineering company that adopts this marketing strategy, will win all the marbles... and it will be a paradigm shift for the entire O-scope industry. Sure, they'll all still continue making expensive +500MHz scopes (IBM still makes mainframes) for universities and fortune 500 companies, but they'll relinquish the entire sub-500MHz market to Open Source software... kind of like your generic PC hardware is now.

...All it will take is for it to happen just once on a "chosen" platform... kinda like this one...  ;)

BB
 

Offline Martin72

  • Super Contributor
  • ***
  • Posts: 1533
  • Country: de
  • Testfield Technician
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #986 on: March 15, 2019, 09:38:27 pm »
Quote
Cleaning is deleting!

Therefore you post my post again.

Quote
Big thanks for such an easy thing to do.

When the next firmware update will be released, the hack will be gone - then we could patch it again with the same file….perhaps.
When this can be done, it´s an evidence that rigol doesn´t want to stop hacking seriously.

 
The following users thanked this post: luma

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 11388
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #987 on: March 15, 2019, 10:26:03 pm »
When the next firmware update will be released, the hack will be gone - then we could patch it again with the same file….perhaps.
When this can be done, it´s an evidence that rigol doesn´t want to stop hacking seriously.

The firmware release notes states that it 'Boots in less than a minute'" so obviously some boss gave the order to "Make it boot in less than a minute!"

It used to boot in 1:15 and now it takes 0:59 so they shaved off just enough to comply with the order. As soon as it was less than 60s they stopped work.

Switching off SSL might have been one of the things they did to reach that goal, ie. it wasn't switched off for security reasons but purely for boot-timing reasons.  :popcorn:
« Last Edit: March 15, 2019, 10:30:24 pm by Fungus »
 

Offline quakeman

  • Contributor
  • Posts: 6
  • Country: de
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #988 on: March 16, 2019, 05:05:03 pm »
My MSO5074 was delivered yesterday with firmware 01.01.04.04.
I did a backup and after that applied the patch. It worked out of the box and now i have all options activated.
Thanks to all who made this possible. :)
 

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #989 on: March 20, 2019, 07:31:23 pm »

2) umount /dev/sda1 && fsck -a -f /dev/sda1 you mean?

Yes exactly that - but I get the error message as shown at the bottom of the attached image.  |O
fsck.minix is the only fsck version available :( so sad. So you'd have to do it locally on a desktop system
 
The following users thanked this post: NED88

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #990 on: March 20, 2019, 07:39:08 pm »
It amazes me how these companies will rush a basically good piece of hardware to market with this many firmware bugs... and with only half-assed beta testing (if any)... This is generally where the community decides to take matters into their own hands, and makes it a fully open-source project. Can anyone say, "OpenWRT"?
Absolutly, as long as you realize, it's a massive amount of work of course.

First, we need to fully _understand_ the scope. I'm slowly working on that via https://www.gitlab.com/riglol/rigolee but not (m)any contributions yet :)

You've dumped all the firmware... Clearly, some people are using IDA Pro to reverse engineer some of that code. You could amp-this-up by using FLIRT signatures in IDA for code pattern recognition of known libraries (I did this for an STM-based Set-Top-Box using all their code libraries). Once all the "canned" code is identified, what's left is custom-written code/drivers - and you can figure-out what they're doing with some work... I'm sure this was the same basic process that resulted in the OpenWrt Project (maybe we should call it the "OpenScope Project"?)
Cute :) but you understatimate the effort :)
In any case, what we know so far, is that the UI is built ontop of QT, but sadly, that's all they use, the rest is all custom code they've written internally. Copyright/IP fear from the chinese naturally. Write it yourself, however so badly, and atleast you can't get sued is the general thought. That said, they also modified the kernel and u-boot.

As for the openwrt port, remember that they only started after they have received the GPL-ed kernel code. They used the propriatery blobs for the wifi drivers, and that got them a linux system. It took them YEARS to get where they are now, and what we had with the initial openwrt port was just very basic (but super powerfull and 100x beter than what the vendor had). Mind you, i've been running openwrt since the first release on a WRT54G :) and only buy routers that support openwrt.

So if you want to help, an open task is to bugger Rigol about releasing their GPL-ed work. The bootloader and Kernel most importantly. The application, well, we don't care too much about that yet :)

It's only a matter of time before we, as a community, pick a relatively inexpensive "base" piece of DSO hardware and make it our own (as in, we maintain the firmware/software - they just compete on the best hardware). What DSO engineering company wouldn't want to be "chosen" by our community as the first hardware "base"? ...Certainly not Rigol - they just want to sell their hardware... and I'm half thinking (at least, in part) this is Rigol's modus operandi when it comes to the ease of hacking their scopes. I'm actually really surprised that a entire source code tree hasn't mysteriously "appeared" on the web to force some companies' sales into the stratosphere... and it would!
I love your enthousiasm, but so far, mostly hardware guys in this thread (which we also badly need). Step one, with any project, is understanding the hardware. We have some good resources though, but at least I haven't documented all my findings yet :) In time, in time. The wiki also has some knowledge of the chips used for example. We ain't sleepin' ya know.

Once you force the issue, these DSO engineering companies will work/compete on making a better hardware platforms for our "OpenScope" software...

It's only a matter of time... and the first DSO engineering company that adopts this marketing strategy, will win all the marbles... and it will be a paradigm shift for the entire O-scope industry. Sure, they'll all still continue making expensive +500MHz scopes (IBM still makes mainframes) for universities and fortune 500 companies, but they'll relinquish the entire sub-500MHz market to Open Source software... kind of like your generic PC hardware is now.

...All it will take is for it to happen just once on a "chosen" platform... kinda like this one...  ;)

BB
I welcome you to help! Please :)
 

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #991 on: March 20, 2019, 07:41:01 pm »
When the next firmware update will be released, the hack will be gone - then we could patch it again with the same file….perhaps.
When this can be done, it´s an evidence that rigol doesn´t want to stop hacking seriously.

The firmware release notes states that it 'Boots in less than a minute'" so obviously some boss gave the order to "Make it boot in less than a minute!"

It used to boot in 1:15 and now it takes 0:59 so they shaved off just enough to comply with the order. As soon as it was less than 60s they stopped work.

Switching off SSL might have been one of the things they did to reach that goal, ie. it wasn't switched off for security reasons but purely for boot-timing reasons.  :popcorn:
Well I know that after the double beep you hear during boot, 'appEntry' starts (their main application). That's where the scope spends most its time. Even the 8 seconds it takes to load the FPGA (which is needed anyway) is insignificant compared to the bloated QT app to load. So they must have reduces some sleeps/waits in some loops during startup to shave those 16 seconds off, and pray that everything still works :)
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 11388
  • Country: 00
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #992 on: March 20, 2019, 07:49:27 pm »
.... the bloated QT app to load.

QT? Say it ain't so.  :palm:

 

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Serial console help
« Reply #993 on: March 20, 2019, 08:13:05 pm »
So first some background; I have been using serial consoles at home and professionally for years, so I would have thought I knew what I was doing :)

but I'm quite baffled, as to why I can't get decent text out of my console on the scope. Lets start with a screenshot :) (see attachment)

The serial port is connected as 115200 8n1 as expected and I tried 4 different USB uart adapters. But they all produce similar garbage.

Now, it's important to know, that I have not soldered on the connector. I took a jumper wire, and thickened it with solder and thickened the pin until it took some effort to squeeze it in (3x). So granted, the connection could be poor. But would that result in this kind of poor reception?

I do see quite a few of you manage to talk to the scope over serial; but I'm a little hestitant to solder a connector on (for now, warranty claims and all that).

But other then an unreliable connection, I'm puzzled as to why I cannot talk to the scope ... any tips/pointers? I am about to order some of these http://microcontrollershop.com/advanced_search_result.php?keywords=press-fit&x=0&y=0 but they'll take a while to arrive here ...

Edit: So having the scope probe itself I got this screenshot. Here the scope is doing an "echo "Hello World" > /dev/ttyPS0" (with the serial debugger connected).
Edit2: The third image is what the scope 'see's' comming from the serial converter, but nothing actually is arriving on the serial port (I think firmware 1.1.2.3 started do disable the RX part of the serial port.
« Last Edit: March 20, 2019, 08:30:28 pm by oliv3r »
 

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #994 on: March 20, 2019, 08:14:22 pm »
.... the bloated QT app to load.

QT? Say it ain't so.  :palm:
It aint so!
But of course, we know it is :( what do you think https://gitlab.com/riglol/rigolee/tree/MSO5000/firmware/rootfs/rigol/Qt5.5 is for :)
 

Offline egonotto

  • Frequent Contributor
  • **
  • Posts: 313
Re: Serial console help
« Reply #995 on: March 20, 2019, 08:40:07 pm »

but I'm quite baffled, as to why I can't get decent text out of my console on the scope. Lets start with a screenshot :) (see attachment)


Hello,

look at Reply #619 from seronday (page 25)

he has a solution to your problem.

Best regards
egonotto
 
The following users thanked this post: NED88

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #996 on: March 21, 2019, 05:36:52 pm »
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 ...
« Last Edit: March 21, 2019, 06:54:46 pm by oliv3r »
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 1839
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #997 on: March 21, 2019, 06:55:59 pm »
So this doesn't look very much like a pulse that's not wide enough, but bits being shuffled ....

So, is it serial port obfuscation (by port driver modding)?

If so, a custom terminal is needed.
 

Offline oliv3r

  • Regular Contributor
  • *
  • Posts: 121
  • Country: nl
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #998 on: March 22, 2019, 09:42:53 am »
So this doesn't look very much like a pulse that's not wide enough, but bits being shuffled ....

So, is it serial port obfuscation (by port driver modding)?

If so, a custom terminal is needed.

I'm not really sure whats going on, and more strangely, what they changed. Even if they hacked the smithereens out of the serial driver, it doesn't matter, u-boot is 'broken' ... they could of course added the same modifications to u-boot, but that's super unlikely. What could be the case though, is that they are initializing the port wrong. They are using the xilinx serial peripherial, so it's all in all, a hardware based serial port. I'll go read the manual and start reading the registers to see wtf they are doing there.

Meanwhile, I can read 'just about enough' to debug stuff. I do have to take appart the scope to see if I'm missing the 0? oHm resistor.
 

Offline tv84

  • Super Contributor
  • ***
  • Posts: 1839
  • Country: pt
Re: Hacking the Rigol MSO5000 series oscilloscopes
« Reply #999 on: March 22, 2019, 10:59:25 am »
Meanwhile, I can read 'just about enough' to debug stuff. I do have to take appart the scope to see if I'm missing the 0? oHm resistor.

Or, as I've hinted in the past, maybe the serial passes through the FPGA and something went bad in the latest programming.

If it was unintented, a bad recovery serial port is not something very pleasant to have...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf