Rigol DM3058/DM3068 firmware updates available for request online - finally!

[ralphrmartin]

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]

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]

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]

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

[Macbeth]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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?