Products > Test Equipment
Rigol DSXXXX .GEL firmware file format
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
[0] Message Index
[#] Next page
[*] Previous page
Go to full version