Rigol DM3058/DM3068 firmware updates available for request online - finally! - Page 1
Forum section: electronics / testgear

author: Macbeth
author_rank: Super Contributor
timestamp: March 24, 2015, 11:38:47 pm
content: I just noticed that Rigol have updated thefirmware request formto 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 descriptionAlso noticed a newDM3058 Calibration Guidedated 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)

author: Macbeth
author_rank: Super Contributor
timestamp: March 25, 2015, 12:08:51 am
content: Reading the calibration guide, Rigol recommend using a Fluke 5520A. It has been discontinued and even used ones are a little pricey, butthis ebay sellerhas 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...

author: xrunner
author_rank: Super Contributor
timestamp: March 25, 2015, 12:35:00 am
content: Thanks for posting that, I have a DM3058E and I'll be requesting the firmware.

author: wraper
author_rank: Unknown
timestamp: March 25, 2015, 12:56:16 am
content: 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=spuZipILEhttp://beyondmeasure.rigoltech.com/acton/ct/1579/s-0598-1501/Bct/l-3f49/l-3f49:b33/ct4_0/1?sid=spuZipILE

author: 2Bad4u
author_rank: Newbie
timestamp: March 25, 2015, 02:51:58 am
content: Quote from: wraper on March 25, 2015, 12:56:16 amI 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.

author: Macbeth
author_rank: Super Contributor
timestamp: March 25, 2015, 03:06:11 pm
content: 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.00Utility>T/C>Info shows Version: 01.01.00.02.02.00Continuity 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.

author: thn788
author_rank: Contributor
timestamp: March 25, 2015, 03:51:23 pm
content: 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 versionHold 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).

author: KedasProbe
author_rank: Frequent Contributor
timestamp: March 25, 2015, 03:54:27 pm
content: 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)

author: xrunner
author_rank: Super Contributor
timestamp: March 25, 2015, 05:03:32 pm
content: 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 was02.01.00and it is now02.02.00

author: lho
author_rank: Newbie
timestamp: March 26, 2015, 02:20:08 pm
content: Hi,And what about any calibration loose on the DM3068 ?Lho

author: wraper
author_rank: Unknown
timestamp: March 26, 2015, 02:26:22 pm
content: Quote from: lho on March 26, 2015, 02:20:08 pmWhy should it be lost?

author: KedasProbe
author_rank: Frequent Contributor
timestamp: March 26, 2015, 02:28:05 pm
content: Quote from: lho on March 26, 2015, 02:20:08 pmThere 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)

author: Macbeth
author_rank: Super Contributor
timestamp: March 26, 2015, 02:46:25 pm
content: 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 stockYou can only change the user calibration with a password. The firmware upgrade does not affect the calibration.

author: lho
author_rank: Newbie
timestamp: March 26, 2015, 08:30:41 pm
content: Quote from: wraper on March 26, 2015, 02:26:22 pmI was thinking about non-volatile memory change...

author: mcinque
author_rank: Unknown
timestamp: March 27, 2015, 12:40:23 pm
content: Interesting, anyone has a changelog for the 3058 update?

author: mrkva
author_rank: Unknown
timestamp: September 17, 2015, 10:18:48 pm
content: Bump for the changelog!

author: Dwaine
author_rank: Frequent Contributor
timestamp: June 28, 2016, 11:55:48 pm
content: 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?

author: Macbeth
author_rank: Super Contributor
timestamp: June 29, 2016, 12:57:29 am
content: Quote from: Dwaine on June 28, 2016, 11:55:48 pmReally? Their website still listsCode: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?

author: Dwaine
author_rank: Frequent Contributor
timestamp: June 29, 2016, 08:13:05 am
content: 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.

author: cidak
author_rank: Unknown
timestamp: August 29, 2016, 08:38:07 pm
content: Quote from: Dwaine on June 29, 2016, 08:13:05 amI would be very grateful if you, or someone else, can send privately or post here, the firmware in question.Thank you.

author: TurboTom
author_rank: Super Contributor
timestamp: August 29, 2016, 09:10:06 pm
content: Quote from: cidak on August 29, 2016, 08:38:07 pm+1... I'ld also be interested in the update file!Thanks,Thomas

author: Rbastler
author_rank: Frequent Contributor
timestamp: August 30, 2016, 05:46:32 am
content: 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.

author: Dwaine
author_rank: Frequent Contributor
timestamp: August 30, 2016, 06:21:21 am
content: Here is the firmware:http://beyondmeasure.rigoltech.com/acton/ct/1579/s-0744-1511/Bct/l-3f49/l-3f49:1cac/ct3_0/1?sid=QJ41gTN30Here 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

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2016, 08:00:13 am
content: Quote from: Rbastler on August 30, 2016, 05:46:32 amSave a bit more and go for a Keysight 6.5 digit DMM! The price difference is too small to settle for second best.

author: 2N3055
author_rank: Super Contributor
timestamp: August 30, 2016, 12:20:21 pm
content: Quote from: nctnico on August 30, 2016, 08:00:13 amWhile 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

author: EEVblog
author_rank: Unknown
timestamp: August 30, 2016, 12:41:35 pm
content: You still have to request firmware?

author: H.O
author_rank: Frequent Contributor
timestamp: August 30, 2016, 12:54:02 pm
content: 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

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2016, 02:38:13 pm
content: Quote from: 2N3055 on August 30, 2016, 12:20:21 pmWhy would you want the GPIB option? The 34461A has USB and LAN as standard which are much easier interfaces to work with.

author: 2N3055
author_rank: Super Contributor
timestamp: August 30, 2016, 02:44:57 pm
content: Quote from: nctnico on August 30, 2016, 02:38:13 pmYou are right, I don't need GPIB, just trying to compare them on equal terms..

author: Rbastler
author_rank: Frequent Contributor
timestamp: August 30, 2016, 03:42:18 pm
content: Quote from: Dwaine on August 30, 2016, 06:21:21 amThanks 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 30, 2016, 03:56:25 pm
content: 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.

author: TheSteve
author_rank: Unknown
timestamp: August 30, 2016, 04:40:12 pm
content: 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.

author: Dwaine
author_rank: Frequent Contributor
timestamp: August 30, 2016, 05:38:29 pm
content: 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.

author: 2N3055
author_rank: Super Contributor
timestamp: August 30, 2016, 09:05:32 pm
content: Quote from: Dwaine on August 30, 2016, 05:38:29 pmThis 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 ..

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 10, 2017, 01:02:09 pm
content: 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.

author: Macbeth
author_rank: Super Contributor
timestamp: December 10, 2017, 09:21:40 pm
content: Quote from: ralphrmartin on December 10, 2017, 01:02:09 pmIt 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 11, 2017, 01:15:04 pm
content: 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 athttps://beyondmeasure.rigoltech.com/acton/formfd/1579/0025:d-000dit 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.

author: Macbeth
author_rank: Super Contributor
timestamp: December 11, 2017, 03:15:44 pm
content: Quote from: ralphrmartin on December 11, 2017, 01:15:04 pmThat appears to be a very old firmware, my earliest is 01.01.00.02.01.00.01 and dates back to 08/2012.QuoteHave 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.

author: H.O
author_rank: Frequent Contributor
timestamp: December 11, 2017, 07:33:05 pm
content: 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 11, 2017, 11:49:54 pm
content: Quote from: Macbeth on December 11, 2017, 03:15:44 pmThat'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.

author: smithnerd
author_rank: Regular Contributor
timestamp: December 12, 2017, 12:09:53 am
content: 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 17, 2017, 08:35:27 pm
content: Quote from: ralphrmartin on December 11, 2017, 11:49:54 pmI 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.

author: Macbeth
author_rank: Super Contributor
timestamp: December 17, 2017, 09:28:52 pm
content: Quote from: ralphrmartin on December 17, 2017, 08:35:27 pmPossibly 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?

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 18, 2017, 01:35:44 pm
content: 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?

author: Macbeth
author_rank: Super Contributor
timestamp: December 18, 2017, 08:35:45 pm
content: 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:installingYou can test it's working by running thebfin-jtagcommand andcable probewhich 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 thedetectcommand in bfin-jtag after thecable probeto 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!

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 19, 2017, 10:38:09 am
content: Set it all up, and as long as I run it as root, it looks good:jtag> cable probeFound USB cable: UsbBlasterConnected 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.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 19, 2017, 11:58:36 am
content: Wired it all up, and seems good so far:IR length: 5Chain length: 1Device Id: 01100010011110100101000011001011 (0x627A50CB)Manufacturer: Analog Devices, Inc. (0x0CB)Part(0): BF533 (0x27A5)Stepping: 6Filename: /opt/uClinux/bfin-uclinux/bin/../share/urjtag/analog/bf533/bf533warning: UsbBlaster: untested cable, set wait_clocks to 30Standing by for further instructions...

author: Macbeth
author_rank: Super Contributor
timestamp: December 19, 2017, 02:37:42 pm
content: Looking good. Ok, the DM3058 has 4MB flash memory at 0x20000000 and the layout is:0x000000 - 0x1dffff : Firmware0x1e0000 - 0x1e00ff : Serial No, Version, CAL ID0x1f0000 - 0x1f0dff : Calibration data?0x200000 - 0x3fffff : Unused flashYou will want to make a full backup before flashing. Make a dm3058 folder in your home dir. Runbfin-jtagand...cable probefrequency 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.detectinitbus bf533_stamp// or bf533_ezkit or bf53xdetectflash 0x20000000endian littlereadmem 0x20000000 0xfffff /home/user/dm3058/backup_0x20000000_block0readmem 0x20100000 0xdffff /home/user/dm3058/backup_0x20100000_block1readmem 0x201e0000 0x0ffff /home/user/dm3058/backup_0x201e0000_serialreadmem 0x201f0000 0x0ffff /home/user/dm3058/backup_0x201f0000_calibrationinstr bypassshift irquitYou 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 RigolDM3058_System.ldrneeds 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! Socd /home/user/dm3058dd if=DM3058_System.ldr of=DM3058_block0 skip=49 count=1048576 iflag=skip_bytes,count_bytesdd if=DM3058_System.ldr of=DM3058_block1 skip=1048625 count=917504 iflag=skip_bytes,count_bytesand to flash it run bfin-jtag and...cable probefrequency 6000000// replace with your highest speeddetectinitbus bf533_stampdetectflash 0x20000000endian littleflashmem 0x20000000 /home/user/dm3058/DM3058_block0flashmem 0x20100000 /home/user/dm3058/DM3058_block1instr bypassshift irquitAfter 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

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 20, 2017, 08:06:23 am
content: 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 0x20000000Query 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 mVVcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mVVpp  Supply Minimum Write/Erase voltage: 0 mVVpp  Supply Maximum Write/Erase voltage: 0 mVTypical timeout per single byte/word program: 128 usTypical timeout for maximum-size multi-byte program: 128 usTypical timeout per individual block erase: 1024 msTypical timeout for full chip erase: 0 msMaximum timeout for byte/word program: 1024 usMaximum timeout for multi-byte program: 4096 usMaximum timeout per individual block erase: 16384 msMaximum timeout for chip erase: 0 msDevice 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: 32Number of Erase Block Regions within device: 2Erase Block Region Information:Region 0:Erase Block Size: 8192 B (8 KiB)Number of Erase Blocks: 8Region 1:Erase Block Size: 65536 B (64 KiB)Number of Erase Blocks: 63Primary Vendor-Specific Extended Query:Major version number: 1Minor version number: 3Address Sensitive Unlock: RequiredProcess Technology: Bad valueErase Suspend: Read/writeSector Protect: 1 sectors per groupSector Temporary Unprotect: SupportedSector Protect/Unprotect Scheme: Bad valueSimultaneous Operation: Not supportedBurst Mode Type: SupportedPage Mode Type: 8 word PageACC (Acceleration) Supply Minimum: 11500 mVACC (Acceleration) Supply Maximum: 12500 mVTop/Bottom Sector Flag: Bottom boot deviceProgram Suspend: Not supportedjtag> endian littlejtag> flashmem 0x20000000 DM3058_block0Chip: AMD FlashManufacturer: AMDChip: S92GLxxxNProtected: 0001program:flash_unlock_block 0x20000000 IGNOREblock 0 unlockedflash_erase_block 0x20000000flash_erase_block 0x20000000 DONEerasing block 0: 0flash_unlock_block 0x20002000 IGNORE... lots more like thisblock 22 unlockedflash_erase_block 0x200F0000flash_erase_block 0x200F0000 DONEerasing block 22: 0addr: 0x200FFFFEverify:error: flash program: addr: 0x200000D8verify error:read: 0x0000D822expected: 0x0000FA62I 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.

author: Macbeth
author_rank: Super Contributor
timestamp: December 20, 2017, 01:42:32 pm
content: Hmm... Have you tried usinginitbus bf533_ezkitinstead 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 yourbackup_0x201e0000_serialand then patch in the new version number and flash that to 201e0000. But thats for later.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 20, 2017, 02:48:03 pm
content: Yes, triedinitbus bf533_ezkitwith 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?

author: Macbeth
author_rank: Super Contributor
timestamp: December 20, 2017, 03:58:37 pm
content: 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 zeroesdd if=/dev/zero ibs=1k count=64 of=test.binI chose a few "safe" locations 0x201d0000, 0x20220000, 0x20310000. I couldreadmem 0x201d0000 0xffff /home/mac/dm3058/0x201d0000.bakand thenflashmem 0x201d0000 /home/mac/dm3058/test.binand 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?

author: Macbeth
author_rank: Super Contributor
timestamp: December 20, 2017, 06:16:56 pm
content: 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:UrJTAG 0.10 #Copyright (C) 2002, 2003 ETC s.r.o.Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authorsUrJTAG is free software, covered by the GNU General Public License, and you arewelcome 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 probeFound USB cable: ARM-USB-OCDConnected to libftdi driver.jtag> detectIR length: 5Chain length: 1Device Id: 01100010011110100101000011001011 (0x627A50CB)Manufacturer: Analog Devices, Inc. (0x0CB)Part(0): BF533 (0x27A5)Stepping: 6Filename: /opt/uClinux/bfin-uclinux/bin/../share/urjtag/analog/bf533/bf533warning: ARM-USB-OCD: untested cable, set wait_clocks to 30jtag> initbus bf533_ezkitjtag> detectflash 0x20000000Query 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 mVVcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mVVpp  Supply Minimum Write/Erase voltage: 0 mVVpp  Supply Maximum Write/Erase voltage: 0 mVTypical timeout per single byte/word program: 128 usTypical timeout for maximum-size multi-byte program: 128 usTypical timeout per individual block erase: 1024 msTypical timeout for full chip erase: 0 msMaximum timeout for byte/word program: 1024 usMaximum timeout for multi-byte program: 4096 usMaximum timeout per individual block erase: 16384 msMaximum timeout for chip erase: 0 msDevice 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: 32Number of Erase Block Regions within device: 2Erase Block Region Information:Region 0:Erase Block Size: 8192 B (8 KiB)Number of Erase Blocks: 8Region 1:Erase Block Size: 65536 B (64 KiB)Number of Erase Blocks: 63Primary Vendor-Specific Extended Query:Major version number: 1Minor version number: 3Address Sensitive Unlock: RequiredProcess Technology: Bad valueErase Suspend: Read/writeSector Protect: 1 sectors per groupSector Temporary Unprotect: SupportedSector Protect/Unprotect Scheme: Bad valueSimultaneous Operation: Not supportedBurst Mode Type: SupportedPage Mode Type: 8 word PageACC (Acceleration) Supply Minimum: 11500 mVACC (Acceleration) Supply Maximum: 12500 mVTop/Bottom Sector Flag: Bottom boot deviceProgram Suspend: Not supportedjtag> endian littlejtag> readmem 0x20000000 0xfffff /home/user/dm3058/backup_0x20000000_block0address: 0x20000000length: 0x00100000reading:addr: 0x20100000Done.jtag> readmem 0x20100000 0xdffff /home/user/dm3058/backup_0x20100000_block1address: 0x20100000length: 0x000E0000reading:addr: 0x201E0000Done.jtag> readmem 0x201e0000 0x0ffff /home/user/dm3058/backup_0x201e0000_serialaddress: 0x201E0000length: 0x00010000reading:addr: 0x201F0000Done.jtag> readmem 0x201f0000 0x0ffff /home/u/dm3058/backup_0x201f0000_calibrationaddress: 0x201F0000length: 0x00010000reading:addr: 0x20200000Done.jtag> instr bypassjtag> shift irjtag> quitOk, 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 ofbackup_0x201e0000_serialand 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:UrJTAG 0.10 #Copyright (C) 2002, 2003 ETC s.r.o.Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authorsUrJTAG is free software, covered by the GNU General Public License, and you arewelcome 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 probeFound USB cable: ARM-USB-OCDConnected to libftdi driver.jtag> frequency 6000000Setting TCK frequency to 6000000 Hzjtag> detectIR length: 5Chain length: 1Device Id: 01100010011110100101000011001011 (0x627A50CB)Manufacturer: Analog Devices, Inc. (0x0CB)Part(0): BF533 (0x27A5)Stepping: 6Filename: /opt/uClinux/bfin-uclinux/bin/../share/urjtag/analog/bf533/bf533warning: ARM-USB-OCD: untested cable, set wait_clocks to 30jtag> initbus bf533_ezkitjtag> detectflash 0x20000000Query 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 mVVcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mVVpp  Supply Minimum Write/Erase voltage: 0 mVVpp  Supply Maximum Write/Erase voltage: 0 mVTypical timeout per single byte/word program: 128 usTypical timeout for maximum-size multi-byte program: 128 usTypical timeout per individual block erase: 1024 msTypical timeout for full chip erase: 0 msMaximum timeout for byte/word program: 1024 usMaximum timeout for multi-byte program: 4096 usMaximum timeout per individual block erase: 16384 msMaximum timeout for chip erase: 0 msDevice 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: 32Number of Erase Block Regions within device: 2Erase Block Region Information:Region 0:Erase Block Size: 8192 B (8 KiB)Number of Erase Blocks: 8Region 1:Erase Block Size: 65536 B (64 KiB)Number of Erase Blocks: 63Primary Vendor-Specific Extended Query:Major version number: 1Minor version number: 3Address Sensitive Unlock: RequiredProcess Technology: Bad valueErase Suspend: Read/writeSector Protect: 1 sectors per groupSector Temporary Unprotect: SupportedSector Protect/Unprotect Scheme: Bad valueSimultaneous Operation: Not supportedBurst Mode Type: SupportedPage Mode Type: 8 word PageACC (Acceleration) Supply Minimum: 11500 mVACC (Acceleration) Supply Maximum: 12500 mVTop/Bottom Sector Flag: Bottom boot deviceProgram Suspend: Not supportedjtag> endian littlejtag> flashmem 0x201e0000 /home/andy/dm3058/0x201e0000_serialChip: AMD FlashManufacturer: AMDChip: S92GLxxxNProtected: 0001program:flash_unlock_block 0x201E0000 IGNOREblock 37 unlockedflash_erase_block 0x201E0000flash_erase_block 0x201E0000 DONEerasing block 37: 0addr: 0x201EFFFEverify:addr: 0x201EFFFEDone.jtag> instr bypassjtag> shift irjtag> quitAppears 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...

author: bson
author_rank: Unknown
timestamp: December 20, 2017, 06:21:33 pm
content: flash erase_address and flash write_image both have an optional parameter to unlock the protection.

author: Macbeth
author_rank: Super Contributor
timestamp: December 20, 2017, 07:48:18 pm
content: Quote from: bson on December 20, 2017, 06:21:33 pmThank 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_bytesCode:jtag> help unlockflashUsage: unlockflash ADDR BLOCKSUnlock flash memory from ADDR.ADDR target address for erasing blockBLOCKS number of blocks to lockADDR 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 BitAMD/Fujitsu Standard Command Set supported: AMD 29LV800B, S29GLxxxN; MX29LV640B, W19B320AT/B; 1x16 BitAMD/Fujitsu Standard Command Set supported: AMD 29LV160, AMD 29LV065D, AMD 29LV040B, S29GLxxxN, W19B320AT/B; 1x8 BitIntel Standard Command Set supported: 28Fxxxx, 2 x 16 bitIntel Standard Command Set supported: 28Fxxxx, 1 x 16 bitIntel Standard Command Set supported: 28Fxxxx, 1 x 8 bitAMD Standard Command Set supported: AMD 29LV040B, 29C040B, 1x8 Bitjtag>jtag> unlockflash 0x20000000 2Chip: AMD FlashManufacturer: AMDChip: S92GLxxxNProtected: 0001Unlocking 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/testChip: AMD FlashManufacturer: AMDChip: S92GLxxxNProtected: 0001program:flash_unlock_block 0x20000000 IGNOREblock 0 unlockedflash_erase_block 0x20000000flash_erase_block 0x20000000 DONEerasing block 0: 0flash_unlock_block 0x20002000 IGNOREblock 1 unlockedflash_erase_block 0x20002000flash_erase_block 0x20002000 DONEerasing block 1: 0addr: 0x20003FFEverify:error: flash program: addr: 0x200000D8verify error:read: 0x0000F9A0expected: 0x0000FA62jtag>I dunno why the IGNORE thing comes up

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: December 21, 2017, 03:34:32 pm
content: As noted,unlockflash 0x20000000 2says 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.

author: Chris56000
author_rank: Frequent Contributor
timestamp: January 06, 2018, 11:29:20 pm
content: 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

author: jraut
author_rank: Newbie
timestamp: December 07, 2018, 04:13:57 am
content: Quote from: ralphrmartin on December 21, 2017, 03:34:32 pmSorry 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:jtag> cable probeFound USB cable: UsbBlasterConnected to libftdi driver.jtag> frequency 12000000Setting TCK frequency to 12000000 Hzjtag> detectIR length: 5Chain length: 1Device ID: 01100010011110100101000011001011 (0x627A50CB)Manufacturer: Analog Devices, Inc. (0x0CB)Part(0): BF533 (0x27A5)Stepping: 6Filename: ./../share/urjtag/analog/bf533/bf533warning: UsbBlaster: untested cable, set wait_clocks to 30jtag> initbus bf533_stampjtag> detectflash 0x20000000Query identification string:....................................jtag> endian littlejtag> flashmem 0x20000000 /home/jeff/DM3058/DM3058_block0Chip: AMD FlashManufacturer: AMDChip: S92GLxxxNProtected: 0001program:flash_unlock_block 0x20000000 IGNOREblock 0 unlockedflash_erase_block 0x20000000flash_erase_block 0x20000000 DONEerasing block 0: 0flash_unlock_block 0x20002000 IGNORE......................block 21 unlockedflash_erase_block 0x200E0000flash_erase_block 0x200E0000 DONEerasing block 21: 0flash_unlock_block 0x200F0000 IGNOREblock 22 unlockedflash_erase_block 0x200F0000flash_erase_block 0x200F0000 DONEerasing block 22: 0addr: 0x200FFFFEverify:error: flash program: addr: 0x2005EDCEverify error:read: 0x0000EEDBexpected: 0x0000B012jtag>I get a similar verification error for "DM3058_block1", but right off the bat at address 0x20100000:Code:.............................................similar to code above.............................................block 35 unlockedflash_erase_block 0x201C0000flash_erase_block 0x201C0000 DONEerasing block 35: 0flash_unlock_block 0x201D0000 IGNOREblock 36 unlockedflash_erase_block 0x201D0000flash_erase_block 0x201D0000 DONEerasing block 36: 0addr: 0x201DFFFEverify:error: flash program: addr: 0x20100000verify error:read: 0x0000FFFFexpected: 0x000089B9jtag>Any help would be greatly appreciated.Thanks,Jeff

author: jraut
author_rank: Newbie
timestamp: December 07, 2018, 03:34:35 pm
content: 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 probefrequency 12000000detectinitbus bf533_ezkit// bf533_stamp worked for the _block0 code segment, but I was having trouble with it for _block1detectflash 0x20000000// Use 0x20000000 even though we're writing to 0x20100000endian littleflashmem 0x20100000 /home/<username>/DM3058/DM3058_block1instr bypassshift irquit

author: jraut
author_rank: Newbie
timestamp: December 07, 2018, 06:02:37 pm
content: 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

author: Macbeth
author_rank: Super Contributor
timestamp: December 09, 2018, 12:32:32 am
content: 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!

author: jraut
author_rank: Newbie
timestamp: December 09, 2018, 03:00:12 am
content: Quote from: Macbeth on December 09, 2018, 12:32:32 amThe 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 firmwareexactlyfor 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.

author: greenwk2
author_rank: Newbie
timestamp: September 14, 2020, 01:53:02 am
content: 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.

author: Macbeth
author_rank: Super Contributor
timestamp: September 14, 2020, 02:27:27 am
content: 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.

author: Zack
author_rank: Newbie
timestamp: September 16, 2020, 10:45:01 pm
content: 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?