New Rigol 16-bit function generators DG800/900 series

[SMB784]

So I have successfully applied the upgrade from DG811 to DG992, and installed the latest firmware.

I have the tools necessary to calibrate this unit, and there is a calibration guide for the DG2000 series floating around on the internet that I have in my possession.  In principle, because the DG800/DG900/DG2000 are extremely similar (if not the same in terms of hardware), I should be able to calibrate this upgraded DG992.

I have tried to access the calibration menu using various combinations of :CAL and other things via SCPI to access the cal menu with no success.  I have also tried pressing all the buttons (and some combinations) during boot up also with no success.  I did however discover that if you pres the "Trig" button repeatedly from the moment you turn the unit on, it takes you to a chinese menu that lets you test the buttons and test the touch screen (see attached photo).

Has anyone been able to successfully use the CAL scpi commands for the DG800/900 described here?  If so, please share and I will happily calibrate this unit and provide the calibration parameters in this post, so that everyone can have a true DG992 with correct performance.

[TurboTom]

Are you sure the CAL guide is the proper one for the recent DG2000 series? There has been a "prehistoric" DG2000 about a decade ago for which I'm aware of calibration instructions, but not for the recent one.

Moreover, it may be necessary to insert the "magic USB key" while calibrating the generator. I'll also be highly interested in the corresponding instructions... 

[SMB784]

Are you sure the CAL guide is the proper one for the recent DG2000 series? There has been a "prehistoric" DG2000 about a decade ago for which I'm aware of calibration instructions, but not for the recent one.

Moreover, it may be necessary to insert the "magic USB key" while calibrating the generator. I'll also be highly interested in the corresponding instructions... 

I have attached a photo of the successful "upgrade" to the DG992 model at the end of this message, with the latest firmware and serial number restoration procedure installed.  It would appear that you are correct, my Cal guide is for the ancient DG2000 series and not the most recent DG2000 series.  This would explain why the cal menu does not exist.

I have tested out various "CAL" SCPI commands mentioned in the Rigol SCPI command list, but I cannot determine whether or not they actually do anything of note (all generate no response).  I am wondering if there is a bootup button sequence that will enable calibration mode.  It's clear that there are at least two independent sequences at bootup (firmware upgrade by hitting utility, screen test by hitting trigger).  However, both have a visible effect by just pressing the key without the insertion of a USB.  This leads me to believe that there is a button sequence that will enable calibration at startup, but that likely needs more than just one button press (maybe two in combination).

[SMB784]

I contacted Rigol to see if they would give me anything on how to calibrate this unit, and their response was that they do not have any way for customers to calibrate it, but that if I needed it to be calibrated that I should contact Transcat. So, it clearly can be calibrated (as if that were in doubt), but clearly it is not a procedure that is doable in any obvious way. Never the less I will soldier on in my quest.

[SMB784]

Alright so I poked around using the SCPI cal commands, and I have discovered the following.

Entering the Cal commands on SCPI with the "send&read" command using Rigol's Ultra Sigma software causes a timeout on the read part of the "send&read" command, and also causes the next SCPI command to throw a protocol error during the transfer of the next SCPI command.

However!  If you simply send the CAL command, and then send&receive the :SYST:ERR? command, it will tell you if the CAL command has returned an error.  I tried this with the :CAL:DATE command and it returns a "-220 parameter error" when :SYST:ERR? is invoked after the :CAL:DATE command is passed.  I then passed :CAL:DATE 09/09/2020 and then invoked :SYST:ERR? and it returned no error, so I think that means I successfully passed a cal date command but I have no idea how to verify that.

Its not much, but its something.  Maybe we can use this to figure out what the correct cal sequence is.

[tv84]

I think Rigol usually uses the :SYST:ERR? after all commands to see if their commanding is going ok.

[SMB784]

I think Rigol usually uses the :SYST:ERR? after all commands to see if their commanding is going ok.

I think you are correct because I passed :CAL:DATE 09/09/2020 and then :SYST:ERR? and it returned no errors, so I believe that this cal command was successful (and probably set the cal date to september 9th 2020).  However, I have no idea how to verify this.  One thing that we may be able to check is the system log (which I have turned on via :SYST:LOG ON).  However, I'm not sure where I could find that.

[SMB784]

Alright so I spoke with Rigol's service department, and they told me pretty much what I expected: these instruments arent intended to be manually calibrated by customers, but the service tech didnt know what mechanism (if there is one) that is preventing this from happening.  They do the calibration in house, and there is no known procedure for circumventing this.  He also mentioned that they do not provide calibration certifications of any kind, so even if the unit was professionally calibrated by them there is no way to document that fact other than the performance verification guide.  He also said that if I wanted a professional calibration with documentation that I could reach out to Transcat, as Rigol contracts with them for calibration services and that they may have more information on the process.  I did contact Transcat and I am awaiting their response, but I am not optimistic given that their entire business is charging people to calibrate things and I'm asking them how they do the calibration for this unit.

So, that said, it looks like there is a software process that performs the calibration.  My best guess is that they use some sequence of SCPI commands to calibrate the unit.  However, unless we can figure out what that sequence of commands is (or come up with some other software solution), I dont think there is a way to calibrate this thing unless jscm2000 can provide us with his method.  Maybe its time to open the unit up and take a look to snoop around in the serial port next to the Spartan 6?

** EDIT **

What do ya'll think this ribbon connector attached to the main processor board is for?  Its not connected to the display, but it looks like a display connector (see attached image)

[TurboTom]

It is the display connector. See the first photo on this page. It's a little bit hard to see since my photographing skills (and gear as well) can be improved on... It's the brown polyimide flex PCB that first sneaks up and then down in the right front-area cutout of the main metal chassis of the instrument.

I don't think that the FPGA's JTAG interface will be that helpful regarding the calibration issue. The ominous three-pin footprint labeled "J2" on the processor board looks like a much more promising candidate to me. Pins 1 and 2 are routed via a resistor each and then vanish in the direction of the CPU. Pin 3 is connected to ground. Could very well be an UART interface with 3.3V CMOS levels.

Edit:
Just had my DG800 apart and hooked up to J2 (first Scope, then UART interface): 1 - TxD, 2 - RxD, 3 - GND. 115200/n/8/1, no handshake. I recorded the bootlog without the front panel attached so I assume this causes the I²C errors:

Code: [Select]


U-Boot SPL 2015.07 (Jul 17 2018 - 16:15:46)
Jumping to U-Boot



U-Boot 2015.07 (Jul 17 2018 - 16:15:46 +0800)


       Watchdog enabled

I2C:   ready

DRAM:  256 MiB

NAND:  512 MiB

MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1

Net:   MAC addr->F4:E1:1E:A1:E5:CC

get PHY for cpsw: addr 1

cpsw

Hit any key to stop autoboot:  1  0

Booting from nand ...


NAND read: device 0 offset 0x400000, size 0x9140

 37184 bytes read: OK


NAND read: device 0 offset 0x500000, size 0x409000

 4231168 bytes read: OK

crc_format = bootm 0x82000000 - 0x88000000.

## Booting kernel from Legacy Image at 82000000 ...

   Image Name:   Linux-3.14.26-rt25

   Created:      2018-07-19   9:09:58 UTC

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    4231104 Bytes = 4 MiB

   Load Address: 80008000

   Entry Point:  80008000

## Flattened Device Tree blob at 88000000

   Booting using the fdt blob at 0x88000000

   Loading Kernel Image ... OK

   Loading Device Tree to 8ef17000, end 8ef23132 ... OK


Starting kernel ...


[    0.527343] mtdoops: mtd device (mtddev=name/number) must be supplied
[    0.600253] cpu cpu0: cpu0 clock notifier not ready, retry
Starting logging: OK
mount user space...
Starting mdev...
modprobe: can't change directory to '3.14.26-rt25': No such file or directory
Initializing random number generator... [    4.243743] random: dd urandom read with 7 bits of entropy available
done.
Starting network: OK
Starting dropbear sshd: OK
Starting sshd: /var/empty must be owned by root and not group or world-writable.

OK
Starting app...
[    4.884799] sardine-adc TI-am335x-adc: initialized


Welcome to RIGOL DG800 system

rigol login: [    4.964771] fram 0-000a: initialized
[    5.022452] beep pwm:beeper,hwpwm:0,period:2000,polarity:0
[    5.032691] pwmdev-beeper beeper.7: initialized
[    5.085729] gpio-led led.8: initialized
[    5.783576] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.789953] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.796808] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.803105] read: i2c_transfer error!
[    5.807276] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.813561] read: i2c_transfer error!
[    5.817751] ts-ft6336U 2-0038: ts_ft_i2c_write i2c write error.
[    5.824049] read: i2c_transfer error!
[    5.829168] input: Rigol-FocalTech TS as /devices/ocp.3/4819c000.i2c/i2c-2/2-0038/input/input0
[    5.925523] input: rigol keyboard as /devices/ocp.3/48022000.serial/input/input1
[    5.954777] rigol-kbd 48022000.serial: initialized!
[    6.035074] usbcore: registered new interface driver usbtmc
[    6.114785] usbcore: registered new interface driver asix
[    6.164791] usbcore: registered new interface driver r8152
rmmod: can't unload module 'usbtmc_dev': No such file or directory
rmmod: can't unload module 'libcomposite': No such file or directory
[   22.312471] Rigol Device gadget: Usb device Gadget, version: 2016 July 26
[   22.319781] Rigol Device gadget: Rigol Device ready
[   22.420986] usbcore: deregistering interface driver usbtmc
[   22.534791] usbcore: registered new interface driver usbtmc
[   30.679919] random: nonblocking pool is initialized


I may install a wire to J2 and run it outside so I can use the instrument with an UART interface attached. Let's see where it takes us...

[SMB784]

I can't seem to pull up any serial output from J2 on the processor board. I have even checked the output on an oscilloscope and there is nothing. What firmware version are you running?

[TurboTom]

Very strange. I'm running F/V 00.02.04 on my DG800 (which started life as a DG811 but believes it's a DG992...). Meanwhile, I installed the break-out cable and reassembled the instrument again. Using Putty, I'm able to "talk" to the instrument but haven't been able to log in yet (lacking the root password). I've been able to stop the boot process in U-Boot and messed around there a little.

IIRC, among other Rigol instruments, there have been some specimen that were missing the resistors that routed the UART lines to the corresponding port pins. You may want to pull the CPU module and check if R113 and R114 are installed. They should be in the ballpark of 330 ohms to 1k ohm.

[SMB784]

Thanks for the heads up, I ended up figuring it out.  What I thought was GND turned out to be TX, so flipping those two fixed it and now I can interact with it via serial over putty.

I have attached my full boot log in this message.  Gonna try some things, maybe we'll get lucky and get root shell access.

[SMB784]

So I logged the serial port output in the 4 different known boot configurations, and got some interesting results.

The first boot configuration is the standard one, no button presses at the start and just let it run through its normal boot process.

The second boot configuration involves repeatedly pressing the "Trig" key as I mentioned before, which puts the system into LCD/button test mode.

The third boot configuration involves pressing the "Help/Local" button repeatedly at startup, which puts the system into USB firmware upgrade mode.

The fourth boot configuration can only be accessed via serial port, and it involves pressing any key before the 1 second timer on the autoboot expires.  This immediately dumps you to a uboot login.

The differences here appear to occur when the device finishes autoboot.  The second boot configuration makes some cryptic references to "entering engineering model" and erasing redundant RAM and mentions a "New crc = 0x4cc6443" towards the end of the boot process. The third boot configuration will either upgrade the firmware from a USB (I didn't check the output for this part yet) or will fail to detect a valid USB and dump you to the uboot login prompt.  The fourth configuration dumps you straight to a uboot login.

All of this leads me to believe that "calibration mode" (if it exists) will likely be accessed by doing something before autoboot finishes, like the other modes.  More investigations tomorrow.  Maybe someone can try to upgrade the firmware while monitoring the serial port.

[tv84]

password: sardine_uboot

[TurboTom]

Can't log in on the console with root / sardine_uboot . Maybe the password is to be used with a different login or not on the serial console? Entry into the uboot shell is possible without any access control.

[tv84]

Keep pressing Crtl-C when booting.

[SMB784]

Can't log in on the console with root / sardine_uboot . Maybe the password is to be used with a different login or not on the serial console? Entry into the uboot shell is possible without any access control.

How did you manage to get into uboot shell without a password? My unit requires a password for uboot (see above)

As for the console login, maybe we can binwalk the login name from the firmware. My bet is that it will use the same password as uboot login

[TurboTom]

Don't know..    My DG811 has a S/N from Q4 2018 so it's probably a rather early specimen. Maybe at that time, Rigol didn't lock Uboot shell with a password. I definitely can get into the shell by just pressing a key when Uboot prompts for it. No password required.

[SMB784]

ok I can confirm that the password sardine_uboot works for logging into the uboot shell.  It does not work for logging into the main console with root login name after the boot process. We still don't know the user name for logging into the post-boot shell

For some reason TurboTom's system does not need a password to log into uboot.  I find this odd, given that I would expect the password requirement to be tied to the firmware version, but maybe its device specific.  Anyway, we are into the uboot shell.  Now for the main console!

[SMB784]

I have attached a dump of various uboot info commands in this message.  This includes a comprehensive list of all commands that can be entered into the uboot shell.  There are some interesting nuggets in there, like RIGOL specific uboot commands and some info on various start up routines.  The only thing I cannot figure out is how to work the "ls" command.  It says it needs a directory to work on, but when I enter "ls /" which is supposedly the default, it spits out the same "this only works on a directory" message.  Does anyone know what the file system looks like so that I can begin poking around and seeing whats available?

Check out the dump and let me know what you think.

[tv84]

Like this?

[SMB784]

Additional dump with fdt command list

[SMB784]

Like this?

Is that the uboot file system or the linux file system?  I tried using ls -laR / in uboot shell but it keeps giving me a "** Bad device specification **" or ** No device specified **

[tv84]

Is that the uboot file system or the linux file system?

I think such thing doesn't exist. If it's a filesystem, it's beyond uboot.

[SMB784]

Is that the uboot file system or the linux file system?

I think such thing doesn't exist. If it's a filesystem, it's beyond uboot.

I see. I wonder how the ls command is supposed to work in uboot shell. I have tried it and all I get is a message saying I haven't specified a device