-
You still have to request firmware?
-
For the DM yes, but for DS, DG, DSA, DSG and DP you can just download it here: http://int.rigol.com/Support/SoftDownload/3
-
Why would you want the GPIB option? The 34461A has USB and LAN as standard which are much easier interfaces to work with.
While I agree that Keysight is a premium brand , getting 34461A+GPIB option to make it roughly the same as stock Rigol DM3068, will cost you about 350$ more...Mee too! I`m getting a DM3068 when I get my money from work and I would need that file, if it doesn't come already upgraded.
Save a bit more and go for a Keysight 6.5 digit DMM! The price difference is too small to settle for second best. -
Why would you want the GPIB option? The 34461A has USB and LAN as standard which are much easier interfaces to work with.
You are right, I don't need GPIB, just trying to compare them on equal terms..
-
Here is the firmware:
http://beyondmeasure.rigoltech.com/acton/ct/1579/s-0744-1511/Bct/l-3f49/l-3f49:1cac/ct3_0/1?sid=QJ41gTN30
Here are the release Notes:
http://beyondmeasure.rigoltech.com/acton/ct/1579/s-0744-1511/Bct/l-3f49/l-3f49:1cac/ct6_0/1?sid=QJ41gTN30
Thanks for sharing the firmware!
After seeing Daves video about the 34461A, I decided to stick with the Rigol. My reasons are that the Rigol has capacitance and the Agilent doesn't (altough I heard that they changed that with a firmware update ?). Then there is money. Even if the Agilent doesn't cost much more, it's still too much for me as a soon to be student. This will be my last big purchase for electronic gear in some time. -
FYI: The Keysight 34461A also has capacitance measurement. However if you are tight on money you have to ask yourself whether you really need a 6.5 digit DMM.
-
If you already own it no point in switching, if you're going to buy a new meter also consider resale value down the road. In five/ten years time odds are the Keysight will hold much better value.
-
We just need to bug Rigol to fix the Agilent compatibility functions. Then we could use benchvue software.
Reading everyone comments. I'm still very happy with the Rigol DM3068 meter. It has served me good the last two months. The Meat and Potatoes meter that I was looking for. -
We just need to bug Rigol to fix the Agilent compatibility functions. Then we could use benchvue software.
Reading everyone comments. I'm still very happy with the Rigol DM3068 meter. It has served me good the last two months. The Meat and Potatoes meter that I was looking for.
This is exactly how I feel.. There was a new firmware made available in last few days... In release notes says: ....." 5. Add a remote command to modify *IDN? command response data" .....
Also, fixes for READ? command and USB reconnecting... I would say mostly fixes with SCPI to emulate Agilent ... I loaded it today, went fine, but didn't have time to test ..
-
Anyone got a direct link for the DM3058 (not 3068) firmware please? I just bought one secondhand in China for a bargain price, and it has rather old firmware.
-
Anyone got a direct link for the DM3058 (not 3068) firmware please? I just bought one secondhand in China for a bargain price, and it has rather old firmware.
It would help if you actually stated what firmware you have? As far as I know I have the very very latest which is years old. There is a very good chance of bricking your meter with a firmware change as has happened to me. I found out what caused it and recovered my meter using JTAG, vs sending it back to Rigol, spent many hours reporting to Rigol Germany how I could recreate this DMM bricking every time, and they bricked their own meter when they finally did the same procedure, but refuse to acknowledge any fault and just gaslighted me all along.
I can say please never ever run "Rigol UltraSensor" if you have a DM3058. It doesn't work anyway, never mind the fact it can brick your meter if you try to flash the firmware after using it.
DM3058_01.01.00.02.02.00.02 is the latest that I have and dates to 2015. I don't have a direct link but could stick it on Mega or something if you have no joy from Rigol. -
Thanks. I have 01.01.00.01.05.01, and I want to use this over Ethernet; I understand the later firmware fixes some issues with the SCPI commands.
I have actually found that if you put your name / email in the form at
https://beyondmeasure.rigoltech.com/acton/formfd/1579/0025:d-000d
it downloads the firmware straight away, no need for anything to be emailed, but I now have a different problem.
The device just fails to respond when a USB drive (FAT32) is inserted. It doesn't start the firmware load as it should, and it does not show up as an A: drive for saving either. I'm beginning to suspect a borked USB port.
-
Thanks. I have 01.01.00.01.05.01, and I want to use this over Ethernet; I understand the later firmware fixes some issues with the SCPI commands.
That appears to be a very old firmware, my earliest is 01.01.00.02.01.00.01 and dates back to 08/2012.QuoteThe device just fails to respond when a USB drive (FAT32) is inserted. It doesn't start the firmware load as it should, and it does not show up as an A: drive for saving either. I'm beginning to suspect a borked USB port.
Have you tried smaller/older USB drives? Perhaps the firmware is so old it can't cope with the larger capacity USB sticks.
Failing that if you don't mind getting your hands dirty you could flash the latest firmware using JTAG. -
Rigol instruments are quite picky about their USB sticks.
I've had one that my DG4000 function generator recognizes but won't load firmware from while the same stick works perfectly fine in my DS4000 scope, for saving screenshots and loading firmware. At that time I knew about the instruments could be picky but since the stick worked fine with the scope I convinced myself that wasn't the problem - but it was.
I think in general you should do what Macbeth suggests and try using the smallest USB stick you can find. -
Failing that if you don't mind getting your hands dirty you could flash the latest firmware using JTAG.
That's handy. Any pointers on how to do that will be gratefully received.
Before I go down that route I'll try to find an old and small USB memory stick. -
Another thing to try is to chkdsk/repair the USB stick on a Windows machine and make sure to 'eject' it properly from the OS. The MS FAT library that Rigol uses (mfs) is not very sophisticated and, depending on the version, often completely intolerant of minor filesystem issues.
-
Failing that if you don't mind getting your hands dirty you could flash the latest firmware using JTAG.
That's handy. Any pointers on how to do that will be gratefully received.
Before I go down that route I'll try to find an old and small USB memory stick.
I tried a 512MB memory stick and that didn't work either. This has a light on it, and it flashes very briefly as the usb stick is inserted instead of staying on as it does on other devices. Seems like the USB port is not working properly.
Still waiting for any pointers on the JTAG way, if anyone can help. I didn't find much with Google.
-
Still waiting for any pointers on the JTAG way, if anyone can help. I didn't find much with Google.
Possibly because I'm the only idiot persistent enough to fix it myself vs send back to China. It's been a while, I will have to dig out some old Linux stuff, but I worked out the memory map of the DM3058 and found a safe way to flash it in stages with JTAG.
Do you have a JTAG USB programmer at all? Do you use Linux? -
Yes, I have Linux in a VM, and I have an Altera Blaster JTAG Programmer if that's any use. Otherwise - what do you suggest?
-
Yes it should work with the Altera USB Blaster, I've not tried it myself but it is supported by the Blackfin toolchain. I used an Olimex ARM-USB-OCD (which an ebayer sold me as the faster ARM-USB-OCD-H
- I got a partial refund on it though. I think the Blaster should run at the same slow speed)
I'm assuming you already have your Blaster set up in Linux, compiled ftdi drivers and all? if so go ahead and install the Blackfin tools:
https://blackfin.uclinux.org/doku.php?id=toolchain:installing
You can test it's working by running the bfin-jtag command and cable probe which should find it on USB. You may find you run into permission problems.
In the highly unlikely event that all is working you can go ahead and connect to the DM3058.
I've attached a diagram for my Olimex. You should be able to remap the pins to suit the Blaster. I think you will need the second circuit with the 2 resistors.
Use the detect command in bfin-jtag after the cable probe to see if all is well.
I'll dig out the other stuff later on (I have to reboot from Win to Linux to access it). You have plenty enough to be getting on with for now!
-
Set it all up, and as long as I run it as root, it looks good:
jtag> cable probe
Found USB cable: UsbBlaster
Connected to libftdi driver.
The USB Blaster has a 10 pin connector, so I did need the circuit with the 2 resistors. Thanks for all the help so far.
-
Wired it all up, and seems good so far:
IR length: 5
Chain length: 1
Device Id: 01100010011110100101000011001011 (0x627A50CB)
Manufacturer: Analog Devices, Inc. (0x0CB)
Part(0): BF533 (0x27A5)
Stepping: 6
Filename: /opt/uClinux/bfin-uclinux/bin/../share/urjtag/analog/bf533/bf533
warning: UsbBlaster: untested cable, set wait_clocks to 30
Standing by for further instructions...
-
Looking good. Ok, the DM3058 has 4MB flash memory at 0x20000000 and the layout is:
0x000000 - 0x1dffff : Firmware
0x1e0000 - 0x1e00ff : Serial No, Version, CAL ID
0x1f0000 - 0x1f0dff : Calibration data?
0x200000 - 0x3fffff : Unused flash
You will want to make a full backup before flashing. Make a dm3058 folder in your home dir. Run bfin-jtag and...
cable probe
frequency 6000000 // This is the max speed for my Olimex. Experiment with Blaster. After setting just type frequency on its own and it reports its setting.
detect
initbus bf533_stamp // or bf533_ezkit or bf53x
detectflash 0x20000000
endian little
readmem 0x20000000 0xfffff /home/user/dm3058/backup_0x20000000_block0
readmem 0x20100000 0xdffff /home/user/dm3058/backup_0x20100000_block1
readmem 0x201e0000 0x0ffff /home/user/dm3058/backup_0x201e0000_serial
readmem 0x201f0000 0x0ffff /home/user/dm3058/backup_0x201f0000_calibration
instr bypass
shift ir
quit
You may want to dump the 0x20200000 and 0x20300000 blocks too but I didn't find anything in them other than 0xFF's and 0x80's.
The bf533 jtag driver only seems to work with up to 1MB blocks max otherwise it just repeats itself.
Ok, after checking your results in a hex editor you are ready to flash the new firmware. The Rigol DM3058_System.ldr needs to be split, so put it in your dm3058 dir.
The file as provided by Rigol has an identifier in the first 48 bytes which we need to strip out. For some reason the end of the file also contains the serial number from another meter at the 1e0000 block and totally blank data at the 1f0000 block which I believe contains the calibration and we certainly do not want to overwrite either! So
cd /home/user/dm3058
dd if=DM3058_System.ldr of=DM3058_block0 skip=49 count=1048576 iflag=skip_bytes,count_bytes
dd if=DM3058_System.ldr of=DM3058_block1 skip=1048625 count=917504 iflag=skip_bytes,count_bytes
and to flash it run bfin-jtag and...
cable probe
frequency 6000000 // replace with your highest speed
detect
initbus bf533_stamp
detectflash 0x20000000
endian little
flashmem 0x20000000 /home/user/dm3058/DM3058_block0
flashmem 0x20100000 /home/user/dm3058/DM3058_block1
instr bypass
shift ir
quit
After an eternity you should be able to reboot the meter and all is well!
I wouldn't mind a copy of your backed up firmware. I have a hunch that the UltraSensor software (which bricked my DMM) only works with very early firmware and am masochistic enough to experiment
-
Hmm, this has ended in tears.
The backup seemed to run OK, apart from warning me the USB Blaster has a fixed frequency of 12000000.
However, when I tried to write the first block of the new firmware, after ages, it went like this, ending with a verification failure:
jtag> detectflash 0x20000000
Query identification string:
Primary Algorithm Command Set and Control Interface ID Code: 0x0002 (AMD/Fujitsu Standard Command Set)
Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null)
Query system interface information:
Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700 mV
Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mV
Vpp [Programming] Supply Minimum Write/Erase voltage: 0 mV
Vpp [Programming] Supply Maximum Write/Erase voltage: 0 mV
Typical timeout per single byte/word program: 128 us
Typical timeout for maximum-size multi-byte program: 128 us
Typical timeout per individual block erase: 1024 ms
Typical timeout for full chip erase: 0 ms
Maximum timeout for byte/word program: 1024 us
Maximum timeout for multi-byte program: 4096 us
Maximum timeout per individual block erase: 16384 ms
Maximum timeout for chip erase: 0 ms
Device geometry definition:
Device Size: 4194304 B (4096 KiB, 4 MiB)
Flash Device Interface Code description: 0x0002 (x8/x16)
Maximum number of bytes in multi-byte program: 32
Number of Erase Block Regions within device: 2
Erase Block Region Information:
Region 0:
Erase Block Size: 8192 B (8 KiB)
Number of Erase Blocks: 8
Region 1:
Erase Block Size: 65536 B (64 KiB)
Number of Erase Blocks: 63
Primary Vendor-Specific Extended Query:
Major version number: 1
Minor version number: 3
Address Sensitive Unlock: Required
Process Technology: Bad value
Erase Suspend: Read/write
Sector Protect: 1 sectors per group
Sector Temporary Unprotect: Supported
Sector Protect/Unprotect Scheme: Bad value
Simultaneous Operation: Not supported
Burst Mode Type: Supported
Page Mode Type: 8 word Page
ACC (Acceleration) Supply Minimum: 11500 mV
ACC (Acceleration) Supply Maximum: 12500 mV
Top/Bottom Sector Flag: Bottom boot device
Program Suspend: Not supported
jtag> endian little
jtag> flashmem 0x20000000 DM3058_block0
Chip: AMD Flash
Manufacturer: AMD
Chip: S92GLxxxN
Protected: 0001
program:
flash_unlock_block 0x20000000 IGNORE
block 0 unlocked
flash_erase_block 0x20000000
flash_erase_block 0x20000000 DONE
erasing block 0: 0
flash_unlock_block 0x20002000 IGNORE
... lots more like this
block 22 unlocked
flash_erase_block 0x200F0000
flash_erase_block 0x200F0000 DONE
erasing block 22: 0
addr: 0x200FFFFE
verify:
error: flash program: addr: 0x200000D8
verify error:
read: 0x0000D822
expected: 0x0000FA62
I retried it, and got exactly the same verification failure.
I wonder if the Protected: 0001 had anything to do with it.
On the other hand, something was probably written, as the meter no longer boots.
I also have a PSOC Miniprog 3 which will do JTAG programming, so I'll see if I can use that instead, [update: no, I can't].
Any further insights gratefully received, thanks. -
Hmm... Have you tried using initbus bf533_ezkit instead of bf533_stamp? I remember having issues with one or the other.
Also, you should be able to recover the meter to where it was using your backed up firmware.
I have to confess when I recovered my bricked meter I just re-flashed the existing firmware (2.1) over its corrupted self. I didn't actually change the firmware version this way. I did the upgrade to 2.2 using USB.
Which leads me to another thing, I imagine you would want to make a copy of your backup_0x201e0000_serial and then patch in the new version number and flash that to 201e0000. But thats for later.