Hacking the Rigol MSO5000 series oscilloscopes

[ebclr]

Do you need to apply all intermediary patch Or can I go from the 1st one directly to the Last one

[Fluffhamster]

Do you need to apply all intermediary patch Or can I go from the 1st one directly to the Last one

Go directly to last one.

Did anyone noticed change in UI responsiveness after patching new FW? I have much better experience.
p.s. Shout out to everyone here for your work @delfinom, @mabl, @tv84 and so many others - long time observer here 

[tv84]

Did we already extract the u-boot image and environment? If so, is there an easy way to do this? Hints are very welcome.

AFAIK you need to read the SPI mem externally.

These are the u-boot commands available:

Code: [Select]

aesTest - aes test
base    - print or set address offset
bdinfo  - print Board Info structure
beeper  - Beeper
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
bootz   - boot Linux zImage image from memory
checkGTP- Config the clock 125MHz
checkVer- check version
clk     - CLK sub-system
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
cpldver - Get cpld version
crc32   - checksum calculation
dcache  - enable or disable data cache
dhcp    - boot image via network using DHCP/TFTP protocol
dpu     - Init DPU
dver    - DPU version
echo    - echo args to console
editenv - edit environment variable
env     - environment handling commands
exec    - exec memaddr ,return 0 on success, or != 0 on error by rigol
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
false   - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fatwrite- write file into a dos filesystem
fdt     - flattened device tree utility commands
fpga    - loadable FPGA image support
go      - start application at address 'addr'
goldFinger- Set boot from Gold finger
help    - print command description/usage
hwver   - Get hardware version
i2c     - I2C sub-system
icache  - enable or disable instruction cache
iminfo  - print header information for application image
itest   - return true/false on integer compare
ledoff  - turn led off
ledon   - turn led on
loadb   - load binary file over serial line (kermit mode)
loadlogo- load logo
loads   - load S-Record file over serial line
loadx   - load binary file over serial line (xmodem mode)
loady   - load binary file over serial line (ymodem mode)
loadzynq- load zynq bit
loop    - infinite loop on address range
md      - memory display
md5sum  - compute MD5 message digest
mdio    - MDIO utility commands
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mw      - memory write (fill)
nand    - NAND sub-system
nboot   - boot from NAND device
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
progGTP - Programing the clock of 125MHz
readfile- Read the package from USB DISK to memory
reset   - Perform RESET of the CPU
restart - Restart the power
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
showMessage- show message on the bottom of the LCD
showvar - print local hushshell variables
sleep   - delay execution for some time
source  - run script from memory
sspi    - SPI utility command
storage - Select Nand or QSPI as the current storage device
tar     - tar command by rigol
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
tftpput - TFTP put command, for uploading files to a server
true    - do nothing, successfully
unzip   - unzip a memory region
upgradeFromUSB- Upgrade firmware from USB Disk
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
zynqaes - Zynq AES decryption
zynqrsa - Zynq RSA verfication


[thinkfat]

Did we already extract the u-boot image and environment? If so, is there an easy way to do this? Hints are very welcome.

AFAIK you need to read the SPI mem externally.

These are the u-boot commands available:

Code: [Select]

fatwrite- write file into a dos filesystem
nand    - NAND sub-system
sspi    - SPI utility command
storage - Select Nand or QSPI as the current storage device
upgradeFromUSB- Upgrade firmware from USB Disk
usb     - USB sub-system
usbboot - boot from USB device


Might not be necessary. I see there's the "usb" command and the "fatwrite" command, it might be possible to read the boot memory into RAM and then write it out to a memory stick. The "upgradeFromUSB" and "usbboot" commands hint that it's feasible.

[tv84]

Might not be necessary. I see there's the "usb" command and the "fatwrite" command, it might be possible to read the boot memory into RAM and then write it out to a memory stick. The "upgradeFromUSB" and "usbboot" commands hint that it's feasible.

I think that's the problem: IIRC, you can't reach the bus to read to mem.

[thinkfat]

Might not be necessary. I see there's the "usb" command and the "fatwrite" command, it might be possible to read the boot memory into RAM and then write it out to a memory stick. The "upgradeFromUSB" and "usbboot" commands hint that it's feasible.

I think that's the problem: IIRC, you can't reach the bus to read to mem.

You mean, u-boot doesn't have a driver for the first-stage boot medium? And the "sspi" command group is not allowing access to it?

[tv84]

You mean, u-boot doesn't have a driver for the first-stage boot medium? And the "sspi" command group is not allowing access to it?

I'm unable to follow you at that level!  It seems that SPI bus is "private" and not accessible after boot. Or the FPGA (that seems to police access to devices) needs a special setting to allow the access... All tries were unsuccessful. Most probably we were missing your contribution when it was investigated!   

We became convinced that to flash the bootloader we need to connect the device to an external programmer. If it is like that is bad but it is also good as the probability of someone bricking it is much lower.

Do these responses help?

rigol-uboot>sspi
00FFFF

rigol-uboot>sspi blabla
00FFFF

[Gandalf_Sr]

I redid my Bode plot having realized that the Ch2 probe was switched to x10 but the input was set to x1; looks a bit more reasonable

[sjm]

Yeah... well I had an old Onkyo TX-NR509 AV amplifier that was kinda brain dead for last 5 years but the power amp part looked intact and should work. Finally had time to look at it.
After some merciless slaughtering and removal of something around 7 circuit boards and half a dozen relays -- no brains, no drive to the relays -- I managed to have a working 5 x 80W power amp!

Then with 100mV drive and 10 ohm power resistor as the load, I gave it a shot and measured the freq response. Nice flat curve from 20Hz to around 100kHz.

BR, -sjm

[Gandalf_Sr]

@sjm
Nice flat response

[cv_pacifier]

First let me say thanks to all of the hard working much more competent people that made unlocking the features of the mso5000 possible. just bought a mso5074 and followed your instructions with success. I also have a MSO2072A and a ds6000 test board. I have been trying to get the rs-232 function to work. I hook probes from both instruments into the demo board and though i can get the mso2072a to sync to the rs-232 signal, i cannot do the same for the mso5074 instrument. Just wonder if anyone has checked the decoding capabilities of the unlocked scope and have you had any trouble making this work. Thanks

[bmx]

i've used the decoders since day 1, and rs232 is working perfectly, except the UI is ugly as hell, and should be nicked Unusable Interface instead. The decoded buffer seems to be the display buffer, and zooming out changes everything in the decoding result.
So yeah, it decodes.

[Noy]

Does somebody know if the "jitter measurment" is working?
Does somebody know if the "eye measurment" is working? And how can i draw an eye?

MSO5000 not 7k/8k

[Sighound36]

Hello Noy


The 5000 is not supposed to have the jitter app, however Tv84's opening up of the scope allows you access. The eye app will not function on the 5000, we struggled to get it work on the 7000 currently only the 8000 has this option.

[Noy]

Hm thats sad.

TV said he was able to run homebrew software?

Maybe we are able to build an app by our own?

I'm thinking of using these pass/fail measure thing but putting an eye into it?

[Sighound36]

You might find its the hardware requirements that are the short fall for the eye app Noy

[eutectique]

i've used the decoders since day 1, and rs232 is working perfectly, except the UI is ugly as hell, and should be nicked Unusable Interface instead. The decoded buffer seems to be the display buffer, and zooming out changes everything in the decoding result.
So yeah, it decodes.

Can you trigger on rs232?

For example, on condition "bit pattern 1xx0x0xx on any of Tx or Rx lines"?

Can you set bit pattern 1xx0x0xx with SCPI command ":trig:rs232:data ..."?

Can you search for these trigger events (chapter 15 Search and Navigation Functions)?

[cv_pacifier]

re decoder: After I read that the instrument did decode, i played with mine  for several hours. My MSO2072 worked great and i thought i had correctly set all the characteristics on both machines. I was a bit confused by the copy trigger function to the decoder. I went over meticulously all the settings and finally got it working after i realized that it was decoding correctly the data it was receiving (RS-232) Changing the polarity on the trigger characteristic solved the problem. Not sure why reversing the logic was necessary since  i thought the default position was appropriate. Anyway it is working now. Thank you for your comments. Its really a hell of a machine feature-wise.

[Gandalf_Sr]

Its really a hell of a machine feature-wise.

That statement sums up my thoughts on the MSO5074.

I'm glad to hear that you got the decode working. RS232 normally idles high so that ought to be the default setting, does your RS232 idle high or low?

[Sighound36]

Its really a hell of a machine feature-wise.

That statement sums up my thoughts on the MSO5074.

Completely agree you do obtain a great deal of useful features with the Rigol 5/7/8000 series machines, Martin 72 made a fair point about them being a little rough around the edges and note quite finished, I would agree to point. But what you have is the raw horsepower and decent deep memory to really delve into debug issues.

For example to obtain 500Mpts from the Lecroy wavepro254 costs a lot more than a fully optioned up and probed MSO 8000 at price points. Or Tek's BW upgrade on the new 4 series is £15K+ LOL  Concerning hobbyists and small start up's the Rigol's offer very good options for the cost, plus the clever folk on here can produce their scripts to enhance their features.

I still use the 8000 daily and its a very good scope, its more polished than the 5000 but the 5000 is still something for the cost, think back 5 years to what even a similar scope WITH all the features would cost then?

Again excellent work from all of those contributors on this thread top stuff chaps

[cv_pacifier]

Hi there. appreciate the commentary on my rs232 difficulties. By idling high are u referring to the polarity or maybe the trigger level. I am really rusty at this and am not sure re your question. I just got the sigma installed and though i'm sure the USB connection is working , I am not familiar with entering commands to the mso5074. As far as the polarity the default polarity on the hieroglyphic for the polarity which i assume is negative shows the first transition from high to low. If I dont change it to low to high  then it misinterprets the data.  Have to make both logic symbols on the trigger and on the decoder i believe positive logic ( with the ist transition low to high) for it to work correctly.

[Gandalf_Sr]

Hi there. appreciate the commentary on my rs232 difficulties. By idling high are u referring to the polarity or maybe the trigger level. I am really rusty at this and am not sure re your question. I just got the sigma installed and though i'm sure the USB connection is working , I am not familiar with entering commands to the mso5074. As far as the polarity the default polarity on the hieroglyphic for the polarity which i assume is negative shows the first transition from high to low. If I dont change it to low to high  then it misinterprets the data.  Have to make both logic symbols on the trigger and on the decoder i believe positive logic ( with the ist transition low to high) for it to work correctly.

I'm referring to the polarity but RS232 is confusing. Going back 20 or 30 years, there were RS232 ports on computers that exchanged data with RS232 devices such as printers using signals that moved between +15 to -15 volts; these voltages were used to make the communications over long cables more reliable.

When we look at the RS232 signals for microcontrollers on PCBs, they typically move between 0V and 5V or 0V and 3.3V but, when those same RS232 signals travel off the PCB level to an external connector e.g. DB9, they typically are routed through a MAX232 chip  that converts the 0 - 5V signals to -5 to +5 signals and does the opposite with the incoming signal (even thought these are not -15 and +15, it still works and MAX232 ICs typically put out -6 to +6 signals).

Confusingly, all these signals are called RS232 because of the way data is encoded.  There's a popular chip that is an RS232 to USB adapter, the FT232 (there are several others) but the RS232 data signals never run at -ve voltages on that IC.  You can download a free utility for the FT232 that is used to configure the chip and, among the settings, is the ability to invert TX and/or RX signal lines. The de facto standard is for the PCB level RS232 signals to idle high (at a '1') but it's possible to have them idle at a '0'.

So what you see when looking at RS232 signals using a scope depends on where you are putting the scope leads.

Sparkfun has some good explanations here https://www.sparkfun.com/tutorials/215.

[TK]

At microcontroller level, the signal is called UART and usually idles high.  What is called RS232 is after the level converter like the MAX232, where the levels are around +-12V.

About the signal format, it idles high and a start bit, what is needed to identify the start of the frame, is the first High to Low transition, the decoder needs to discard this start bit and then start measuring high and low values until the stop bit (low to high transition).  It is an asynchronous protocol, it is very important to set the parameters correctly: baud, number of bits, idle high or low, parity, stop bits, etc.  As it is just a streaming of level transitions, the 2 devices need to know exactly how the information is encoded.

[MartinMajewski]

Edit: This thread is getting messy!  I eventually found this post: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3025330/#msg3025330

...

5) Download the DS5000Update.GEL file from Post #1558 which is the script that will apply the patch (bspatch). This one will have 130k.

...

No GEL file available at post 1558?! Where do I get the most current GEL file to patch firmware version 00.01.03.00.01 ?

Best wishes,
Martin

[eutectique]

Edit: This thread is getting messy!  I eventually found this post: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg3025330/#msg3025330

Yep, that's the one which works.