Backup Firmware DG1022

[tv84]

One of my files is the bootloader.

00000040 - 000002C0  00019982  20000000  0000  0000  00000000  [000002C0-00019C41]

You must place the blue block at the red address in the NVRAM dump! (remember that address 0x20000000 = offset 000000 in the dump)

[JimKnopf]

@tv84 Today i tried to flash the modified ldr file. The file is attached as zip file.
I could not erase the memory before writing. After writing i could not verify it. The DG1022 does not start.

Please, can someone send me a flashdump or proper prepared ldr file for DG1022?

[tv84]

I've asked for external help BUT you should further investigate the not being able to verify.

Because, even with a correct dump, if you can't write/verify the thing correctly, it is useless.

[JimKnopf]

@tv84 OK, i used shorter wires and reduced clock speed (1 MHz instead of 6 MHz). Writing and  verifying worked.

But the device will not start.

[JimKnopf]

@tv84 I found out that the problem was related to the clock speed rather than wire length. The clock signal on the Segger clone becomes unstable at more than 3MHz.

[JimKnopf]

@tv84 Any idea why i can't programm the address space 0x0000 - 0x3fff? When i programm the nvram via jtag, the mentioned area is empty.

I tried different programmers now: TIAO Tumpa, Olimex Tiny-H, Segger j-link clone. Always the same result.

[JimKnopf]

@tv84 How can i move data from 0000 02C0 - 0001 9C4 to 2000 0000 in NVRAM dump when the file ends at  003F FFFF?

[JimKnopf]

That's good news. I'll try to get some help.

Till now i couldn't figure our why i cannot write to  0x0000 0000  - 0x0000 3fff via jtag. Hint's are welcome.

Anyway, i desoldered the 4MB S29GL032N 48 pin flash memory and programmed it in my RT809H using an 48-pin adapter.
I have to say that this is way faster than waiting 40 minutes when programming via jtag. 
Desoldering with low melting solder (Chemet Bi57Sn43) took less than 2 minutes, cleaning and preparing the solderpads with new solder took 2 more minutes.

Erasing, programming and verifying the data took less than 5 minutes. Soldering back the Chip was pretty easy.

I did this in less than 20 minutes, half the time i need to programm the flash via jtag. And soldering looks better than factory.

@tv84 The 52 49 ... data  from the file now starts at 0x0000 0000 in the flashmemory (loaded at 0x2000 0000 for BF531).
But the device still doesn't start.

Would be great ff anyone could support me with a memory dump for a DG1022, Version 00.03.00.08.00.02.08.

[tv84]

Jim,

I corrected the first 0x130 bytes of your dump (they were totally wrong).

Attached is the corrected .bin you should flash. Even so, the file missed some important areas.

I include also its Blackfin .LDR parsings to validate that the contents of this dump is sound and should allow the device to boot.

[JimKnopf]

@tv84 Thank you alot for your effort. The device starts with your modification.
I can see the button lights at boot sequence and hear the relais after booting.
I can recognize the device via USB on Linux and it show up on UltraSigma in my Windows-VM.

The display will not turn on. It flashes one time when pressing power button and goes dark.
After booting up when pressing "View" button, the button itself lights up but display remains dark.

I can't use it with UltraSigma (maybe Softwareproblem, not a device problem?).

[JimKnopf]

@tv84 It was 00.03.00.08.00.02.08 when i tried to update.

00 Bootversion
   .03 Hardware revision
        .00.08 FPGA version
                  .00.02.08 DSP version

[tv84]

Try this one from a working unit with your settings, crafted by me.

This one was extracted from a 00.03.00.08 machine also running FW 2.08. So I'm confident it must work.

Report the results.

[JimKnopf]

@tv64 Many many thanks for your patience and effort. The device works.
It shows up the correct serial number.

[tv84]

The device works.
It shows up the correct serial number.

  Show us the screenshot with the HW and FW version just for future reference.

[JimKnopf]

@tv84 Interesting, the Version number show some crap.

What is the best way to update this device? Using  a LDR file or with a GEL file?
The bootloader has to be updated first.

[tv84]

Interesting and that could be helpful for my investigations. -> EDIT: There are 20 bytes (I think they are not very important) that were wrong in the dump you provided and that I unknowingly reused, but should be corrected in order for the HW/FW version to look correct.

So, that allowed me to discover where the .GEL contains the FW version.

Here is the parsing of the 2.10 FW as an example:

Code: [Select]

00000000 - File Type: RIGOL:DG1:UPDATE FILE ALL
Offset     StartAdd  Size      LoadAddr  CRC16       Rsvd                           CRC16_calc
00000040 - 000002C0  00000000  20000000  0000  0000  00000000
00000054 - 000002C0  001B4BC0  20030000  0000  0000  00000000  [000002C0-001B4E7F]  DBE0
00000068 - 001B4E80  00001194  20208000  0000  0000  00000000  [001B4E80-001B6013]  1907
0000007C - 001B6014  00001194  2020C000  0000  0000  00000000  [001B6014-001B71A7]  532D
00000090 - 001B71A8  00004650  20210000  0000  0000  00000000  [001B71A8-001BB7F7]  7712
000000A4 - 001BB7F8  00002EE0  20220000  0000  0000  00000000  [001BB7F8-001BE6D7]  9CD1
000000B8 - 001BE6D8  0000EA60  20228000  0000  0000  00000000  [001BE6D8-001CD137]  DC3F
000000CC - 001CD138  00007530  20250000  0000  0000  00000000  [001CD138-001D4667]  E68F
000000E0 - 001D4668  00000590  20260000  0000  0000  00000003  [001D4668-001D4BF7]  5C1C
001D46A8 - FW Version: 00.02.10.00 - RIGOL TECHNOLOGIES,DG1012C,DG1F
000000F4 - 001D4BF8  00070000  20290000  0000  0000  00000000  [001D4BF8-00244BF7]  B343
Regarding upgrade, AFAIK 2.08 can't be upgraded (see attached file). I suppose it must be because of the bootloader.

So, my suggestion would be, I can create an image  based on a 2.10 dump. Then you flash that image.

Then you can execute upgrade to version 2.12.

Or, first, you try to upgrade to 2.10 with the stock GEL only and see if you can make it work.

[JimKnopf]

@tv84 Where did you got this information from? The official Rigol release notes confused me when i tried to update because my device never displayed such a long 10 digit DSP version number.

They advised in their release notes:

    IF you have a DG1022 read this:
     1) If the version is < 00.03.00.08.00.02.08.00.01 then you can only update using the LDR version.
         Then you MUST use the LDR file and the instructions in “DG1022 Legacy LDR Update
         Instructions”.

Does version number 00.03.00.08.00.02.08 means < 00.03.00.08.00.02.08.00.01? Or is it the mentioned version number but some digits are just missing on the display?

I took the attached image before the update.

[JimKnopf]

@tv84 I can't update the regular way. Maybe because of the strange version number?

[tv84]

Most probably. I suspected that.

Do you want me to create a 2.12 version with boot 3?

I think that would allow to flash a stock 3.01.00 FW directly.

[JimKnopf]

@tv84 That would be great. I would give it a try.

[tv84]

@tv84 That would be great. I would give it a try.

But you"ll have to flash with programmer, ok?

[JimKnopf]

@tv84 I have done this about 10 or 12 times now with this chip. I ordered some new S29GL032N90TFI04 flash chips because I think the chip will die eventually. At some point it will have been too much. Even if you are skilled, once, twice or three times you can do it with a TSOP48 flash chip. But the chip can't take that much heat. And the more often you do it, the worse it sits in the programming socket. Solder residues remain on the legs and lead to contact problems in the socket.
 

[tv84]

Just for future reference, and because Rigol instructions are not very clear, what Rigol calls the .LDR file (attached) is a file that loads (IMHO) the 00.02.07.00 FW version.

So, anyone with a higher version should never flash this one. I think this was JimKnopf's initial mistake.

[JimKnopf]

@tv84 I think i tried a LDR file but it was a different one. I checked the LDR files i have and compared the md5sum against the file you attached:

find ./ -name '*LDR*.zip' -exec md5sum {} \;
c30ee29b93dc6bddb540b385c1b6be5b  ./examples/tv84/DG10x2_Update_Last_LDR.zip
876a1d457f5f3e77aeddd8290bd02270  ./DG10x2_Update_Last_LDR_00.02.07.00.zip
c30ee29b93dc6bddb540b385c1b6be5b  ./dg1000_latest/LDR/DG10x2_Update_Last_LDR.zip
c30ee29b93dc6bddb540b385c1b6be5b  ./dg1000_/DG10x2_Update_Last_LDR.zip

I have the latest LDR file from Rigol website.

[tv84]

I have the latest LDR file from Rigol website.

My ZIP contains a parsing of the .LDR made by me.

You should not compare the ZIPs but the LDR inside.