Author Topic: Rigol DM3058/DM3068 firmware updates available for request online - finally! (Read 22615 times)

Macbeth · « **on:** March 24, 2015, 11:38:47 pm »

I just noticed that Rigol have updated the firmware request form to include the DMM's that have so far been lacking.

New firmware 01.01.00.02.02.00.02 for my DM3058E (currently 01.01.00.02.01.00). Version 01.01.00.01.08.00.01 is available for DM3068. There seems to be an extra 2 decimals on the website description

Also noticed a new DM3058 Calibration Guide dated Feb 2015

(Oh, and don't even attempt to flash upgrade a 3058 to a 3068!

I would love to, but despite them looking the same they are completely different inside - 3068 uses an LM399H ref for starters)

Macbeth · « **Reply #1 on:** March 25, 2015, 12:08:51 am »

Reading the calibration guide, Rigol recommend using a Fluke 5520A. It has been discontinued and even used ones are a little pricey, but this ebay seller has one for only $35,000. Bargain! I'll just blow the cobwebs from my wallet. Oh wait - "I cannot ship internationally"

Aah well, never mind. My trusty Hao Qi Xin will have to make do instead...

xrunner · « **Reply #2 on:** March 25, 2015, 12:35:00 am »

Thanks for posting that, I have a DM3058E and I'll be requesting the firmware.

wraper · « **Reply #3 on:** March 25, 2015, 12:56:16 am »

They send me the link for the DM3068 firmware in just 11 minutes. Really unusual, in the past it took at least few days when I requested firmware for various Rigol equipment.
Firmware was 01.01.00.01.08.00 after update additional .01 did not appear and displayed version still remains the same. However when I requested firmware before, they did not provide it, just said that my firmware is the latest.

DM3068 firmware and update manual links for anyone interested:
http://beyondmeasure.rigoltech.com/acton/ct/1579/s-0598-1501/Bct/l-3f49/l-3f49:b33/ct2_0/1?sid=spuZipILE
http://beyondmeasure.rigoltech.com/acton/ct/1579/s-0598-1501/Bct/l-3f49/l-3f49:b33/ct4_0/1?sid=spuZipILE

2Bad4u · « **Reply #4 on:** March 25, 2015, 02:51:58 am »

Quote from: wraper on March 25, 2015, 12:56:16 am

They send me the link for the DM3068 firmware in just 11 minutes. Really unusual, in the past it took at least few days when I requested firmware for various Rigol equipment.
Firmware was 01.01.00.01.08.00 after update additional .01 did not appear and displayed version still remains the same. However when I requested firmware before, they did not provide it, just said that my firmware is the latest.

DM3068 firmware and update manual links for anyone interested:
http://beyondmeasure.rigoltech.com/acton/ct/1579/s-0598-1501/Bct/l-3f49/l-3f49:b33/ct2_0/1?sid=spuZipILE
http://beyondmeasure.rigoltech.com/acton/ct/1579/s-0598-1501/Bct/l-3f49/l-3f49:b33/ct4_0/1?sid=spuZipILE

I also requested the FW upgrade and received the update email/link within a few minutes - like all other updates that I received in the past. Due to the quick response I suspect that these requests are being processed by an automated script.

Like yourself the FW version number did not change after completing the update. Did a quick look at all of the menus and didn't notice any new/different options so I assume that it is just a bug fix. Rigol should document their FW changes in a readme file.

I've only had the 3068 for about a month now but I'm very pleased with the purchase.

Macbeth · « **Reply #5 on:** March 25, 2015, 03:06:11 pm »

I also got the firmware link by email within minutes. The changes I have noticed on my DM3058E are:

Boot screen shows Version: 02.02.00
Utility>T/C>Info shows Version: 01.01.00.02.02.00
Continuity test is now latched (it's still very fast but with no more crackling)

Histogram shows min/max values (at least I think this is new)

Unfortunately the diode test is still limited to displaying voltages <2V or so, even though the hardware will output enough to light up green & white LEDs.

It's a shame the DM3068 Trendline feature hasn't been added. They have the code already and there is plenty of room for it in the firmware. But I guess that is why I don't work in marketing.

thn788 · « **Reply #6 on:** March 25, 2015, 03:51:23 pm »

Similar to other Rigol products, the full version number is only shown after activating some hidden function. If you don't do this, the DM3068 doesn't show the last digit of the Firmware version number. If you search through the FAQ-documents Rigol lists on their DM3068 product page, you will find a PDF "How do I view the full version information for the DM3068?", which explains the procedure but it's pretty simple and I'll just copy the steps here:

Press 'Utility'
Select 'T/C'
Hold the fifth key for 3s to show the ex version
Hold the same key for 3s to hide the ex version

"Fifth key" means the fifth multi-function key just below the display (counting from the left).

I received my brand new DM3068 just a few days ago and it already shows version number 01.01.00.01.08.00.01, which is supposed to be the most recent version already according to the previous posts and Rigol's Firmware Update Request page. So I can't tell you whether older DM3068s do indeed show a different -- probably ".00" -- version number at the very end or the new DM3068 firmware mentioned here is just the same that has been shipped on all DM3068s so far (and some previous posters just re-installed the same firmware image, they had already installed).

KedasProbe · « **Reply #7 on:** March 25, 2015, 03:54:27 pm »

Although the website does show an new update date for the DM3068 manual it is the same PDF file as before so no big changes expected, maybe some bug fix (probably network)

xrunner · « **Reply #8 on:** March 25, 2015, 05:03:32 pm »

Requested and got the firmware for the DM3058E a few minutes ago. I copied onto a USB stick I had and plugged it in to the meter ...

Nothing happened.

I then formatted the USB stick again and tried it all over again - again not a thing happened.

After thinking about my options, I looked at the formatting of the USB stick, it was NTFS. I took a long shot and re-formatted it to FAT32 and presto - firmware upgraded!

The version before was

02.01.00

and it is now

02.02.00

lho · « **Reply #9 on:** March 26, 2015, 02:20:08 pm »

Hi,

And what about any calibration loose on the DM3068 ?

Lho

wraper · « **Reply #10 on:** March 26, 2015, 02:26:22 pm »

Quote from: lho on March 26, 2015, 02:20:08 pm

Hi,

And what about any calibration loose on the DM3068 ?

Lho

Why should it be lost?

KedasProbe · « **Reply #11 on:** March 26, 2015, 02:28:05 pm »

Quote from: lho on March 26, 2015, 02:20:08 pm

Hi,

And what about any calibration loose on the DM3068 ?

Lho

There is no calibration loss for the DM3068 (or DM3058), if there is you would be the first one. (that problem existed only on an older Rigol DMM)

Macbeth · « **Reply #12 on:** March 26, 2015, 02:46:25 pm »

On reading the newly released calibration guide for the DM3058 it appears there is a factory certified calibration stored in the meter, with further user calibration being stored separately. So even if you did ruin the user calibration you can always go back to stock

You can only change the user calibration with a password. The firmware upgrade does not affect the calibration.

lho · « **Reply #13 on:** March 26, 2015, 08:30:41 pm »

Quote from: wraper on March 26, 2015, 02:26:22 pm

Quote from: lho on March 26, 2015, 02:20:08 pm
Hi,

And what about any calibration loose on the DM3068 ?

Lho
Why should it be lost?

I was thinking about non-volatile memory change...

mcinque · « **Reply #14 on:** March 27, 2015, 12:40:23 pm »

Interesting, anyone has a changelog for the 3058 update?

mrkva · « **Reply #15 on:** September 17, 2015, 10:18:48 pm »

Bump for the changelog!

Dwaine · « **Reply #16 on:** June 28, 2016, 11:55:48 pm »

The last firmware update was in March of 2016 (Version 01.01.00.01.10.00.00). Has anyone heard if Rigol is going to add latching continuity to the DM3068 DMM?

Macbeth · « **Reply #17 on:** June 29, 2016, 12:57:29 am »

Quote from: Dwaine on June 28, 2016, 11:55:48 pm

The last firmware update was in March of 2016 (Version 01.01.00.01.10.00.00). Has anyone heard if Rigol is going to add latching continuity to the DM3068 DMM?

Really? Their website still lists

Code: [Select]

DM3058 and DM3058E: 01.01.00.02.02.00.02 {March 12, 2015}

DM3068: 01.01.00.01.09.00 {October 13, 2015}

I thought the continuity thing was dealt with? It seems ok on the 3058 though the volume is low.

More important to me with the 3058 are the "not fit for purpose" things like Agilent compatibility is totally useless, the reading hold (those big flashing light trigger buttons) are also completely useless, and another selling point for the temperature compensated cold junction being utterly useless for a bench DMM as it is not possible to log the temperature readings. I also found a simple way to brick my meter using Rigols own software and different firmware versions with it. I have reported all of these over the years. Nothing has been fixed.

They are not interested in these major issues - what on earth makes you think they care about a trivial continuity buzzer issue?

Dwaine · « **Reply #18 on:** June 29, 2016, 08:13:05 am »

I requested the newest firmware through the request web url and they forward firmware version 01.01.00.01.10.00.00 for the DM3068.

cidak · « **Reply #19 on:** August 29, 2016, 08:38:07 pm »

Quote from: Dwaine on June 29, 2016, 08:13:05 am

I requested the newest firmware through the request web url and they forward firmware version 01.01.00.01.10.00.00 for the DM3068.

I would be very grateful if you, or someone else, can send privately or post here, the firmware in question.
Thank you.

TurboTom · « **Reply #20 on:** August 29, 2016, 09:10:06 pm »

Quote from: cidak on August 29, 2016, 08:38:07 pm

Quote from: Dwaine on June 29, 2016, 08:13:05 am
I requested the newest firmware through the request web url and they forward firmware version 01.01.00.01.10.00.00 for the DM3068.

I would be very grateful if you, or someone else, can send privately or post here, the firmware in question.
Thank you.

+1

... I'ld also be interested in the update file!

Thanks,
Thomas

Rbastler · « **Reply #21 on:** August 30, 2016, 05:46:32 am »

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.

Dwaine · « **Reply #22 on:** August 30, 2016, 06:21:21 am »

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

nctnico · « **Reply #23 on:** August 30, 2016, 08:00:13 am »

Quote from: Rbastler on August 30, 2016, 05:46:32 am

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.

2N3055 · « **Reply #24 on:** August 30, 2016, 12:20:21 pm »

Quote from: nctnico on August 30, 2016, 08:00:13 am

Quote from: Rbastler on August 30, 2016, 05:46:32 am
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.

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...
For people that are short on money that means an entry level scope and 6 1/2 digit multimeter for the money...

Fact is, Rigol is not really Keysight, but is no crap either... It'll do the job... And if you are buying equipment from the scratch, having two instruments different decent instruments is more useful than having one great piece of equipment...

That is always the dilemma...

Take care Nico

EEVblog · « **Reply #25 on:** August 30, 2016, 12:41:35 pm »

You still have to request firmware?

H.O · « **Reply #26 on:** August 30, 2016, 12:54:02 pm »

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

nctnico · « **Reply #27 on:** August 30, 2016, 02:38:13 pm »

Quote from: 2N3055 on August 30, 2016, 12:20:21 pm

Quote from: nctnico on August 30, 2016, 08:00:13 am
Quote from: Rbastler on August 30, 2016, 05:46:32 am
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.
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...

Why would you want the GPIB option? The 34461A has USB and LAN as standard which are much easier interfaces to work with.

2N3055 · « **Reply #28 on:** August 30, 2016, 02:44:57 pm »

Quote from: nctnico on August 30, 2016, 02:38:13 pm

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..

Rbastler · « **Reply #29 on:** August 30, 2016, 03:42:18 pm »

Quote from: Dwaine on August 30, 2016, 06:21:21 am

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.

nctnico · « **Reply #30 on:** August 30, 2016, 03:56:25 pm »

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.

TheSteve · « **Reply #31 on:** August 30, 2016, 04:40:12 pm »

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.

Dwaine · « **Reply #32 on:** August 30, 2016, 05:38:29 pm »

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.

2N3055 · « **Reply #33 on:** August 30, 2016, 09:05:32 pm »

Quote from: Dwaine on August 30, 2016, 05:38:29 pm

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 ..

ralphrmartin · « **Reply #34 on:** December 10, 2017, 01:02:09 pm »

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.

Macbeth · « **Reply #35 on:** December 10, 2017, 09:21:40 pm »

Quote from: ralphrmartin on December 10, 2017, 01:02:09 pm

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.

ralphrmartin · « **Reply #36 on:** December 11, 2017, 01:15:04 pm »

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.

Macbeth · « **Reply #37 on:** December 11, 2017, 03:15:44 pm »

Quote from: ralphrmartin on December 11, 2017, 01:15:04 pm

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.

Quote

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.

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.

H.O · « **Reply #38 on:** December 11, 2017, 07:33:05 pm »

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.

ralphrmartin · « **Reply #39 on:** December 11, 2017, 11:49:54 pm »

Quote from: Macbeth on December 11, 2017, 03:15:44 pm

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.

smithnerd · « **Reply #40 on:** December 12, 2017, 12:09:53 am »

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.

ralphrmartin · « **Reply #41 on:** December 17, 2017, 08:35:27 pm »

Quote from: ralphrmartin on December 11, 2017, 11:49:54 pm

Quote from: Macbeth on December 11, 2017, 03:15:44 pm
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.

Macbeth · « **Reply #42 on:** December 17, 2017, 09:28:52 pm »

Quote from: ralphrmartin on December 17, 2017, 08:35:27 pm

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?

ralphrmartin · « **Reply #43 on:** December 18, 2017, 01:35:44 pm »

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?

Macbeth · « **Reply #44 on:** December 18, 2017, 08:35:45 pm »

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!

ralphrmartin · « **Reply #45 on:** December 19, 2017, 10:38:09 am »

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.

ralphrmartin · « **Reply #46 on:** December 19, 2017, 11:58:36 am »

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...

Macbeth · « **Reply #47 on:** December 19, 2017, 02:37:42 pm »

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

ralphrmartin · « **Reply #48 on:** December 20, 2017, 08:06:23 am »

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.

Macbeth · « **Reply #49 on:** December 20, 2017, 01:42:32 pm »

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.

ralphrmartin · « **Reply #50 on:** December 20, 2017, 02:48:03 pm »

Yes, tried
initbus bf533_ezkit
with exactly the same result.

Maybe I need to get hold of an olimex arm jtag programmer like you have, and see if that works.

I note your info says you have a DM3058E - but mine is a DM3058. I wonder if the hardware / flash memory layout is the same?

Macbeth · « **Reply #51 on:** December 20, 2017, 03:58:37 pm »

Ralph, I fear your observation of "Protected: 0001" is correct.

I connected my Olimex to my DM3058E and decided to test reading and writing to some "safe" unused areas. e.g. the 64k block at 0x201d0000 is nothing but 0xFF's and the blocks over 0x20200000 appear unused just random 0xF0 and 0x80's.

So I created a test file of 64k zeroes dd if=/dev/zero ibs=1k count=64 of=test.bin

I chose a few "safe" locations 0x201d0000, 0x20220000, 0x20310000. I could readmem 0x201d0000 0xffff /home/mac/dm3058/0x201d0000.bak and then flashmem 0x201d0000 /home/mac/dm3058/test.bin and it wrote and verified successfully. I then flashmem'ed the .bak file to recover that block.

Trying the same with the 0x2022, 0x2031 blocks I got verify errors and indeed nothing was overwritten on those blocks.

FWIW the hardware is the same, only difference is no LXI/GPIB board on the DM3058E.

So it appears I did get away with reflashing my firmware without knowing of this protection. There were no verify errors because the protected blocks had the same code, and wherever the corruption happened to be in unprotected blocks and was overwritten successfully. Damn.

We need to look into how to unprotect the flash. In the meantime you should be able to recover the brick by flashing your backed up firmware, just the first block should do as I don't think you got as far as flashing the 2nd.

As for the USB - ok its obvious, but have you checked for continuity from the socket to the mainboard? There's a narrow 5 way flatflex between them. Maybe yours is damaged?

Macbeth · « **Reply #52 on:** December 20, 2017, 06:16:56 pm »

Ok, I decided to put my money where my mouth is and try flashing my meter. I will start with backing up my 02.02 firmware. You can compare my log to yours.

Code: [Select]

UrJTAG 0.10 #
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.

warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.

jtag> cable probe
Found USB cable: ARM-USB-OCD
Connected to libftdi driver.
jtag> detect
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: ARM-USB-OCD: untested cable, set wait_clocks to 30
jtag> initbus bf533_ezkit
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> readmem 0x20000000 0xfffff /home/user/dm3058/backup_0x20000000_block0
address: 0x20000000
length:  0x00100000
reading:
addr: 0x20100000
Done.
jtag> readmem 0x20100000 0xdffff /home/user/dm3058/backup_0x20100000_block1
address: 0x20100000
length:  0x000E0000
reading:
addr: 0x201E0000
Done.
jtag> readmem 0x201e0000 0x0ffff /home/user/dm3058/backup_0x201e0000_serial
address: 0x201E0000
length:  0x00010000
reading:
addr: 0x201F0000
Done.
jtag> readmem 0x201f0000 0x0ffff /home/u/dm3058/backup_0x201f0000_calibration
address: 0x201F0000
length:  0x00010000
reading:
addr: 0x20200000
Done.
jtag> instr bypass
jtag> shift ir
jtag> quit

Ok, now I was a bit worried about the serial number/version block, it does appear to have some kind of CRC in it looking at my 2.1 and 2.2 backups. This could mean a bricked meter if there is some kind of check. Obviously the USB flashing procedure does not alter the serial but does change the firmware version string.

So I made a copy of backup_0x201e0000_serial and edited the file changing version string to 01.02.03.04.05.06.07 and serial to DM3R666666666. I ignored the CRC like bytes at the end.

Code: [Select]

UrJTAG 0.10 #
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.

warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.

jtag> cable probe
Found USB cable: ARM-USB-OCD
Connected to libftdi driver.
jtag> frequency 6000000
Setting TCK frequency to 6000000 Hz
jtag> detect
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: ARM-USB-OCD: untested cable, set wait_clocks to 30
jtag> initbus bf533_ezkit
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 0x201e0000 /home/andy/dm3058/0x201e0000_serial
Chip: AMD Flash
	Manufacturer: AMD
	Chip: S92GLxxxN
	Protected: 0001
program:
flash_unlock_block 0x201E0000 IGNORE

block 37 unlocked
flash_erase_block 0x201E0000
flash_erase_block 0x201E0000 DONE
erasing block 37: 0
addr: 0x201EFFFE
verify:
addr: 0x201EFFFE
Done.
jtag> instr bypass
jtag> shift ir
jtag> quit

Appears to have flashed without issue. Rebooted the meter (hard power off using the switch at the back - the soft power can be troublesome I've found) and...

The meter works just fine.

Now I will downgrade the meter to 02.01 using the ordinary USB flash and attempt upgrading it to 02.02 using JTAG...

bson · « **Reply #53 on:** December 20, 2017, 06:21:33 pm »

flash erase_address and flash write_image both have an optional parameter to unlock the protection.

Macbeth · « **Reply #54 on:** December 20, 2017, 07:48:18 pm »

Quote from: bson on December 20, 2017, 06:21:33 pm

flash erase_address and flash write_image both have an optional parameter to unlock the protection.

Thank you bson. I've just attempted to upgrade my 2.1 to 2.2 by JTAG and the verify failed near the start of the first 1MB block. I flashed the second 1MB chunk and it verified ok.

I dumped the first 1MB block and did a hex diff with what should have been there and found the first 0x3fff bytes appear to be the ones locked, the rest are ok.

The first 8 blocks are 8k each so that looks like the first 2 blocks need to be unlocked.

dd if=DM3058_block0 of=test count=$((0x4000)) iflag=count_bytes

Code: [Select]

jtag> help unlockflash
Usage: unlockflash ADDR BLOCKS
Unlock flash memory from ADDR.

ADDR       target address for erasing block
BLOCKS     number of blocks to lock

ADDR and BLOCKS could be in decimal or hexadecimal (prefixed with 0x) form.

Supported Flash Memories:
AMD/Fujitsu Standard Command Set  supported: AMD 29LV640D, 29LV641D, 29LV642D; 2x16 Bit
AMD/Fujitsu Standard Command Set  supported: AMD 29LV800B, S29GLxxxN; MX29LV640B, W19B320AT/B; 1x16 Bit
AMD/Fujitsu Standard Command Set  supported: AMD 29LV160, AMD 29LV065D, AMD 29LV040B, S29GLxxxN, W19B320AT/B; 1x8 Bit
Intel Standard Command Set        supported: 28Fxxxx, 2 x 16 bit
Intel Standard Command Set        supported: 28Fxxxx, 1 x 16 bit
Intel Standard Command Set        supported: 28Fxxxx, 1 x 8 bit
AMD Standard Command Set          supported: AMD 29LV040B, 29C040B, 1x8 Bit
jtag> 
jtag> unlockflash 0x20000000 2 
Chip: AMD Flash
	Manufacturer: AMD
	Chip: S92GLxxxN
	Protected: 0001

Unlocking 2 Flash blocks from address 0x20000000
(50% Completed) FLASH Block 0 : unlocking ... flash_unlock_block 0x20000000 IGNORE
(100% Completed) FLASH Block 1 : unlocking ... flash_unlock_block 0x20002000 IGNORE
(100% Completed) FLASH Block 1 : unlocking ... Ok.

Unlocking Completed.
jtag> flashmem 0x020000000 /home/user/dm3058/test
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

block 1 unlocked
flash_erase_block 0x20002000
flash_erase_block 0x20002000 DONE
erasing block 1: 0
addr: 0x20003FFE
verify:
error: flash program: addr: 0x200000D8
 verify error:
read: 0x0000F9A0
expected: 0x0000FA62

jtag>

I dunno why the IGNORE thing comes up

ralphrmartin · « **Reply #55 on:** December 21, 2017, 03:34:32 pm »

As noted,
unlockflash 0x20000000 2
says it is unlocked, but still results in verification errors. It seems a protection mechanism is preventing writing after unlocking (or unlocking itself).

I'll see if I can get the correct firmware to flash from Rigol, as my backup was somehow borked.

Chris56000 · « **Reply #56 on:** January 06, 2018, 11:29:20 pm »

Hi!

I'm hoping to get a bricked one next week as a repair project!

Can anyone tell me:-

1) Is it possible to use a TL866 programmer to reflash this meter? If not can someone post pics/ebay links for an inexpensive JTAG tool and details of how to do it using a Windows machine - I'm afraid Linux makes my head go round!

2) I notice from the pictures provided that these meters use a common monochrome graphic LCD - would it be possible to disassemble Rigol's FW to drive a multi-colour display a bit like the Chinese colour-display variants of the Transistor Testers, or is that too great a task that's beyond the capabilities of the hardware?

Chris Williams

jraut · « **Reply #57 on:** December 07, 2018, 04:13:57 am »

Quote from: ralphrmartin on December 21, 2017, 03:34:32 pm

As noted,
unlockflash 0x20000000 2
says it is unlocked, but still results in verification errors. It seems a protection mechanism is preventing writing after unlocking (or unlocking itself).

I'll see if I can get the correct firmware to flash from Rigol, as my backup was somehow borked.

Sorry to resurrect an old thread. Did anyone ever figure out how to unlock and/or overwrite locked bytes/blocks?

I've got a bricked DM3058 I'm trying to resurrect.

I'm most of the way through the process outlined in this thread by Macbeth but am getting a verification error a good bit of the way through flashing "DM3058_block0" to the DMM (occurring at address 0x2005EDCE of 0x200FFFFF):

Code: [Select]

jtag> cable probe
Found USB cable: UsbBlaster
Connected to libftdi driver.
jtag> frequency 12000000
Setting TCK frequency to 12000000 Hz
jtag> detect
IR length: 5
Chain length: 1
Device ID: 01100010011110100101000011001011 (0x627A50CB)
  Manufacturer: Analog Devices, Inc. (0x0CB)
  Part(0):          BF533 (0x27A5)
  Stepping:        6
  Filename:        ./../share/urjtag/analog/bf533/bf533
warning: UsbBlaster: untested cable, set wait_clocks to 30
jtag> initbus bf533_stamp
jtag> detectflash 0x20000000
Query identification string:
............
............
............
jtag> endian little
jtag> flashmem 0x20000000 /home/jeff/DM3058/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

...........
...........

block 21 unlocked
flash_erase_block 0x200E0000
flash_erase_block 0x200E0000 DONE
erasing block 21: 0
flash_unlock_block 0x200F0000 IGNORE

block 22 unlocked
flash_erase_block 0x200F0000
flash_erase_block 0x200F0000 DONE
erasing block 22: 0
addr: 0x200FFFFE
verify:
error: flash program: addr: 0x2005EDCE
  verify error:
read: 0x0000EEDB
expected: 0x0000B012

jtag>

I get a similar verification error for "DM3058_block1", but right off the bat at address 0x20100000:

Code: [Select]

........................................
.....similar to code above.....
........................................

block 35 unlocked
flash_erase_block 0x201C0000
flash_erase_block 0x201C0000 DONE
erasing block 35: 0
flash_unlock_block 0x201D0000 IGNORE

block 36 unlocked
flash_erase_block 0x201D0000
flash_erase_block 0x201D0000 DONE
erasing block 36: 0
addr: 0x201DFFFE
verify:
error: flash program: addr: 0x20100000
  verify error:
read: 0x0000FFFF
expected: 0x000089B9

jtag>

Any help would be greatly appreciated.

Thanks,
Jeff

jraut · « **Reply #58 on:** December 07, 2018, 03:34:35 pm »

I got it working!! Wahoo!!!

Went from a fully-dickered, bricked unit to a fully working unit using the procedures outlined by Macbeth. Thanks!

For anyone who runs across this in the future, I have a couple thoughts:

1. I used a knock-off Altera USB Blaster from Amazon (~$10 delivered), which requires the "two-resistor" setup in Macbeth's sketch. Note that all pins on the ribbon cable need to be connected, including SRST and TRST, which wasn't immediately obvious to me when I was looking at the diagram.
2. I dumped the flash memory back to new "backup1_block0/1" files after writing the new firmware.
3. Even though I got the error during the verification of "_block0", the DM3058_block0 file was identical to the new backup file. So I'm guessing there was just a hiccup during transmission in the verification stage.
4. I was having a lot of trouble writing the _block1 file to the device. My path to the solution was pretty nonlinear, but I believe what finally ended up working for _block1 was the following code:
cable probe
frequency 12000000
detect
initbus bf533_ezkit // bf533_stamp worked for the _block0 code segment, but I was having trouble with it for _block1
detectflash 0x20000000 // Use 0x20000000 even though we're writing to 0x20100000
endian little
flashmem 0x20100000 /home/<username>/DM3058/DM3058_block1
instr bypass
shift ir
quit

jraut · « **Reply #59 on:** December 07, 2018, 06:02:37 pm »

Posting the Serial and Calibration backup files from my DM3058 (before flashing the new firmware) for posterity or curious eyes.

The "backup_0x20000000_block0" and "backup_0x20100000_block1" aren't really worth posting because they're garbage anyway.

See attachments. Note I added a .TXT extension so that EEVBlog would allow me to attach.

Jeff

Macbeth · « **Reply #60 on:** December 09, 2018, 12:32:32 am »

I'm glad this stuff worked for someone else anyway! I suspect the reason it worked is because you managed to flash the exact same firmware version that had the protected block. I went through this with ralph last year. Sadly he didn't verify the complete JTAG dump before proceeding with the JTAG flash with a new version. I can't blame him. Worst case just go and ask Rigol to provide a copy of the old firmware, right??? WRONG!

jraut · « **Reply #61 on:** December 09, 2018, 03:00:12 am »

Quote from: Macbeth on December 09, 2018, 12:32:32 am

I'm glad this stuff worked for someone else anyway! I suspect the reason it worked is because you managed to flash the exact same firmware version that had the protected block. I went through this with ralph last year. Sadly he didn't verify the complete JTAG dump before proceeding with the JTAG flash with a new version. I can't blame him. Worst case just go and ask Rigol to provide a copy of the old firmware, right??? WRONG!

The chap who bricked it managed to get partway through the upgrade before it crapped out on him for whatever reason (I suspect he got antsy and flipped the power switch while it was in progress, but who knows).

I suspect this because my backup "block0" file matched the latest firmware exactly for the first ~30% of the file, then was all 0xFF. The "block1" backup was all 0xFF. So seems to me that upgrading the firmware via USB first overwrites the flash memory with 0xFF, then puts on the new firmware from front to back.

For what it's worth, I did talk to a tech guy over at Rigol who was very helpful. He had, on his hard drive, Version 02.02 (the current one) and Version 02.03 or 3.03 or something (!!!!! seems to me a new firmware version is in the works). He wasn't willing to give me that one, for obvious reasons. The guy didn't have a copy of the old version at hand, but put in a ticket and was working on getting it for me. I called him off once I got it working.

greenwk2 · « **Reply #62 on:** September 14, 2020, 01:53:02 am »

I know this thread is a bit old but I found it useful in the past few weeks.

I bricked my DM3058 when the upgrade from 02.02 to 02.03.01 failed. I think it failed due to a flakey thumb drive but it's not clear.

I was able to use the procedure above to re-flash the 02.03.01 firmware via JTAG.

I initially tried using a clone Altera USB Blaster from Amazon but that didn't work. I was able to detect the BF533 but I was not able to detect the flash.

I purchased the Olimex adapter from Spark Fun and it didn't work initially either with the same problem but when I changed the frequency to 5000000 it worked fine.

I was surprised, but I didn't have any verification issues at all. I followed MacBeth's steps in Post 47 and it worked fine.

I was happy to be able to un-brick my meter.

Macbeth · « **Reply #63 on:** September 14, 2020, 02:27:27 am »

It's great to see success stories like this!

> I bricked my DM3058 when the upgrade from 02.02 to 02.03.01 failed. I think it failed due to a flakey thumb drive but it's not clear.

After quite a few upgrades and downgrades and JTAG recoveries I have found the problems are caused when trying to flash upgrade using the soft power button off/on procedure.
Switching the meter off and on from the mains properly and then doing a USB firmware upgrade works fine for me so far.

It doesn't matter how many times I have reported this to Rigol, they have completely stonewalled me.

Zack · « **Reply #64 on:** September 16, 2020, 10:45:01 pm »

Glad to see some new DM3058 postings.

The Release Notes for the DM3058 firmware 02.03.01 require re-calibration of capacitance. I do not have access to the expensive equipment to re-calibration. Does anyone know if 02.03.01 is still advisable without re-calibration? Will it overwrite the existing capacitance calibration tables or can one downgrade from 02.03.01 back to 02.02?


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Rigol DM3058/DM3068 firmware updates available for request online - finally! (Read 22615 times)

Share me