Products > Test Equipment
Rigol DSXXXX .GEL firmware file format
<< < (33/38) > >>
tv84:

--- Quote from: janekivi on April 12, 2018, 09:27:37 pm ---Files itself coming after header with their own 24 byte headers.
File headers first 4 bytes is file CRC32 in little endian.
Next 4 bytes are info about compression. This is probably in hex format and also bitmask.
03 00 00 00 (bitmask 0011) - if there is LZMA packed app
01 00 00 00 (bitmask 0001) - if there is LZMA packed gui data
00 00 00 00 (bitmask 0000) - if there is plain file
Next 4 bytes are file length in little endian.
Next 4 bytes are AA 55 55 AA - unknown.
Next 4 bytes are software version in little endian like 6E A6 3D 00 = 4040302.
Next 4 bytes are software branch 00 00 00 00. tv84 explanation

--- End quote ---

An addon to the explanation of these last 8 bytes:

The model's version (as placed in the GEL's header) is: 00.04.04.03.02

the RED is the software branch
the BLUE is the version number

In the region of the 24-bytes headers, quoted above, the last 8 bytes are:

4 bytes are software version in little endian like 6E A6 3D 00 = 04.04.03.02
4 bytes are software branch 00 00 00 00 = 00

If we look at the whole 8 bytes in little-endian the (4 bytes) branch comes before the (4 bytes) version.

This is important because when we want to upload a "temporary version" (like the one in the attached picture), one must change these "branch" bytes of the SparrowAPP file.

An "official version" appears when there is a previous "temporary version" installed in the scope, and we change the branch to 00.
janekivi:

--- Quote from: tv84 on April 19, 2018, 08:31:56 am ---
--- Quote from: Shock on April 18, 2018, 09:53:10 pm ---0.04.04.03.02 2017/02/06 almost suggests it might have the file as the release notes mentioned a bootloader fix, but it's not listed in the header. Have you checked that version?

--- End quote ---

As you can see in my parsing file DS1000_parsing_v2.txt, in previous msgs, the only 04.04.03.02 that is publicly available doesn't have a bootloader.

But, someone who has a factory 4.4.3.2 might have a bootloader in it's NAND. So, if they could extract it or from NVRAM...

Then I would assume 4.4.1.1 is 1.3 and the 4.4.3.2 has a 1.4.

Needs to be checked by you guys.

--- End quote ---

In 00.04.00.00.00 is bootloader 0.0.1.0.
I got mine from factory with 0.0.1.2 and have extracted it from memory here.
From NAND I extracted this 00.04.04.01.01 where was bootloader 0.0.1.4.

Now you need to find out how this is stored there because I can't find it by debuging...
konnor:
LOAD:41047414 MainProcess                             ; DATA XREF: LOAD:MQX_template_listo
LOAD:41047414                 STMFD   SP!, {R12,LR}
LOAD:41047418                 MOV     R0, BootVersion
LOAD:41047420                 MOV     R1, 0x10010
LOAD:41047428                 STR     R1, [R0]

Shock:
According to Rigol, these three firmware had associated bootloader:
00.04.00.00.00   0.0.1.0 released on 20140318
00.04.01.02.00   0.0.1.1 released on 20140728
00.04.02.03.00   0.0.1.2 released on 20141021

Then there was:
00.04.02.04.07 0.0.1.? released on 20141231

My scope (build date 2015/03) came with:
00.04.03.00.01 0.0.1.3 released on 20150505
janekivi:

--- Quote from: konnor on April 21, 2018, 01:36:21 pm ---LOAD:41047414 MainProcess                             ; DATA XREF: LOAD:MQX_template_listo
LOAD:41047414                 STMFD   SP!, {R12,LR}
LOAD:41047418                 MOV     R0, BootVersion
LOAD:41047420                 MOV     R1, 0x10010
LOAD:41047428                 STR     R1, [R0]

--- End quote ---

So bootloader is writing it into memory? I see app is reading it from somewhere.
Where the version is hidden in bootloader?
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod