This item documents a failed attempt to perform a firmware upgrade on a Rigol DM3058.
By the book
The process attempted to upgrade the firmware from v2.02 to v2.03 using the method described by Rigol and upgrade file from their official website.
There were not power interruptions during the upgrade which hung and was shut down after an hour. I might add that I had just upgraded two other DM3058s using the same method, same USB stick.
Email was sent to Rigol Support for help, none came. No surprises there, Rigol are a Chinese company.
I have later found comments that the upgrade may fail if Rigol UltraSensor has been used on the instrument. Others comment on difficulties working with some USB sticks.
The firware is loaded into a flash (external) memory chip attached to a ADSP-BF531 processor chip.
Above, the 4MB flash memory chip branded Spansion, later to become Cypress, then Infineon.
Attempted recovery
The main board has a set of JTAG pins (though non-standard layout), so an attempt was made to recover the device using a suitable JTAG probe and software.
Very little free software supports the BF531 (BF533), Urjtag was a candidate that also supported a range of JTAG probes.
For first attempt, a cheap Chines clone of the USBBlaster was tried. It did not use a genuine FTDI chip and was not recognised by Quartus Programmer, openocd, or Urjtag. The eBay purchase price was refunded.
Next, a Olimex ARM-USB-TINY-H was tried.
Above the JTAG interface on the DM3058.
… and the Vref connection.
Above is the ARM-USB-TINY-H cable interconnection.
Above, a table of the interconnect.
Many attempts were made to ‘connect’ to the flash memory.
jtag> cable probe
Found USB cable: ARM-USB-TINY-H
Connected to libftdi driver.
jtag> frequency 1000000
Setting TCK frequency to 1000000 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: /usr/local/share/urjtag/analog/bf533/bf533
warning: ARM-USB-TINY-H: untested cable, set wait_clocks to 30
jtag> initbus bf533_ezkit
jtag> detectflash
Usage: detectflash ADDRESS
Detect flash memory type connected to a part.
ADDRESS Base address for memory region
error: syntax: detectflash: #parameters should be 2, not 1
jtag> detectflash 0x20000000
dev ID=ff80 man ID=0060
urj_flash_amd_detect: mid 60, did 60
=== experimental extensive JEDEC brute-force autodetection ===
- trying with cpu buswidth 16
-- trying with flash datawidth 16
--- trying with flash dataoffset 0 (using FFFF00AA, FFFF0055 and FFFF0090)
trying with address pattern base 00005555: 00000060 00000060 0000ff80
trying with address pattern base 00000555: 00000060 00000060 0000ff80
trying with address pattern base 0000aaaa: 00000060 0000ff80 00000004
trying with address pattern base 00000aaa: 00000060 0000ff80 00000004
trying with address pattern base 00015554: 00000060 00000004 00000010
trying with address pattern base 00001554: 00000060 00000004 00000010
-- trying with flash datawidth 8
--- trying with flash dataoffset 0 (using FFFFFFAA, FFFFFF55 and FFFFFF90)
trying with address pattern base 00005555: 00000060 00000060 00000080
trying with address pattern base 00000555: 00000060 00000060 00000080
trying with address pattern base 0000aaaa: 00000060 00000080 00000004
trying with address pattern base 00000aaa: 00000060 00000080 00000004
trying with address pattern base 00015554: 00000060 00000004 00000010
trying with address pattern base 00001554: 00000060 00000004 00000010
--- trying with flash dataoffset 8 (using FFFFAAFF, FFFF55FF and FFFF90FF)
trying with address pattern base 00005555: 00000000 00000000 000000ff
trying with address pattern base 00000555: 00000000 00000000 000000ff
trying with address pattern base 0000aaaa: 00000000 000000ff 00000000
trying with address pattern base 00000aaa: 00000000 000000ff 00000000
trying with address pattern base 00015554: 00000000 00000000 00000000
trying with address pattern base 00001554: 00000000 00000000 00000000
- trying with cpu buswidth 8
-- trying with flash datawidth 8
--- trying with flash dataoffset 0 (using FFFFFFAA, FFFFFF55 and FFFFFF90)
trying with address pattern base 00005555: 00000060 00000060 00000080
trying with address pattern base 00000555: 00000060 00000060 00000080
trying with address pattern base 0000aaaa: 00000060 00000080 00000004
trying with address pattern base 00000aaa: 00000060 00000080 00000004
trying with address pattern base 00015554: 00000060 00000004 00000010
trying with address pattern base 00001554: 00000060 00000004 00000010
=== end of experimental extensive JEDEC brute-force autodetection ===
Query identification string:
Primary Algorithm Command Set and Control Interface ID Code: 0x0000 (null)
Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null)
Query system interface information:
Vcc Logic Supply Minimum Write/Erase or Write voltage: 0 mV
Vcc Logic Supply Maximum Write/Erase or Write voltage: 0 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: 0 us
Typical timeout for maximum-size multi-byte program: 0 us
Typical timeout per individual block erase: 0 ms
Typical timeout for full chip erase: 0 ms
Maximum timeout for byte/word program: 0 us
Maximum timeout for multi-byte program: 0 us
Maximum timeout per individual block erase: 0 ms
Maximum timeout for chip erase: 0 ms
Device geometry definition:
Device Size: 0 B (0 KiB, 0 MiB)
Flash Device Interface Code description: 0x0000 (x8)
Maximum number of bytes in multi-byte program: 0
Number of Erase Block Regions within device: 0
Erase Block Region Information:
jtag>
Above is a log of the session. (initbus bf533_stamp was also tried.)
Though the detectflash command failed, it was possible to read the flash.
There are four memory address ranges of interest, they were dumped to files successfully.
jtag> jtag> frequency 6000000 Setting TCK frequency to 6000000 Hz jtag> readmem 0x20000000 0xfffff blk0.bin readmem 0x20100000 0xdffff blk1.bin readmem 0x201e0000 0x0ffff serial.bin readmem 0x201f0000 0x0ffff cal.bin address: 0x20000000 length: 0x00100000 reading: addr: 0x20100000 Done. jtag> address: 0x20100000 length: 0x000E0000 reading: addr: 0x201E0000 Done. jtag> address: 0x201E0000 length: 0x00010000 reading: addr: 0x201F0000 Done. jtag> address: 0x201F0000 length: 0x00010000 reading: addr: 0x20200000 Done. jtag>
There are two main banks of memory of interest, blk0 and blk1.
A binary comparison found that blk1 was identical to v2.20 block 1, so it was unchanged in the failed upgrade process.
Block 0 was compared to v2.20 block 0.
203-0.bin blk0.bin differ: byte 630153, line 7726
That offset is 0x99d89.
00099D08 0B 64 BB E6 │ F7 FF E1 2F │ B8 E4 F7 FF │ 88 0C 13 10 │ BA E4 F7 FF │ 12 4F 0A E1 .d...../.............O.. 00099D20 50 E0 4A E1 │ 2C 00 11 A0 │ 0A 32 0F 5A │ 01 E6 FB FF │ BB E4 F7 FF │ 0B 64 BB E6 P.J.,....2.Z.........d.. 00099D38 F7 FF EB 2F │ B0 B9 FF E3 │ 0D 8B F0 BB │ 00 0C 08 18 │ 03 E1 00 00 │ 43 E1 0B 00 .../................C... 00099D50 03 50 F0 BB │ 05 20 FB E3 │ 3E B3 F0 B9 │ 01 20 78 AC │ 01 E8 00 00 │ 50 00 00 E8 .P... ..>.... x.....P... 00099D68 08 00 B8 B0 │ 03 60 E3 BB │ BB E6 F7 FF │ 02 60 F2 BB │ 00 0C 03 10 │ 08 60 54 20 .....`㻻 ....`.......`T 00099D80 B8 A0 C0 BB │ FB E3 21 82 │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF ......!................. 00099D98 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF ........................ 00099DB0 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF ........................ 00099DC8 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF ........................ 00099DE0 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF ........................
So, the higher addresses are erased, and they match up to 0x99d89. The upgrade seems to have erased block 0 then just stopped writing at 0x99d89.
What caused that? An I/O error on the USB stick, flash failure, something else? Anyway, it will not reboot.
Urjtag cannot determine the flash type to set the parameters, and so the flash cannot be erased and rewritten.
The instrument is good for some spares!
Rigol’s upgrade procedure has no recovery, the instrument is now only good for some spares!
Where to?
I may attempt to replace the flash chip.
Addendum
I offer the following tested patch to fix a defect in Urjtag in support of the "Olimex ARM-USB-TINY-H (FT2232H) Cable".
--- org/ft2232.c 2019-05-13 07:49:47.028616448 +1000
+++ ft2232.c 2023-11-11 07:34:56.614842343 +1100
@@ -2601,7 +2601,7 @@
URJ_DECLARE_FTDX_CABLE(0x15BA, 0x0004, "-mpsse", "ARM-USB-OCD", armusbocdtiny)
const urj_cable_driver_t urj_tap_cable_ft2232_armusbtiny_h_driver = {
- "ARM-USB-OCD-H",
+ "ARM-USB-TINY-H",
N_("Olimex ARM-USB-TINY-H (FT2232H) Cable"),
URJ_CABLE_DEVICE_USB,
{ .usb = ft2232_connect, },
.