EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: zybizg on May 10, 2018, 10:16:26 pm
-
New firmware Rigol DS1000Z 00.04.04.03.05 2018-05-09 (2018-02-28)
http://www.rigol.com/Support/SoftDownload/3 (http://www.rigol.com/Support/SoftDownload/3)
Release notes?
-
Release notes?
Appears to be encrypted with "E-SafeNet"
(https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/?action=dlattach;attach=429677;image)
I read a PDF (https://raw.githubusercontent.com/c3c/E-Safenet/master/report.pdf) and it's really rubbish encryption, if anybody can do Python there's a cracker here:
https://github.com/c3c/E-Safenet (https://github.com/c3c/E-Safenet)
(I'm not a Python person, don't have it installed...)
-
Pluses gone? :'(
-
Curious. It's on the Chinese web page (www.rigol.com (http://www.rigol.com)) but not on the "International" (int.rigol.com) website.
Who dares? ;)
-
I did.
No more "Pluses" :-- It was really a sort of trademark. And some sense of humor doesn't hurt!
I was wrong, Pluses are still there :)
Vertical channel alignment is better in my unit. Mine had a very slight deviation between channels, it doesn't happen any longer.
Options still intact :-+
Now I'm curious about the release notes.
-
On my MSO1074 worked as well, strangely enough, on the System Info version number didn't change ( 04.04.sp3) but trying to update again finds the software at the new version :wtf:.
Autocalibration in progress, let's see.
Cheers,
DC1MC
-
The last update (I have) is v00.04.04.03.02, this update is 00.04.04.03.05. So both versions are 00.04.04.03 :-)
-
Nice to know they have not completely abandoned this model. :-+
-
I don't think there were any real bugs left. Maybe a few minor ones.
Or ... are there any new features?
(unlikely - the file size is almost identical)
Maybe the people over in the firmware hacking thread can put "Pluses" back in for us.
Are there no Python gurus reading this who can decrypt the release notes?
-
I don't think there were any real bugs left. Maybe a few minor ones.
The USB transfer speed as someone (is it Karel the DSRemote author ?) mentioned Rigol is not fully implementing certain USB standards if I'm not mistaken. I don't remember the details. :-//
-
Return of sense of humour for Borjam the Horizontal Statistic selection menu now has Pulses spelt correctly but the actual displayed Stats at the bottom of the display is still Pluses. Oh well the next upgrade sigh! :-+
-
DC1MC if you look at the detailed System Info via the rapid button pushing technique it displays the the full F/W status and it definitely is an 00.04.04.03.05 after the upgrade.
-
On my MSO1074 worked as well, strangely enough, on the System Info version number didn't change ( 04.04.sp3) but trying to update again finds the software at the new version :wtf:.
Autocalibration in progress, let's see.
The ordinary system info doesn't show the final set of digits, only the first three.
DC1MC if you look at the detailed System Info via the rapid button pushing technique it displays the the full F/W status and it definitely is an 00.04.04.03.05 after the upgrade.
Menu -> Menu -> Force -> Menu -> Utility -> System -> System Info
But ... if the major numbers don't change then I think this could be a very minor update.
-
On my MSO1074 worked as well, strangely enough, on the System Info version number didn't change ( 04.04.sp3) but trying to update again finds the software at the new version :wtf:.
Autocalibration in progress, let's see.
The ordinary system info doesn't show the final set of digits, only the first three.
DC1MC if you look at the detailed System Info via the rapid button pushing technique it displays the the full F/W status and it definitely is an 00.04.04.03.05 after the upgrade.
Menu -> Menu -> Force -> Menu -> Utility -> System -> System Info
But ... if the major numbers don't change then I think this could be a very minor update.
Well this a screenshot of this "magic" ;) info screen
Cheers,
DC1MC
-
Are there no Python gurus reading this who can decrypt the release notes?
I'm no Python guru, but I do know and use Python, and I'm trying to get to decrypt the release notes, but I'm not able to obtain yet any sensible cleartext.
I'm following the "probable plaintext attack" route, trying to feed pieces of the previous release notes.
It seems only the recent updates for the DS100Z and DS2000A have the release notes encrypted. Other f/w upgrades released this month are in plain text as it should, with the oddball of the DG1KZ release notes being a UTF-16 file.
-
Are there no Python gurus reading this who can decrypt the release notes?
I'm no Python guru, but I do know and use Python, and I'm trying to get to decrypt the release notes, but I'm not able to obtain yet any sensible cleartext.
I'm following the "probable plaintext attack" route, trying to feed pieces of the previous release notes.
It seems only the recent updates for the DS100Z and DS2000A have the release notes encrypted. Other f/w upgrades released this month are in plain text as it should, with the oddball of the DG1KZ release notes being a UTF-16 file.
This encrypted file is also UTF-16 encoded, this why the ASCI decoder doesn't work :( and it's a bit larger.
Probing with diverse parts I see now and then something like H i s t o r y and R e l e a s e, but the program replaces the zeroes in UTF-16 with spaces and itsn't able to deduce the key :(
The program needs to be adapted for UTF-16 in the plaintext mode, but this really needs someone who knows python and this is not me unfortunately.
DC1MC
-
I prefer to wait to see really errore corrects, so they comment "pluses" no, I have installed the version of Konor that fixes that error, so let's see what the gurus opninan. and here is the previous version https://beyondmeasure.rigoltech.com/acton/form/1579/0025:d-0005/0/-/-/-/-/index.htm (https://beyondmeasure.rigoltech.com/acton/form/1579/0025:d-0005/0/-/-/-/-/index.htm)
-
This encrypted file is also UTF-16 encoded, this why the ASCI decoder doesn't work :( and it's a bit larger.
Probing with diverse parts I see now and then something like H i s t o r y and R e l e a s e, but the program replaces the zeroes in UTF-16 with spaces and itsn't able to deduce the key :(
The program needs to be adapted for UTF-16 in the plaintext mode, but this really needs someone who knows python and this is not me unfortunately.
I don't know Python but I'm guessing you have to add "or o == 0" at the end of line 86 of file partial_c.py
(in function "is_allowed_char")
-
This encrypted file is also UTF-16 encoded, this why the ASCI decoder doesn't work :( and it's a bit larger.
Probing with diverse parts I see now and then something like H i s t o r y and R e l e a s e, but the program replaces the zeroes in UTF-16 with spaces and itsn't able to deduce the key :(
The program needs to be adapted for UTF-16 in the plaintext mode, but this really needs someone who knows python and this is not me unfortunately.
I don't know Python but I'm guessing you have to add "or o == 0" at the end of line 86 of file partial_c.py
(in function "is_allowed_char")
Not that easy unfortunately, the whole program has to be modified for UTF-16 :(
DC1MC
-
i think this is just a counter act on the hacked rigol fw thread, they probaly only correct Pluses in one place and thats it, and then encrypt it so no more low level hack. they dont even bother or dont know how to use "Find word" feature to correct all the Pluses, i guess they are on Win7 or later (Find file with keyword function in WinExplorer is real sucks). Possibly they also blocked hacked version from being installed in this version. If there is no substantial improvement, i will say there is no need to upgrade to this official version, we may keep an eye on the hacked fw thread. ymmv.
-
Release notes?
Appears to be encrypted with "E-SafeNet"
Why would one encrypt the release notes?
-
Why would one encrypt the release notes?
:-// Perhaps the package was assembled using internal engineering documents, which could be encrypted to avoid possible 'leaks' to spill news before they are ready for the public release.
-
Those +Pluses -Pluses and RNAGe RNAG are exactly like in previous version
so for them they were already corrected and they think we are just joking...
Downgrade is possible in different ways and I believe hacking isn't problem
either. Comparing functions can give better overview what is changed.
-
Release notes?
Appears to be encrypted with "E-SafeNet"
I read a PDF (https://raw.githubusercontent.com/c3c/E-Safenet/master/report.pdf) and it's really rubbish encryption, if anybody can do Python there's a cracker here:
https://github.com/c3c/E-Safenet (https://github.com/c3c/E-Safenet)
(I'm not a Python person, don't have it installed...)
Here we go again! ;D
00000000 - File Type: DS1000Z
00000010 - Software Branch/Version: 00.04.04.03.05
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset Section Name SectiSz StartAdr CRC32 Type
00000028 /sys/SparrowAPP.out 00109197 00000280 F0939219 00000001 [00000280-00109416] CRC OK
00000064 /sys/SparrowFPGA.hex 000C4372 00109417 D9C46F2E 00000005 [00109417-001CD788] CRC OK
000000A0 /sys/SparrowDGFPGA.hex 00046F04 001CD789 433D327B 00000006 [001CD789-0021468C] CRC OK
000000DC /sys/logo.hex 000BB818 0021468D C9D7EDE5 0000000A [0021468D-002CFEA4] CRC OK
00000118 /sys/guiResData.hex 000B6A2C 002CFEA5 322A3B01 0000000C [002CFEA5-003868D0] CRC OK
00000154 /sys/guiPicData.hex 0001E6BF 003868D1 7F322FAE 00000011 [003868D1-003A4F8F] CRC OK
00000190 /sys/SparrowConfig.hex 000BB818 003A4F90 DF2A2311 00000010 [003A4F90-004607A7] CRC OK
000001CC /sys/SparrowWaveTable.hex 000020E8 004607A8 C29BAD69 0000000B [004607A8-0046288F] CRC OK
00000208 /sys/SparrowCalFile.hex 0002329C 00462890 5613C891 0000000F [00462890-00485B2B] CRC OK
00000244 00000118 00485B2C 00000000 00000032 [00485B2C-00485C43]
Offset CRC32 Flags Filesize Endianes Branch/Version
00000280 FD9F4BF8 00000003 0010917F AA5555AA 00.04.04.03.05 [00000298-00109416] CRC OK
00109417 C9AF5D56 00000000 000C435A AA5555AA 00.04.04.03.05 [0010942F-001CD788] CRC OK
001CD789 138E13B9 00000000 00046EEC AA5555AA 00.04.04.03.05 [001CD7A1-0021468C] CRC OK
0021468D 9B4EA177 00000000 000BB800 AA5555AA 00.04.04.03.05 [002146A5-002CFEA4] CRC OK
002CFEA5 D7825E44 00000000 000B6A14 AA5555AA 00.04.04.03.05 [002CFEBD-003868D0] CRC OK
003868D1 01873014 00000001 0001E6A7 AA5555AA 00.04.04.03.05 [003868E9-003A4F8F] CRC OK
003A4F90 5DEF7058 00000000 000BB800 AA5555AA 00.04.04.03.05 [003A4FA8-004607A7] CRC OK
004607A8 558BD392 00000000 000020D0 AA5555AA 00.04.04.03.05 [004607C0-0046288F] CRC OK
00462890 7717C897 00000000 00023284 AA5555AA 00.04.04.03.05 [004628A8-00485B2B] CRC OK
Must be a minor bug correction since all other files are the same as in 00.04.04.03.02 and SparrowAPP is even 124 bytes shorter.
Regarding the encrypted release notes, I think they gave up on protecting the GEL and turned to the release notes! :-DD
-
Not that easy unfortunately, the whole program has to be modified for UTF-16 :(
It shouldn't make any difference to the overall program.
The UTF-16 actually makes it a lot easier because you know what half the bytes of the plaintext are (assuming it's ASCII text like all the other release notes, every other byte will be zero).
-
Are there no Python gurus reading this who can decrypt the release notes?
I'm no Python guru, but I do know and use Python, and I'm trying to get to decrypt the release notes, but I'm not able to obtain yet any sensible cleartext.
I'm following the "probable plaintext attack" route, trying to feed pieces of the previous release notes.
By looking at the E-SafeNet header of the 'MSO_DS1000Z Release Notes.txt', the header does not follow any more the format described in table 1 (page 9 of 'report.pdf' from https://github.com/c3c/E-Safenet).
- bytes '8-10 checksum: sum of bytes 512-1023 of the plaintext' (which were criticized in the PDF paper for leaking information about the file being a text or a binary type) are now all 00
- bytes '4-5' indicates the header will end before byte 0x00AA, and we expect 00 padding between 0x001C and 0x00AA, yet not all bytes in that range are zero. There are 32 bytes expected to be all padding zeros (from 0x0028 to 0x0047), but they are "E3 40 15 BE 5C E0 08 87 DD 42 47 D2 EE FF EE EC AF 53 B7 11 4F C7 30 0D DF EF 9E 0A 87 49 DA 07" instead of all 00. Maybe an 128 bit public key?
The research paper is from 2014. My guess is the current E-SafeNet encryption scheme is somehow different from the one used in the c3c's decryption implementation on github.
It would be interesting to see if the autocorrelation test used in section 4.1 of the PDF will still show a 512 bytes pattern for our file.
Of course, decrypting the release notes doesn't add any value to the current firmware, it is more of a curiosity exercise. :P
-
Not that easy unfortunately, the whole program has to be modified for UTF-16 :(
It shouldn't make any difference to the overall program.
The UTF-16 actually makes it a lot easier because you know what half the bytes of the plaintext are (assuming it's ASCII text, every other byte will be zero).
Totally agree. Thinking on it at the moment.
-
I'm not sure the English release notes is UTF. My assumption will be it is still ASCII, because the English update instructions file is ASCII, too.
Also, both the Chinese and the English version of the release notes contain the same 32 unexplained bytes in the E-SafeNet header: E3 40 15 BE 5C E0 08 87 DD 42 47 D2 EE FF EE EC AF 53 B7 11 4F C7 30 0D DF EF 9E 0A 87 49 DA 07, so I assume the header and the algorithm for E-SafeNet has changed.
-
I'm not sure the English release notes is UTF.
Neither am I, I'm not sure where that came from. It is twice as big as before though...
-
To better illustrate the theory, half of the key is already visible in this image.
Look after the 1rst row. The bytes in the odd positions are always the same.
Half done, half to go!
Look at the .BMP in the ZIP. The image clearly confirms that the file must be UTF-16.
Edit: corrected this msg just for historical reasons.
-
To better illustrate the theory, half of the key is already visible in this image.
Look after the 1rst row. The bytes in the odd positions are always the same.
Exactly. Every odd byte is zero so when you XOR it with the key you get the key.
On the even bytes: You need to find value which gives valid ASCII when you XOR them with all the rows.
-
Half of the key:
xx CA xx 8E xx 92 xx E9 xx C5 xx 1F xx 49 xx D0
xx A3 xx 21 xx D9 xx A0 xx 91 xx DC xx 27 xx BA
xx 02 xx B6 xx 61 xx 1D xx C8 xx 3C xx 7D xx 60
xx BE xx 6B xx E4 xx FA xx 47 xx 1C xx ED xx 30
xx CD xx 3F xx A2 xx C0 xx 89 xx 47 xx 16 xx A8
xx 2E xx E2 xx 8F xx 60 xx 81 xx 13 xx 0D xx DA
xx C1 xx 7B xx EF xx AF xx 1C xx 9F xx 0F xx 76
xx B9 xx 7D xx 12 xx 7C xx BE xx 22 xx D8 xx 62
xx FA xx 41 xx 85 xx C2 xx 5F xx 1E xx 02 xx 3D
xx 3F xx 17 xx EC xx 91 xx DB xx 48 xx 9E xx A5
xx 47 xx FD xx 5A xx 20 xx 9E xx B6 xx C2 xx D7
xx 98 xx 5F xx 65 xx 2E xx D5 xx 4E xx 67 xx 7E
xx 9C xx DA xx 75 xx 66 xx 01 xx E2 xx 8E xx 0F
xx 4A xx 9D xx 87 xx 39 xx 0C xx 0E xx 17 xx E4
xx 67 xx 75 xx 8F xx 3E xx 3A xx 16 xx 47 xx F6
xx C9 xx 76 xx 61 xx 28 xx C9 xx 09 xx B2 xx BF
xx 2E xx 1D xx A1 xx D9 xx 46 xx E6 xx D2 xx EB
xx 41 xx FB xx 2F xx 45 xx E4 xx 69 xx D4 xx 1D
xx 26 xx A9 xx AF xx CA xx EC xx 3A xx 1E xx CD
xx 58 xx EC xx 58 xx 2C xx 65 xx 36 xx A4 xx 7D
xx 84 xx 15 xx 41 xx 8A xx 69 xx E1 xx 60 xx 52
xx 41 xx 26 xx 10 xx 69 xx FA xx 0D xx 5C xx 44
xx 37 xx 7A xx B1 xx 81 xx 32 xx A7 xx 2F xx B4
xx 01 xx A5 xx 3D xx 44 xx B1 xx A5 xx BF xx B5
xx C5 xx 8C xx A2 xx A0 xx 60 xx 06 xx DC xx 25
xx 1E xx 61 xx 31 xx 96 xx 6F xx 6E xx 23 xx EC
xx C3 xx 44 xx ED xx 85 xx 3B xx C3 xx 38 xx BB
xx D7 xx 51 xx 15 xx 29 xx 22 xx CE xx F8 xx F7
xx 56 xx 80 xx 1A xx FD xx 37 xx 38 xx AB xx C5
xx BD xx D5 xx FA xx 43 xx A8 xx 75 xx 38 xx 53
xx 50 xx EB xx 0E xx 6B xx 58 xx EB xx FE xx BC
xx A3 xx 75 xx 96 xx C1 xx 22 xx A5 xx 7B xx 8F
-
Cool :)
In case anyone wants to check what bugs actually have been fixed, please consider commenting here on the DS1000Z buglist thread (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/), so I can keep track and update the OP.
I am going to try the update myself this weekend and start working on it accordingly.
Thank you and kind regards,
Frederik
-
Half of the key:
xx CA xx 8E xx 92 xx E9 xx C5 xx 1F xx 49 xx D0
xx A3 xx 21 xx D9 xx A0 xx 91 xx DC xx 27 xx BA
xx 02 xx B6 xx 61 xx 1D xx C8 xx 3C xx 7D xx 60
xx BE xx 6B xx E4 xx FA xx 47 xx 1C xx ED xx 30
xx CD xx 3F xx A2 xx C0 xx 89 xx 47 xx 16 xx A8
xx 2E xx E2 xx 8F xx 60 xx 81 xx 13 xx 0D xx DA
xx C1 xx 7B xx EF xx AF xx 1C xx 9F xx 0F xx 76
xx B9 xx 7D xx 12 xx 7C xx BE xx 22 xx D8 xx 62
xx FA xx 41 xx 85 xx C2 xx 5F xx 1E xx 02 xx 3D
xx 3F xx 17 xx EC xx 91 xx DB xx 48 xx 9E xx A5
xx 47 xx FD xx 5A xx 20 xx 9E xx B6 xx C2 xx D7
xx 98 xx 5F xx 65 xx 2E xx D5 xx 4E xx 67 xx 7E
xx 9C xx DA xx 75 xx 66 xx 01 xx E2 xx 8E xx 0F
xx 4A xx 9D xx 87 xx 39 xx 0C xx 0E xx 17 xx E4
xx 67 xx 75 xx 8F xx 3E xx 3A xx 16 xx 47 xx F6
xx C9 xx 76 xx 61 xx 28 xx C9 xx 09 xx B2 xx BF
xx 2E xx 1D xx A1 xx D9 xx 46 xx E6 xx D2 xx EB
xx 41 xx FB xx 2F xx 45 xx E4 xx 69 xx D4 xx 1D
xx 26 xx A9 xx AF xx CA xx EC xx 3A xx 1E xx CD
xx 58 xx EC xx 58 xx 2C xx 65 xx 36 xx A4 xx 7D
xx 84 xx 15 xx 41 xx 8A xx 69 xx E1 xx 60 xx 52
xx 41 xx 26 xx 10 xx 69 xx FA xx 0D xx 5C xx 44
xx 37 xx 7A xx B1 xx 81 xx 32 xx A7 xx 2F xx B4
xx 01 xx A5 xx 3D xx 44 xx B1 xx A5 xx BF xx B5
xx C5 xx 8C xx A2 xx A0 xx 60 xx 06 xx DC xx 25
xx 1E xx 61 xx 31 xx 96 xx 6F xx 6E xx 23 xx EC
xx C3 xx 44 xx ED xx 85 xx 3B xx C3 xx 38 xx BB
xx D7 xx 51 xx 15 xx 29 xx 22 xx CE xx F8 xx F7
xx 56 xx 80 xx 1A xx FD xx 37 xx 38 xx AB xx C5
xx BD xx D5 xx FA xx 43 xx A8 xx 75 xx 38 xx 53
xx 50 xx EB xx 0E xx 6B xx 58 xx EB xx FE xx BC
xx A3 xx 75 xx 96 xx C1 xx 22 xx A5 xx 7B xx 8F
On the even bytes: You know bit 7 of the plaintext is zero so you know that bit in the key, too. :-)
The bottom 5 bits should mostly appear if you do the "valid ASCII" check on all the rows. That leave two bits which are difficult.
-
It's precisely the same key in the DS2000 release notes. ;)
With a bit of brute-force we can work out the whole key.
-
A good bet would be to take the last 256 bytes of the previous release notes, convert to UTF-16 and use that as 'known plaintext'. The key might pop right out if you do that.
Try a couple of variants in case they added an extra CRLF a the end of the file or something trivial.
-
It's precisely the same key in the DS2000 release notes. ;)
In that case they've totally blown it. Never use your one-time-pad twice!
Just XOR together the second block of the both files and you'll get the complete key.
Edit: No, hang on, that's not right... let me think.
Edit2: Nope, you get the XOR of the two plaintext.
I think the best bet is what I said in the previous post: Assume the last 256 bytes of the new file is the same as the previous one. The key should pop right out.
-
Your last 256 bytes tactic might be the way to go. But, by hand, without UTF conversions.
Start with a bottom-up technique! :)
-
Edit2: Nope, you get the XOR of the two plaintext.
Yep. No use.
-
I superficially looked update.
Result:
- No new functions, only bugfixed
- No any changes on resoures (help, menu, images, etc)
- function, that determines the version of the board, is complete rewritten.
Old Function:
P4:4003B698 CPLD_GetBoardVersion ; CODE XREF: IsLogicalAnalyserPresent_+14p
P4:4003B698 ; UpdateBoardVersion+20p
P4:4003B698 ; Circuits_StartInit_13_1+10Cp
P4:4003B698 ; KBD_StartInit+190p
P4:4003B698 ; IsLogicalAnalyserPresent+20p
P4:4003B698 ; SetupDS1104Z+174p
P4:4003B698 ; TestPresenceDevices+Cp
P4:4003B698
P4:4003B698 IoBuffer = -0x18
P4:4003B698 Buff = -0x14
P4:4003B698
P4:4003B698 STMFD SP!, {R4,R5,LR} ; Store Block to Memory
P4:4003B69C SUB SP, SP, #0xC ; Rd = Op1 - Op2
P4:4003B6A0 LDR R0, =pSPI2_BusHandle ; Load from Memory
P4:4003B6A4 LDR R4, [R0] ; Load from Memory
P4:4003B6A8 MOVS R0, SP ; Rd = Op2
P4:4003B6AC MOV R1, #0 ; Rd = Op2
P4:4003B6B0 STRH R1, [R0,#0x18+IoBuffer] ; Store to Memory
P4:4003B6B4 CMP R4, #0 ; Set cond. codes on Op1 - Op2
P4:4003B6B8 BNE loc_4003B6C4 ; Branch
P4:4003B6BC MOV R0, #0 ; Rd = Op2
P4:4003B6C0 B locret_4003B78C ; Branch
P4:4003B6C4 ; ---------------------------------------------------------------------------
P4:4003B6C4
P4:4003B6C4 loc_4003B6C4 ; CODE XREF: CPLD_GetBoardVersion+20j
P4:4003B6C4 MOV R1, #SPI2_CS_CPLD ; Rd = Op2
P4:4003B6C8 STR R1, [SP,#0x18+Buff] ; Store to Memory
P4:4003B6CC ADD R2, SP, #0x18+Buff ; Buff
P4:4003B6D0 MOV R1, IO_IOCTL_SPI_SET_CS ; Code
P4:4003B6D8 MOVS R0, R4 ; hFile
P4:4003B6DC BL io_ioctl ; Code:
P4:4003B6DC ; (nr & 0xFF)
P4:4003B6DC ; (type&0xFF) << 8
P4:4003B6DC ; (size&0x3FFF) <<16
P4:4003B6DC ; (dir & 3) << 30
P4:4003B6DC ;
P4:4003B6DC ; Size&dir = 0
P4:4003B6E0 ;-- 7,0 -> SPI
P4:4003B6E0 MOV R1, #7 ; Rd = Op2
P4:4003B6E4 STRB R1, [SP,#0x18+IoBuffer] ; Store to Memory
P4:4003B6E8 MOV R1, #0 ; Rd = Op2
P4:4003B6EC STRB R1, [SP,#0x18+IoBuffer+1] ; Store to Memory
P4:4003B6F0 MOV R2, #2 ; len
P4:4003B6F4 MOVS R1, SP ; Buffer
P4:4003B6F8 MOVS R0, R4 ; hOut
P4:4003B6FC BL write ; Branch with Link
P4:4003B700 MOV R1, #1 ; denominator
P4:4003B704 BL __aeabi_uidivmod ; Íà âûõîäå:
P4:4003B704 ; R0 - ðåçóëüòàò äåëåíèÿ
P4:4003B704 ; R1 - îñòàòîê äåëåíèÿ
P4:4003B708 MOV R0, #20 ; microseconds
P4:4003B70C BL Delay_mks_ ; Branch with Link
P4:4003B710 ;---
P4:4003B710 MOV R2, #2 ; Len
P4:4003B714 MOVS R1, SP ; Buffer
P4:4003B718 MOVS R0, R4 ; hFile
P4:4003B71C BL read ; Branch with Link
P4:4003B720 MOV R1, #1 ; denominator
P4:4003B724 BL __aeabi_uidivmod ; Íà âûõîäå:
P4:4003B724 ; R0 - ðåçóëüòàò äåëåíèÿ
P4:4003B724 ; R1 - îñòàòîê äåëåíèÿ
P4:4003B728 ;--
P4:4003B728 LDRB R0, [SP,#0x18+IoBuffer+1] ; Load from Memory
P4:4003B72C MOVS R5, R0,LSL#8 ; Rd = Op2
P4:4003B730 ;- 6,0 -> SPI
P4:4003B730 MOV R1, #6 ; Rd = Op2
P4:4003B734 STRB R1, [SP,#0x18+IoBuffer] ; Store to Memory
P4:4003B738 MOV R1, #0 ; Rd = Op2
P4:4003B73C STRB R1, [SP,#0x18+IoBuffer+1] ; Store to Memory
P4:4003B740 MOV R2, #2 ; len
P4:4003B744 MOVS R1, SP ; Buffer
P4:4003B748 MOVS R0, R4 ; hOut
P4:4003B74C BL write ; Branch with Link
P4:4003B750 MOV R1, #1 ; denominator
P4:4003B754 BL __aeabi_uidivmod ; Íà âûõîäå:
P4:4003B754 ; R0 - ðåçóëüòàò äåëåíèÿ
P4:4003B754 ; R1 - îñòàòîê äåëåíèÿ
P4:4003B758 MOV R0, #20 ; microseconds
P4:4003B75C BL Delay_mks_ ; Branch with Link
P4:4003B760 ;--
P4:4003B760 MOV R2, #2 ; Len
P4:4003B764 MOVS R1, SP ; Buffer
P4:4003B768 MOVS R0, R4 ; hFile
P4:4003B76C BL read ; Branch with Link
P4:4003B770 MOV R1, #1 ; denominator
P4:4003B774 BL __aeabi_uidivmod ; Íà âûõîäå:
P4:4003B774 ; R0 - ðåçóëüòàò äåëåíèÿ
P4:4003B774 ; R1 - îñòàòîê äåëåíèÿ
P4:4003B778 LDRB R0, [SP,#0x18+IoBuffer+1] ; Load from Memory
P4:4003B77C ORRS R5, R0, R5 ; Rd = Op1 | Op2
P4:4003B780 MOVS R0, R5 ; Rd = Op2
P4:4003B784 MOV R0, R0,LSL#16 ; Rd = Op2
P4:4003B788 MOVS R0, R0,LSR#16 ; Rd = Op2
P4:4003B78C
P4:4003B78C locret_4003B78C ; CODE XREF: CPLD_GetBoardVersion+28j
P4:4003B78C LDMFD SP!, {R1-R5,PC} ; Load Block from Memory
P4:4003B78C ; End of function CPLD_GetBoardVersion
New Function (with two subroutines):
P4_rw:4003B698 CPLD_GetBoardVersion ; CODE XREF: IsLogicalAnalyserPresent_+14p
P4_rw:4003B698 ; UpdateBoardVersion+20p
P4_rw:4003B698 ; Circuits_StartInit_13_1+10Cp
P4_rw:4003B698 ; KBD_StartInit+190p
P4_rw:4003B698 ; IsLogicalAnalyserPresent+20p
P4_rw:4003B698 ; SetupDS1104Z+174p
P4_rw:4003B698 ; TestPresenceDevices+Cp
P4_rw:4003B698
P4_rw:4003B698 IoBuffer = -0x28
P4_rw:4003B698 var_24 = -0x24
P4_rw:4003B698 Array = -0x20
P4_rw:4003B698
P4_rw:4003B698 STMFD SP!, {R4-R7,LR} ; Store Block to Memory
P4_rw:4003B69C SUB SP, SP, #0x14 ; Rd = Op1 - Op2
P4_rw:4003B6A0 LDR R0, =pSPI2_BusHandle ; Load from Memory
P4_rw:4003B6A4 LDR R4, [R0] ; Load from Memory
P4_rw:4003B6A8 MOVS R0, SP ; Rd = Op2
P4_rw:4003B6AC MOV R1, #0 ; Rd = Op2
P4_rw:4003B6B0 STR R1, [R0,#0x28+IoBuffer] ; Store to Memory
P4_rw:4003B6B4 MOV R6, #0 ; Rd = Op2
P4_rw:4003B6B8 MOV R5, #0 ; Rd = Op2
P4_rw:4003B6BC ADD R0, SP, #0x28+Array ; Rd = Op1 + Op2
P4_rw:4003B6C0 MOV R1, #0 ; Rd = Op2
P4_rw:4003B6C4 MOV R2, #0 ; Rd = Op2
P4_rw:4003B6C8 MOV R3, #0 ; Rd = Op2
P4_rw:4003B6CC STMIA R0!, {R1-R3} ; Store Block to Memory
P4_rw:4003B6D0 SUBS R0, R0, #0xC ; Rd = Op1 - Op2
P4_rw:4003B6D4 ;--
P4_rw:4003B6D4 CMP R4, #0 ; Set cond. codes on Op1 - Op2
P4_rw:4003B6D8 BNE loc_4003B6E4 ; Branch
P4_rw:4003B6DC MOV R0, #0 ; Rd = Op2
P4_rw:4003B6E0 B RetFunc ; Branch
P4_rw:4003B6E4 ; ---------------------------------------------------------------------------
P4_rw:4003B6E4
P4_rw:4003B6E4 loc_4003B6E4 ; CODE XREF: CPLD_GetBoardVersion+40j
P4_rw:4003B6E4 MOV R1, #1 ; Rd = Op2
P4_rw:4003B6E8 STR R1, [SP,#0x28+var_24] ; Store to Memory
P4_rw:4003B6EC ADD R2, SP, #0x28+var_24 ; Rd = Op1 + Op2
P4_rw:4003B6F0 MOV R1, 0xE14
P4_rw:4003B6F8 MOVS R0, R4 ; Rd = Op2
P4_rw:4003B6FC BL io_ioctl ; Branch with Link
P4_rw:4003B700 ;----
P4_rw:4003B700 MOV R5, #0 ; Rd = Op2
P4_rw:4003B704 B loc_4003B78C ; Branch
P4_rw:4003B708 ; ---------------------------------------------------------------------------
P4_rw:4003B708
P4_rw:4003B708 Repeat6Answer ; CODE XREF: CPLD_GetBoardVersion+D0j
P4_rw:4003B708 ADDS R6, R6, #1 ; Rd = Op1 + Op2
P4_rw:4003B70C
P4_rw:4003B70C loc_4003B70C ; CODE XREF: CPLD_GetBoardVersion+178j
P4_rw:4003B70C ANDS R6, R6, #0xFF ; Rd = Op1 & Op2
P4_rw:4003B710 CMP R6, #5 ; Set cond. codes on Op1 - Op2
P4_rw:4003B714 BCS loc_4003B76C ; Branch
P4_rw:4003B718 ;---
P4_rw:4003B718 MOV R1, #6 ; Rd = Op2
P4_rw:4003B71C STRB R1, [SP,#0x28+IoBuffer] ; Store to Memory
P4_rw:4003B720 MOV R1, #0 ; Rd = Op2
P4_rw:4003B724 STRB R1, [SP,#0x28+IoBuffer+1] ; Store to Memory
P4_rw:4003B728 MOV R2, #2 ; Rd = Op2
P4_rw:4003B72C MOVS R1, SP ; Rd = Op2
P4_rw:4003B730 MOVS R0, R4 ; Rd = Op2
P4_rw:4003B734 BL write ; Branch with Link
P4_rw:4003B738 MOV R1, #1 ; Rd = Op2
P4_rw:4003B73C BL __aeabi_uidivmod ; Branch with Link
P4_rw:4003B740 MOV R0, #0x14 ; Rd = Op2
P4_rw:4003B744 BL Delay_mks_ ; Branch with Link
P4_rw:4003B748 MOV R2, #2 ; Rd = Op2
P4_rw:4003B74C MOVS R1, SP ; Rd = Op2
P4_rw:4003B750 MOVS R0, R4 ; Rd = Op2
P4_rw:4003B754 BL read ; Branch with Link
P4_rw:4003B758 MOV R1, #1 ; Rd = Op2
P4_rw:4003B75C BL __aeabi_uidivmod ; Branch with Link
P4_rw:4003B760 LDRB R0, [SP,#0x28+IoBuffer] ; Load from Memory
P4_rw:4003B764 CMP R0, #6 ; Set cond. codes on Op1 - Op2
P4_rw:4003B768 BNE Repeat6Answer ; Branch
P4_rw:4003B76C
P4_rw:4003B76C loc_4003B76C ; CODE XREF: CPLD_GetBoardVersion+7Cj
P4_rw:4003B76C LDRB R0, [SP,#0x28+IoBuffer+1] ; Load from Memory
P4_rw:4003B770 ORRS R7, R0, R7 ; Rd = Op1 | Op2
P4_rw:4003B774 MOVS R0, R5 ; Rd = Op2
P4_rw:4003B778 ANDS R0, R0, #0xFF ; Rd = Op1 & Op2
P4_rw:4003B77C MOVS R0, R0,LSL#1 ; Rd = Op2
P4_rw:4003B780 ADD R1, SP, #0x28+Array ; Rd = Op1 + Op2
P4_rw:4003B784 STRH R7, [R0,R1] ; Store to Memory
P4_rw:4003B788 ADDS R5, R5, #1 ; Rd = Op1 + Op2
P4_rw:4003B78C
P4_rw:4003B78C loc_4003B78C ; CODE XREF: CPLD_GetBoardVersion+6Cj
P4_rw:4003B78C ANDS R5, R5, #0xFF ; Rd = Op1 & Op2
P4_rw:4003B790 CMP R5, #5 ; Set cond. codes on Op1 - Op2
P4_rw:4003B794 BCS loc_4003B814 ; Branch
P4_rw:4003B798 MOV R6, #0 ; Rd = Op2
P4_rw:4003B79C B loc_4003B7A4 ; Branch
P4_rw:4003B7A0 ; ---------------------------------------------------------------------------
P4_rw:4003B7A0
P4_rw:4003B7A0 No7Answer ; CODE XREF: CPLD_GetBoardVersion+168j
P4_rw:4003B7A0 ADDS R6, R6, #1 ; Rd = Op1 + Op2
P4_rw:4003B7A4
P4_rw:4003B7A4 loc_4003B7A4 ; CODE XREF: CPLD_GetBoardVersion+104j
P4_rw:4003B7A4 ANDS R6, R6, #0xFF ; Rd = Op1 & Op2
P4_rw:4003B7A8 CMP R6, #5 ; Set cond. codes on Op1 - Op2
P4_rw:4003B7AC BCS loc_4003B804 ; Branch
P4_rw:4003B7B0 ;---
P4_rw:4003B7B0 MOV R1, #7 ; Rd = Op2
P4_rw:4003B7B4 STRB R1, [SP,#0x28+IoBuffer] ; Store to Memory
P4_rw:4003B7B8 MOV R1, #0 ; Rd = Op2
P4_rw:4003B7BC STRB R1, [SP,#0x28+IoBuffer+1] ; Store to Memory
P4_rw:4003B7C0 MOV R2, #2 ; Rd = Op2
P4_rw:4003B7C4 MOVS R1, SP ; Rd = Op2
P4_rw:4003B7C8 MOVS R0, R4 ; Rd = Op2
P4_rw:4003B7CC BL write ; Branch with Link
P4_rw:4003B7D0 MOV R1, #1 ; Rd = Op2
P4_rw:4003B7D4 BL __aeabi_uidivmod ; Branch with Link
P4_rw:4003B7D8 MOV R0, #0x14 ; Rd = Op2
P4_rw:4003B7DC BL Delay_mks_ ; Branch with Link
P4_rw:4003B7E0 MOV R2, #2 ; Rd = Op2
P4_rw:4003B7E4 MOVS R1, SP ; Rd = Op2
P4_rw:4003B7E8 MOVS R0, R4 ; Rd = Op2
P4_rw:4003B7EC BL read ; Branch with Link
P4_rw:4003B7F0 MOV R1, #1 ; Rd = Op2
P4_rw:4003B7F4 BL __aeabi_uidivmod ; Branch with Link
P4_rw:4003B7F8 LDRB R0, [SP,#0x28+IoBuffer] ; Load from Memory
P4_rw:4003B7FC CMP R0, #7 ; Set cond. codes on Op1 - Op2
P4_rw:4003B800 BNE No7Answer ; Branch
P4_rw:4003B804
P4_rw:4003B804 loc_4003B804 ; CODE XREF: CPLD_GetBoardVersion+114j
P4_rw:4003B804 LDRB R0, [SP,#0x28+IoBuffer+1] ; Load from Memory
P4_rw:4003B808 MOVS R7, R0,LSL#8 ; Rd = Op2
P4_rw:4003B80C MOV R6, #0 ; Rd = Op2
P4_rw:4003B810 B loc_4003B70C ; Branch
P4_rw:4003B814 ; ---------------------------------------------------------------------------
P4_rw:4003B814
P4_rw:4003B814 loc_4003B814 ; CODE XREF: CPLD_GetBoardVersion+FCj
P4_rw:4003B814 MOV R1, #5 ; Length
P4_rw:4003B818 ADD R0, SP, #0x28+Array ; Array
P4_rw:4003B81C BL NewBoardVersionAnalyser ; Branch with Link
P4_rw:4003B820 MOVS R7, R0 ; Rd = Op2
P4_rw:4003B824 MOVS R0, R7 ; Rd = Op2
P4_rw:4003B828 MOV R0, R0,LSL#16 ; Rd = Op2
P4_rw:4003B82C MOVS R0, R0,LSR#16 ; Rd = Op2
P4_rw:4003B830
P4_rw:4003B830 RetFunc ; CODE XREF: CPLD_GetBoardVersion+48j
P4_rw:4003B830 ADD SP, SP, #0x14 ; Rd = Op1 + Op2
P4_rw:4003B834 LDMFD SP!, {R4-R7,PC} ; Load Block from Memory
P4_rw:4003B834 ; End of function CPLD_GetBoardVersion
P4_rw:4003C0EC ; int __cdecl NewBoardVersionRecodeFind(__int16 *, int Len, __int16 FindCode)
P4_rw:4003C0EC NewBoardVersionRecodeFind ; CODE XREF: NewBoardVersionAnalyser+44p
P4_rw:4003C0EC ; NewBoardVersionAnalyser+74p
P4_rw:4003C0EC R12_Index = R12
P4_rw:4003C0EC STMFD SP!, {LR} ; Store Block to Memory
P4_rw:4003C0F0 MOV R3, #0 ; Rd = Op2
P4_rw:4003C0F4 MOV R12_Index, #0 ; Rd = Op2
P4_rw:4003C0F8 B loc_4003C128 ; Branch
P4_rw:4003C0FC ; ---------------------------------------------------------------------------
P4_rw:4003C0FC
P4_rw:4003C0FC loc_4003C0FC ; CODE XREF: NewBoardVersionRecodeFind+50j
P4_rw:4003C0FC MOVS LR, R12_Index ; Rd = Op2
P4_rw:4003C100 MOV LR, LR,LSL#16 ; Rd = Op2
P4_rw:4003C104 MOVS LR, LR,LSR#16 ; Rd = Op2
P4_rw:4003C108 MOVS LR, LR,LSL#1 ; Rd = Op2
P4_rw:4003C10C LDRH LR, [LR,R0] ; Load from Memory
P4_rw:4003C110 MOV R2, R2,LSL#16 ; Rd = Op2
P4_rw:4003C114 MOVS R2, R2,LSR#16 ; Rd = Op2
P4_rw:4003C118 CMP LR, R2 ; Set cond. codes on Op1 - Op2
P4_rw:4003C11C BNE loc_4003C124 ; Branch
P4_rw:4003C120 ADDS R3, R3, #1 ; Rd = Op1 + Op2
P4_rw:4003C124
P4_rw:4003C124 loc_4003C124 ; CODE XREF: NewBoardVersionRecodeFind+30j
P4_rw:4003C124 ADDS R12_Index, R12_Index, #1 ; Rd = Op1 + Op2
P4_rw:4003C128
P4_rw:4003C128 loc_4003C128 ; CODE XREF: NewBoardVersionRecodeFind+Cj
P4_rw:4003C128 MOV R12_Index, R12_Index,LSL#16 ; Rd = Op2
P4_rw:4003C12C MOVS R12_Index, R12_Index,LSR#16 ; Rd = Op2
P4_rw:4003C130 MOV R1, R1,LSL#16 ; Rd = Op2
P4_rw:4003C134 MOVS R1, R1,LSR#16 ; Rd = Op2
P4_rw:4003C138 CMP R12_Index, R1 ; Set cond. codes on Op1 - Op2
P4_rw:4003C13C BCC loc_4003C0FC ; Branch
P4_rw:4003C140 MOVS R0, R3 ; Rd = Op2
P4_rw:4003C144 MOV R0, R0,LSL#16 ; Rd = Op2
P4_rw:4003C148 MOVS R0, R0,LSR#16 ; Rd = Op2
P4_rw:4003C14C LDMFD SP!, {PC} ; Load Block from Memory
P4_rw:4003C14C ; End of function NewBoardVersionRecodeFind
P4_rw:4003C14C
P4_rw:4003C150
P4_rw:4003C150 ; =============== S U B R O U T I N E =======================================
P4_rw:4003C150
P4_rw:4003C150
P4_rw:4003C150 ; int __cdecl NewBoardVersionAnalyser(__int16 *Array, int Length)
P4_rw:4003C150 NewBoardVersionAnalyser ; CODE XREF: CPLD_GetBoardVersion+184p
P4_rw:4003C150 STMFD SP!, {R4-R8,LR} ; Store Block to Memory
P4_rw:4003C154 MOVS R4, R0 ; Rd = Op2
P4_rw:4003C158 MOVS R5, R1 ; Rd = Op2
P4_rw:4003C15C MOV R6, #0 ; Rd = Op2
P4_rw:4003C160 LDRH R0, [R4] ; Load from Memory
P4_rw:4003C164 MOVS R6, R0 ; Rd = Op2
P4_rw:4003C168 MOV R7, #0 ; Rd = Op2
P4_rw:4003C16C B loc_4003C1F4 ; Branch
P4_rw:4003C170 ; ---------------------------------------------------------------------------
P4_rw:4003C170
P4_rw:4003C170 loc_4003C170 ; CODE XREF: NewBoardVersionAnalyser+B8j
P4_rw:4003C170 MOVS R0, R7 ; Rd = Op2
P4_rw:4003C174 MOV R0, R0,LSL#16 ; Rd = Op2
P4_rw:4003C178 MOVS R0, R0,LSR#16 ; Rd = Op2
P4_rw:4003C17C MOVS R0, R0,LSL#1 ; Rd = Op2
P4_rw:4003C180 LDRH R2, [R0,R4] ; FindCode
P4_rw:4003C184 MOVS R1, R5 ; Rd = Op2
P4_rw:4003C188 MOV R1, R1,LSL#16 ; Rd = Op2
P4_rw:4003C18C MOVS R1, R1,LSR#16 ; Len
P4_rw:4003C190 MOVS R0, R4 ; __int16 *
P4_rw:4003C194 BL NewBoardVersionRecodeFind ; Branch with Link
P4_rw:4003C198 MOVS R8, R0 ; Rd = Op2
P4_rw:4003C19C MOVS R0, R7 ; Rd = Op2
P4_rw:4003C1A0 MOV R0, R0,LSL#16 ; Rd = Op2
P4_rw:4003C1A4 MOVS R0, R0,LSR#16 ; Rd = Op2
P4_rw:4003C1A8 MOVS R0, R0,LSL#1 ; Rd = Op2
P4_rw:4003C1AC ADDS R0, R0, R4 ; Rd = Op1 + Op2
P4_rw:4003C1B0 LDRH R2, [R0,#2] ; FindCode
P4_rw:4003C1B4 MOVS R1, R5 ; Rd = Op2
P4_rw:4003C1B8 MOV R1, R1,LSL#16 ; Rd = Op2
P4_rw:4003C1BC MOVS R1, R1,LSR#16 ; Len
P4_rw:4003C1C0 MOVS R0, R4 ; __int16 *
P4_rw:4003C1C4 BL NewBoardVersionRecodeFind ; Branch with Link
P4_rw:4003C1C8 MOV R8, R8,LSL#16 ; Rd = Op2
P4_rw:4003C1CC MOVS R8, R8,LSR#16 ; Rd = Op2
P4_rw:4003C1D0 CMP R8, R0 ; Set cond. codes on Op1 - Op2
P4_rw:4003C1D4 BCS loc_4003C1F0 ; Branch
P4_rw:4003C1D8 MOVS R0, R7 ; Rd = Op2
P4_rw:4003C1DC MOV R0, R0,LSL#16 ; Rd = Op2
P4_rw:4003C1E0 MOVS R0, R0,LSR#16 ; Rd = Op2
P4_rw:4003C1E4 MOVS R0, R0,LSL#1 ; Rd = Op2
P4_rw:4003C1E8 ADDS R0, R0, R4 ; Rd = Op1 + Op2
P4_rw:4003C1EC LDRH R6, [R0,#2] ; Load from Memory
P4_rw:4003C1F0
P4_rw:4003C1F0 loc_4003C1F0 ; CODE XREF: NewBoardVersionAnalyser+84j
P4_rw:4003C1F0 ADDS R7, R7, #1 ; Rd = Op1 + Op2
P4_rw:4003C1F4
P4_rw:4003C1F4 loc_4003C1F4 ; CODE XREF: NewBoardVersionAnalyser+1Cj
P4_rw:4003C1F4 MOV R7, R7,LSL#16 ; Rd = Op2
P4_rw:4003C1F8 MOVS R7, R7,LSR#16 ; Rd = Op2
P4_rw:4003C1FC MOV R5, R5,LSL#16 ; Rd = Op2
P4_rw:4003C200 MOVS R5, R5,LSR#16 ; Rd = Op2
P4_rw:4003C204 CMP R7, R5 ; Set cond. codes on Op1 - Op2
P4_rw:4003C208 BCC loc_4003C170 ; Branch
P4_rw:4003C20C MOVS R0, R6 ; Rd = Op2
P4_rw:4003C210 MOV R0, R0,LSL#16 ; Rd = Op2
P4_rw:4003C214 MOVS R0, R0,LSR#16 ; Rd = Op2
P4_rw:4003C218 LDMFD SP!, {R4-R8,PC} ; Load Block from Memory
P4_rw:4003C218 ; End of function NewBoardVersionAnalyser
It's possible that this should help with hang-ups during the boot phase.
- A noticeably changed function that loads data from the FPGA to the CPU.
- In one firmware update function, the checksum check is removed.
Perhaps there are still some small (in terms of code size) changes.
Address offset
;New Old delta
4003B558 4003B558 0
4003B698 4003B698 0 (changed func board_version)
4003B83C 4003B794 A8
4003B864 4003B7BC A8
4003BC80 4003BBD8 A8
4003C024 4003BF7C A8 (2 dword after)
4003C068 4003BFB8 B0
; New function
4003C0EC -
4003C150 -
4003C21C 4003C02C 1F0 (3->9 dword after)
4003C54C 4003C374 1D8 (2->3 dword after)
4003C618 4003C43C 1DC (no dword after)
4003C984 4003C7AC 1D8
4003CA2C 4003C854 1D8 (1 dword after)
4003CB44 4003C968 1DC (3->2 dword after)
4003CBA4 4003C9CC 1D8
4003C54C 4003C374 1D8
4003CA2C 4003C854 1D8
4003CE9C 4003CCC4 1D8 (changed read wave func + 1 dword after)
4003D8A0 4003D5D8 2C8
4003D9E0 4003D718 2C8 (3 dword after)
4003DA44 4003D770 2D4 (1 dword after)
4003DAC8 4003D7F8 2D0 (2->1 dword after)
4003DAEC 4003D820 2CC
4003FA3C 4003F778 2C4
40042F38 40042C74 2C4
40055CBC 400559F8 2C4
4005B3EC 4005B128 2C4
40063504 40063240 2C4
40063790 400634CC 2C4
40063848 40063584 2C4
40064164 40063EA0 2C4 (No CRC Check now)
40064330 40064090 2A0
40064B28 40064888 2A0
40066F0C 40066C6C 2A0
400682EC 4006804C 2A0
400B44F0 400B4250 2A0
400BB0F4 400BAE54 2A0
;
400F5A24 400F5788 29C
400F65B0 400F6314 29C
400F6940 400F66A4 29C
;
40149784 401494F4 290
402386B4 40238424 290
402523A4 40252114 290
;
402A4F34 402A4CB4 280
4031AFE8 4031AD68 280
40329D88 40329B08 280
4032A282 4032A002 280
4032A367 4032A0E7 280 (Reloc start)
;RAM
406BAB90 406BAB90 0 (Clear Area)
4075AEF8 4075AEF8
-
The complete E-Safenet key is:
0xD0, 0xCA, 0x19, 0x8E, 0x9C, 0x92, 0x1E, 0xE9, 0x72, 0xC5, 0x57, 0x1F, 0x54, 0x49, 0x1A, 0xD0,
0x04, 0xA3, 0x55, 0x21, 0xE7, 0xD9, 0xC7, 0xA0, 0x4C, 0x91, 0x5C, 0xDC, 0x6C, 0x27, 0xF3, 0xBA,
0x21, 0x02, 0x89, 0xB6, 0xD8, 0x61, 0x2E, 0x1D, 0x93, 0xC8, 0xAF, 0x3C, 0x59, 0x7D, 0x91, 0x60,
0x9F, 0xBE, 0xA9, 0x6B, 0xF5, 0xE4, 0x68, 0xFA, 0xDC, 0x47, 0xDA, 0x1C, 0x35, 0xED, 0x63, 0x30,
0x06, 0xCD, 0x18, 0x3F, 0xAB, 0xA2, 0x51, 0xC0, 0xDE, 0x89, 0x3D, 0x47, 0xCF, 0x16, 0xB1, 0xA8,
0x4F, 0x2E, 0x28, 0xE2, 0x09, 0x8F, 0x78, 0x60, 0x77, 0x81, 0x6B, 0x13, 0xF9, 0x0D, 0x70, 0xDA,
0x5B, 0xC1, 0xBF, 0x7B, 0xC8, 0xEF, 0x11, 0xAF, 0x8C, 0x1C, 0xE1, 0x9F, 0xA0, 0x0F, 0x2A, 0x76,
0x8B, 0xB9, 0x97, 0x7D, 0xFB, 0x12, 0xC5, 0x7C, 0x7E, 0xBE, 0x54, 0x22, 0xC7, 0xD8, 0xEF, 0x62,
0x27, 0xFA, 0x79, 0x41, 0x87, 0x85, 0xC4, 0xC2, 0x70, 0x5F, 0x15, 0x1E, 0xE8, 0x02, 0x13, 0x3D,
0xD5, 0x3F, 0x78, 0x17, 0x61, 0xEC, 0xF3, 0x91, 0x0C, 0xDB, 0xE3, 0x48, 0x13, 0x9E, 0x8B, 0xA5,
0x74, 0x47, 0x1A, 0xFD, 0xB3, 0x5A, 0x52, 0x20, 0x2A, 0x9E, 0x29, 0xB6, 0x9B, 0xC2, 0x84, 0xD7,
0x16, 0x98, 0x5D, 0x5F, 0xEE, 0x65, 0x33, 0x2E, 0x2B, 0xD5, 0xC8, 0x4E, 0x8F, 0x67, 0x27, 0x7E,
0xB2, 0x9C, 0xE6, 0xDA, 0x61, 0x75, 0x17, 0x66, 0xE5, 0x01, 0x74, 0xE2, 0xFE, 0x8E, 0x7A, 0x0F,
0xD1, 0x4A, 0x6A, 0x9D, 0x69, 0x87, 0x3E, 0x39, 0x21, 0x0C, 0x81, 0x0E, 0x8F, 0x17, 0x78, 0xE4,
0xC7, 0x67, 0xB8, 0x75, 0x34, 0x8F, 0x00, 0x3E, 0x72, 0x3A, 0x3F, 0x16, 0x1E, 0x47, 0x8A, 0xF6,
0x04, 0xC9, 0x01, 0x76, 0xD9, 0x61, 0x8D, 0x28, 0x07, 0xC9, 0xE7, 0x09, 0x49, 0xB2, 0xEA, 0xBF,
0x14, 0x2E, 0xAD, 0x1D, 0x02, 0xA1, 0x2E, 0xD9, 0x0F, 0x46, 0xE2, 0xE6, 0xCE, 0xD2, 0x84, 0xEB,
0xB3, 0x41, 0x5D, 0xFB, 0xF0, 0x2F, 0xEF, 0x45, 0x01, 0xE4, 0x34, 0x69, 0x35, 0xD4, 0x91, 0x1D,
0xF1, 0x26, 0x39, 0xA9, 0x6E, 0xAF, 0xC7, 0xCA, 0xCC, 0xEC, 0xB7, 0x3A, 0x18, 0x1E, 0xA9, 0xCD,
0xCE, 0x58, 0x28, 0xEC, 0xDD, 0x58, 0x26, 0x2C, 0x8F, 0x65, 0x63, 0x36, 0x63, 0xA4, 0x2B, 0x7D,
0x89, 0x84, 0xD6, 0x15, 0xE6, 0x41, 0x44, 0x8A, 0x23, 0x69, 0x49, 0xE1, 0x3B, 0x60, 0x85, 0x52,
0xF9, 0x41, 0x65, 0x26, 0x7C, 0x10, 0x79, 0x69, 0xAA, 0xFA, 0xCE, 0x0D, 0x21, 0x5C, 0xE6, 0x44,
0x26, 0x37, 0x6C, 0x7A, 0x93, 0xB1, 0x1E, 0x81, 0xA0, 0x32, 0x7B, 0xA7, 0xC3, 0x2F, 0x0C, 0xB4,
0x9F, 0x01, 0x57, 0xA5, 0x3B, 0x3D, 0xE1, 0x44, 0x17, 0xB1, 0x58, 0xA5, 0x8D, 0xBF, 0xAF, 0xB5,
0x0B, 0xC5, 0x3D, 0x8C, 0x65, 0xA2, 0x97, 0xA0, 0x56, 0x60, 0x28, 0x06, 0x70, 0xDC, 0xE8, 0x25,
0x82, 0x1E, 0xD4, 0x61, 0xAC, 0x31, 0x28, 0x96, 0x42, 0x6F, 0x52, 0x6E, 0x0A, 0x23, 0x33, 0xEC,
0x28, 0xC3, 0x75, 0x44, 0x53, 0xED, 0xD3, 0x85, 0x69, 0x3B, 0xEB, 0xC3, 0x4D, 0x38, 0xA1, 0xBB,
0x80, 0xD7, 0xCD, 0x51, 0xF2, 0x15, 0xAB, 0x29, 0x0B, 0x22, 0xEF, 0xCE, 0xED, 0xF8, 0xC1, 0xF7,
0xFC, 0x56, 0xEA, 0x80, 0x73, 0x1A, 0x18, 0xFD, 0x5D, 0x37, 0x6F, 0x38, 0x70, 0xAB, 0x64, 0xC5,
0x35, 0xBD, 0x52, 0xD5, 0xEF, 0xFA, 0xB7, 0x43, 0xFF, 0xA8, 0x7A, 0x75, 0x59, 0x38, 0x87, 0x53,
0xB6, 0x50, 0xD8, 0xEB, 0xB9, 0x0E, 0xA3, 0x6B, 0x70, 0x58, 0x47, 0xEB, 0x42, 0xFE, 0x05, 0xBC,
0x1F, 0xA3, 0xE8, 0x75, 0x61, 0x96, 0xC4, 0xC1, 0x68, 0x22, 0x60, 0xA5, 0xB3, 0x7B, 0x3F, 0x8F
The last part of the release notes is:
easure
- Fixed the bug of information display
[History]
-------------
v00.04.04.01.01 2016/09/14
- Supported the multi-inteface of LXI
- Fixed bugs about Measure
v00.04.04.00.07 2016/07/19
- Added the full-screen display in the XY mode
- Modified the Trace data of average sample mode
- Fixed the bug of system halted for wve persistance in the Zoom mode
- Fixed bugs about Measure
v00.04.03.02.03 2015/10/20
- Added commands concerning the type and format of the image
- Added four measurement items (+Pulses, -Pulses, +Edges, -Edges) and
relate commands
- Added commands concerning the digital filter
- Added more information to the last setting
- Fixed option installation
- Fixed Intg operation
v00.04.03.01.05 2015/06/16
- Added French in system language
- Added the mutual communication with DG4000 Series
- Added the digital filter
- Supported using memory data to carry out FFT operation
- Supported invert and format setting when reading a image remotely
- Fixed bugs when the dta of the digital channel is saved in the CSV
format
v00.04.03.00.01 2015/05/05
- Added DS1104Z Plus and DS1074Z Plus
- Fixed pass/fail test
- Fixed FFT operation
v00.04.02.04.07 2014/12/31
- Fixed triggering fuction
- Fixed storage function
- Fixed bugs of jitter in the signal under the AC or low-frequency
coupling
v00.04.02.03.00 2014/10/21
- Added commands concerning remote reading and download of pass/fail test
rules
- Improved the command set for decoding and waveform recording
- Fixed bugs in RS232 decoding
v00.04.01.02.00 2014/07/28
- Added traditional Chinese language for the measurement menu
- Optimized the event table display
- Pressed and held [Measure] to remove all the measurement items
- Added hardware version number to the displayed system information
- Fixed bugs in storage function
- Fixed bugs in the Undo operation for AUTO
- Fixed bugs i signal source function
v00.04.00.00.00 2014/03/18
- Added remote reading of LA waveform data
- Added commands concerning the measurement of MATH waveform
- Optimized the prompt message of LA probe calibration
- Fixed bugsin triggering function
v00.02.03.05.00 2014/01/27
- Added the command set for the keypad
- Added multiple system languages
- Optimize the prompt message of LA probe calibration
- Fixed bugs in frequency counter
- Fixedbugs in storage
- Fixed the crash problem when formatting U disk in NTFS format
v00.02.01.01.00 2013/10/31
- Added measurement history function
- Added the setting for measurement range
- Adjusted the priority order of the emote interface
- Realized the seamless integration of digital oscilloscope and the signal
generator
- Optimized trigger state display
- Fixed bugs in horizontal scale
v00.02.00.01.00 2013/09/02
- Optimized the brighness of waveform display
- Optimized the waiting time for the slow sweep mode
v00.01.00.16.09 2013/08/14
- Supported the remote access to memory data
v00.01.00.13.09 2013/ 07/ 25
- Added the export function of deep memory wavform data
- Added the delay calibration function for the channel
- Optimized the persistence time of waveform display
- Fixed bugs in slow sweep
v00.01.00.12.08 2013/07/10
- Optimized the USB Device interface communication
- Fixed bugs in print function
- Modified the abnormal trigger level line after the AUTO operation
v00.01.00.03.00 2013/05/21
- Fixed bugs for the expiration of the trial options
v00.01.00.02.00 2013/05/19
- Added the isplay interface of the installed option
v00.01.00.00.05 2013/05/19
- Released the first edition
Just have to decompress the 1st 512 bytes (LZO). Now the python guys can easily do it.
-
The complete E-Safenet key is:
0xD0, 0xCA, 0x19, 0x8E, 0x9C, 0x92, 0x1E, 0xE9, 0x72, 0xC5, 0x57, 0x1F, 0x54, 0x49, 0x1A, 0xD0,
0x04, 0xA3, 0x55, 0x21, 0xE7, 0xD9, 0xC7, 0xA0, 0x4C, 0x91, 0x5C, 0xDC, 0x6C, 0x27, 0xF3, 0xBA,
0x21, 0x02, 0x89, 0xB6, 0xD8, 0x61, 0x2E, 0x1D, 0x93, 0xC8, 0xAF, 0x3C, 0x59, 0x7D, 0x91, 0x60,
0x9F, 0xBE, 0xA9, 0x6B, 0xF5, 0xE4, 0x68, 0xFA, 0xDC, 0x47, 0xDA, 0x1C, 0x35, 0xED, 0x63, 0x30,
0x06, 0xCD, 0x18, 0x3F, 0xAB, 0xA2, 0x51, 0xC0, 0xDE, 0x89, 0x3D, 0x47, 0xCF, 0x16, 0xB1, 0xA8,
0x4F, 0x2E, 0x28, 0xE2, 0x09, 0x8F, 0x78, 0x60, 0x77, 0x81, 0x6B, 0x13, 0xF9, 0x0D, 0x70, 0xDA,
0x5B, 0xC1, 0xBF, 0x7B, 0xC8, 0xEF, 0x11, 0xAF, 0x8C, 0x1C, 0xE1, 0x9F, 0xA0, 0x0F, 0x2A, 0x76,
0x8B, 0xB9, 0x97, 0x7D, 0xFB, 0x12, 0xC5, 0x7C, 0x7E, 0xBE, 0x54, 0x22, 0xC7, 0xD8, 0xEF, 0x62,
0x27, 0xFA, 0x79, 0x41, 0x87, 0x85, 0xC4, 0xC2, 0x70, 0x5F, 0x15, 0x1E, 0xE8, 0x02, 0x13, 0x3D,
0xD5, 0x3F, 0x78, 0x17, 0x61, 0xEC, 0xF3, 0x91, 0x0C, 0xDB, 0xE3, 0x48, 0x13, 0x9E, 0x8B, 0xA5,
0x74, 0x47, 0x1A, 0xFD, 0xB3, 0x5A, 0x52, 0x20, 0x2A, 0x9E, 0x29, 0xB6, 0x9B, 0xC2, 0x84, 0xD7,
0x16, 0x98, 0x5D, 0x5F, 0xEE, 0x65, 0x33, 0x2E, 0x2B, 0xD5, 0xC8, 0x4E, 0x8F, 0x67, 0x27, 0x7E,
0xB2, 0x9C, 0xE6, 0xDA, 0x61, 0x75, 0x17, 0x66, 0xE5, 0x01, 0x74, 0xE2, 0xFE, 0x8E, 0x7A, 0x0F,
0xD1, 0x4A, 0x6A, 0x9D, 0x69, 0x87, 0x3E, 0x39, 0x21, 0x0C, 0x81, 0x0E, 0x8F, 0x17, 0x78, 0xE4,
0xC7, 0x67, 0xB8, 0x75, 0x34, 0x8F, 0x00, 0x3E, 0x72, 0x3A, 0x3F, 0x16, 0x1E, 0x47, 0x8A, 0xF6,
0x04, 0xC9, 0x01, 0x76, 0xD9, 0x61, 0x8D, 0x28, 0x07, 0xC9, 0xE7, 0x09, 0x49, 0xB2, 0xEA, 0xBF,
0x14, 0x2E, 0xAD, 0x1D, 0x02, 0xA1, 0x2E, 0xD9, 0x0F, 0x46, 0xE2, 0xE6, 0xCE, 0xD2, 0x84, 0xEB,
0xB3, 0x41, 0x5D, 0xFB, 0xF0, 0x2F, 0xEF, 0x45, 0x01, 0xE4, 0x34, 0x69, 0x35, 0xD4, 0x91, 0x1D,
0xF1, 0x26, 0x39, 0xA9, 0x6E, 0xAF, 0xC7, 0xCA, 0xCC, 0xEC, 0xB7, 0x3A, 0x18, 0x1E, 0xA9, 0xCD,
0xCE, 0x58, 0x28, 0xEC, 0xDD, 0x58, 0x26, 0x2C, 0x8F, 0x65, 0x63, 0x36, 0x63, 0xA4, 0x2B, 0x7D,
0x89, 0x84, 0xD6, 0x15, 0xE6, 0x41, 0x44, 0x8A, 0x23, 0x69, 0x49, 0xE1, 0x3B, 0x60, 0x85, 0x52,
0xF9, 0x41, 0x65, 0x26, 0x7C, 0x10, 0x79, 0x69, 0xAA, 0xFA, 0xCE, 0x0D, 0x21, 0x5C, 0xE6, 0x44,
0x26, 0x37, 0x6C, 0x7A, 0x93, 0xB1, 0x1E, 0x81, 0xA0, 0x32, 0x7B, 0xA7, 0xC3, 0x2F, 0x0C, 0xB4,
0x9F, 0x01, 0x57, 0xA5, 0x3B, 0x3D, 0xE1, 0x44, 0x17, 0xB1, 0x58, 0xA5, 0x8D, 0xBF, 0xAF, 0xB5,
0x0B, 0xC5, 0x3D, 0x8C, 0x65, 0xA2, 0x97, 0xA0, 0x56, 0x60, 0x28, 0x06, 0x70, 0xDC, 0xE8, 0x25,
0x82, 0x1E, 0xD4, 0x61, 0xAC, 0x31, 0x28, 0x96, 0x42, 0x6F, 0x52, 0x6E, 0x0A, 0x23, 0x33, 0xEC,
0x28, 0xC3, 0x75, 0x44, 0x53, 0xED, 0xD3, 0x85, 0x69, 0x3B, 0xEB, 0xC3, 0x4D, 0x38, 0xA1, 0xBB,
0x80, 0xD7, 0xCD, 0x51, 0xF2, 0x15, 0xAB, 0x29, 0x0B, 0x22, 0xEF, 0xCE, 0xED, 0xF8, 0xC1, 0xF7,
0xFC, 0x56, 0xEA, 0x80, 0x73, 0x1A, 0x18, 0xFD, 0x5D, 0x37, 0x6F, 0x38, 0x70, 0xAB, 0x64, 0xC5,
0x35, 0xBD, 0x52, 0xD5, 0xEF, 0xFA, 0xB7, 0x43, 0xFF, 0xA8, 0x7A, 0x75, 0x59, 0x38, 0x87, 0x53,
0xB6, 0x50, 0xD8, 0xEB, 0xB9, 0x0E, 0xA3, 0x6B, 0x70, 0x58, 0x47, 0xEB, 0x42, 0xFE, 0x05, 0xBC,
0x1F, 0xA3, 0xE8, 0x75, 0x61, 0x96, 0xC4, 0xC1, 0x68, 0x22, 0x60, 0xA5, 0xB3, 0x7B, 0x3F, 0x8F
The last part of the release notes is:
easure
- Fixed the bug of information display
Just have to decompress the 1st 512 bytes (LZO). Now the python guys can easily do it.
Noob question, so the new encryption introduced is now cracked wide open now ?
-
tv84 - great work!
How did you do it!?!
-
Noob question, so the new encryption introduced is now cracked wide open now ?
Yes, but this was used only in the release notes. Nothing to do with the app compiled code. No change there.
Maybe the source code is also encrypted with this key... :)
-
tv84 - great work!
How did you do it!?!
As Fungus was saying and I confirmed, the UTF-16 served as a confirmation of the method. Then, I just took the last 512 bytes of the previous release notes and XORed them with the last 512 bytes of this new release notes. Piece of cake.
BTW, without decompressing the LZO, the beginning of the release notes says something like:
ÿþ
[Supported Model] ¤
All the?
SO/DS10?Z Series Digita?Osci? o?opÌ
[La?st Revision?
¼¤2018/04/28l[UpdÜ }Ctnts]?- m
(3n5d%6Dl¬- FixÔ-ç*lo?%t bug of lxi-web?¤ t64* average m
So it seems it fixes a bug in the LXI-Web.
-
novice question, the error of pluses, I have it already corrected by a Konnor file, but I can not find it RNAGe RNAG
-
tv84.
Wow, really nice work!
Any chance you could decrypt the new release note for the DS2000A firmware as well?
http://www.rigol.com/File/ProductSoftWare/20180509/DS2000(DSP)update.rar (http://www.rigol.com/File/ProductSoftWare/20180509/DS2000(DSP)update.rar)
-
Here are fully decrypted release notes.
Enjoy!
-
tv84 Many thanks for the decryption.
John
-
So the used 'key' doesn't seem to be any password/passphrase or other readable string, but rather a cryptographic nonce (except it has been used at least twice!)
-
tv84 - great work!
How did you do it!?!
All the information is in this thread, starting here (https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/msg1531787/#msg1531787).
Bottom line: It wasn't exactly industrial strength encryption.
-
Here are fully decrypted release notes.
Hah! Good work.
The release notes for v00.04.04.03.02 have vanished from the file, I wonder why?
I also wonder why anybody would use such a weird/rubbish encryption? A zip file with password would be much easier/universal/uncrackable.
So the used 'key' doesn't seem to be any password/passphrase or other readable string, but rather a cryptographic nonce (except it has been used at least twice!)
Yep. This means you have to pass a key file around with the encrypted file, making it almost pointless.
(If you can intercept the encrypted file you can probably intercept the key file as well)
I'm guessing that encryption was done by a manager, not an engineer.
I superficially looked update.
Result:
- No new functions, only bugfixed
- function, that determines the version of the board, is complete rewritten.
Nothing major fixed or changed, probably not worth installing.
- No any changes on resoures (help, menu, images, etc)
But ... somebody said "Pluses" was changed to "Pulses". :o
-
I'm guessing that encryption was done by a manager, not an engineer.
I'm guessing that all Rigol encryption always was done by a manager, not an engineer. ;D
Nothing major fixed or changed, probably not worth installing.
And, in addition, release note does not fully correspond to the real changes.
I will further analyze the firmware, but I will not use it to my device yet. I will wait revoked from other enthusiasts. ;)
But ... somebody said "Pluses" was changed to "Pulses".
1) String Pluses/Pulses - not in resources.
2) i see in firmware:
P4_rw:401FA8C4 aDuty_0 DCB "+Duty",0
P4_rw:401FA8CA DCB 0
P4_rw:401FA8CB DCB 0
P4_rw:401FA8CC aDuty DCB "-Duty",0
P4_rw:401FA8D2 DCB 0
P4_rw:401FA8D3 DCB 0
P4_rw:401FA8D4 aPluses DCB "+Pluses",0
P4_rw:401FA8DC aPluses_0 DCB "-Pluses",0
P4_rw:401FA8E4 aEdges DCB "+Edges",0
P4_rw:401FA8EB DCB 0
P4_rw:401FA8EC aEdges_0 DCB "-Edges",0
-
The release notes for v00.04.04.03.02 have vanished from the file, I wonder why?
I also wonder why anybody would use such a weird/rubbish encryption? A zip file with password would be much easier/universal/uncrackable.
I guess that's another sign of how these release notes were released. In a hurry and without proper care.
They forgot to add the previous notes to the history and forgot to decrypt the file.
I would not be amazed if this is the key that they use in their development tree since that's one of the main uses of E-Safenet.
One thing is certain: encrypting public release notes is just a dumb idea or a top-secret beyond my understanding!
-
Something else has been improved. My unit had a slight offset between channels and channel one was ever so slightly noisy when engaging the 20 MHz filter. After the update, even prior to recalibration that has improved a lot.
-
Something else has been improved. My unit had a slight offset between channels and channel one was ever so slightly noisy when engaging the 20 MHz filter. After the update, even prior to recalibration that has improved a lot.
When it was brand new, out of the box, all the traces were on the same zero ground level.
After the first recalibration, I remember being somehow disappointed about the traces not being on the same zero line. Since then, I never seen that factory default zero line, with all traces on top on each other, and perfectly aligned.
Are you sure it is not just a lucky recalibration? If you recalibrate the scope again, would you still obtain the same result? How long did you let the scope to heat up before recalibration, please?
-
I'm guessing that encryption was done by a manager, not an engineer.
I'm guessing that all Rigol encryption always was done by a manager, not an engineer. ;D
Nothing major fixed or changed, probably not worth installing.
And, in addition, release note does not fully correspond to the real changes.
I will further analyze the firmware, but I will not use it to my device yet. I will wait revoked from other enthusiasts. ;)
But ... somebody said "Pluses" was changed to "Pulses".
1) String Pluses/Pulses - not in resources.
2) i see in firmware:
P4_rw:401FA8C4 aDuty_0 DCB "+Duty",0
P4_rw:401FA8CA DCB 0
P4_rw:401FA8CB DCB 0
P4_rw:401FA8CC aDuty DCB "-Duty",0
P4_rw:401FA8D2 DCB 0
P4_rw:401FA8D3 DCB 0
P4_rw:401FA8D4 aPluses DCB "+Pluses",0
P4_rw:401FA8DC aPluses_0 DCB "-Pluses",0
P4_rw:401FA8E4 aEdges DCB "+Edges",0
P4_rw:401FA8EB DCB 0
P4_rw:401FA8EC aEdges_0 DCB "-Edges",0
Konnor, when you correct this version, the error "Pluses" for "pulses" will you upload them ??? ;D ;D ;D
-
I also wonder why anybody would use such a weird/rubbish encryption? A zip file with password would be much easier/universal/uncrackable.
Googling for E-Safenet returned, among e.g. pdf slides for an IETF conference in '92 encrypted with this algorithm,
also a message from an old thread in this very forum:
https://www.eevblog.com/forum/testgear/the-siglent-sdg2042x-thread/msg917775/#msg917775 (https://www.eevblog.com/forum/testgear/the-siglent-sdg2042x-thread/msg917775/#msg917775)
So Siglent also uses it. :-+
As the academic paper was explaining, it must be indeed quite extensively used in China.
-
When it was brand new, out of the box, all the traces were on the same zero ground level.
After the first recalibration, I remember being somehow disappointed about the traces not being on the same zero line. Since then, I never seen that factory default zero line, with all traces on top on each other, and perfectly aligned.
Are you sure it is not just a lucky recalibration? If you recalibrate the scope again, would you still obtain the same result? How long did you let the scope to heat up before recalibration, please?
After updating the firmware I power cycled it and checked out of curiosity. Traces were on the right spot. The scope had been powered for an hour maybe, I don't remember.
I will power it on again, let it be for an hour or so and recallibrate.
-
When it was brand new, out of the box, all the traces were on the same zero ground level.
After the first recalibration, I remember being somehow disappointed about the traces not being on the same zero line. Since then, I never seen that factory default zero line, with all traces on top on each other, and perfectly aligned.
Are you sure it is not just a lucky recalibration? If you recalibrate the scope again, would you still obtain the same result? How long did you let the scope to heat up before recalibration, please?
I have recalibrated again.
Vertical scale is 10 mV/div because the channels are configured for 10x. With nothing connected to the inputs it's actually 1 mV/div. Averaging so that any offset is more visible.
Before the latest firmware update I had some offset and the 20 MHz filter for channel 1 (and it only affected channel 1) was a bit strange. Now it works as it should.
Curiously if I enable just channels 1 and 2 there is a very slight offset affecting channel 2. But it's certainly better than it was in the past.
-
Thank you for testing again the recalibration.
With my current firmware 00.04.04.03.02, there is a very slight change in offset (2 channels active vs 4 channels), too.
-
The encrypted release notes must've been a mistake. It's rather unnecessary since the contents have always been rather cryptic already. :-DD
Now, if the release notes this time had detailed information about the changes made, I might consider it to have been intentional. Nice job on the hacking.
The "pluses" are a shame...still. :palm: :horse:
Like others have indicated, I think I'll wait on updating mine. From what little information there is in the release notes, I don't see anything worth updating for and risking it somehow interfering with the community firmware efforts.
-
I can confirm that after the update (and an auto calibration -- needed three attempts until it passed), the traces are exactly centered on the trace markers. Have never seen that before on my DS1000Z since I purchased it some four years ago. They were always riding slightly above the markers. Seems like Rigol finally took care of one of the "minor annoyances" that could still make a difference...
-
I can confirm that after the update (and an auto calibration -- needed three attempts until it passed), the traces are exactly centered on the trace markers. Have never seen that before on my DS1000Z since I purchased it some four years ago. They were always riding slightly above the markers. Seems like Rigol finally took care of one of the "minor annoyances" that could still make a difference...
Same here, just upgraded and re-calibrated and immediately noticed the perfect alignment of the traces, my first channel always had a bit of offset in all ranges no matter how many times I ran the calibration.
Still, the "Pluses" are very irritating... (I had to write a report with some measurement screenshots and fixed the pluses in photoshop :palm:) It is really an inside joke? I'm starting to believe it is.
-
Like others have indicated, I think I'll wait on updating mine. From what little information there is in the release notes, I don't see anything worth updating for and risking it somehow interfering with the community firmware efforts.
Just my 50 cents:
- The update is very low risk and, as some have already informed, it seems to bring visible improvements.
- The fact that the update GEL doesn't (explicitly) change the bootloader, everyone can still revert to a previous firmware version afterwards.
- Only if the app did some (hidden) changes to the bootloader block, that could pose a risk. But, taking into account the update process/validations used by Rigol in this scope, making such a on-the-fly change would be a nuts idea and not worth the risk and cost of development at this stage.
-
@tv84: OK, I'll buy your 50 cents. I do like the possibility of fixing the zero offsets. Thanks for your input, especially regarding the GEL and bootloader.
-
I ran a scan against the new firmware, using function signatures which we developed while exploring the GEL protection system.
tv84 and janekivi will recognize this stuff:
$ grep -i footer SparrowAPP.4435.matches.txt
f sign.bytes.sym.processFooter_0 500 @ 0x400644a0
f sign.bytes.sym.loadFooter_0 192 @ 0x40064770
f sign.bytes.sym.footer_magic_0 448 @ 0x400abfbc
The protection for this firmware appears to be identical to previous releases.
-
@tv84: OK, I'll buy your 50 cents. I do like the possibility of fixing the zero offsets. Thanks for your input, especially regarding the GEL and bootloader.
While you all wait for konnor to update his new plugin version with the "pluses" corrected, I'll ask janekivi to correct them in the official 00.04.04.03.05 version if that's really important.
-
@tv84: OK, I'll buy your 50 cents. I do like the possibility of fixing the zero offsets. Thanks for your input, especially regarding the GEL and bootloader.
While you all wait for konnor to update his new plugin version with the "pluses" corrected, I'll ask janekivi to correct them in the official 00.04.04.03.05 version if that's really important.
The misspelling is really pissing me off. I guess we all appreciate if you guys make a fixed firmware.
-
@tv84: OK, I'll buy your 50 cents. I do like the possibility of fixing the zero offsets. Thanks for your input, especially regarding the GEL and bootloader.
While you all wait for konnor to update his new plugin version with the "pluses" corrected, I'll ask janekivi to correct them in the official 00.04.04.03.05 version if that's really important.
The misspelling is really pissing me off. I guess we all appreciate if you guys make a fixed firmware.
or the Konnor modification
-
I can make this happen.
Did only Pluses.
DS1000Z_00_04_04_03_05.zip (http://s000.tinyupload.com/index.php?file_id=84621285266561797736)
-
It has just been placed unencoded:
[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date] 2018/04/28
[Updated Contents]
--------------------
v00.04.04.03.05 2018/04/28
- Fixed the login bug of lxi-web
- Fixed the bug of average measure
- Fixed the bug of information display
[History]
-------------
v00.04.04.01.01 2016/09/14
- Supported the multi-inteface of LXI
- Fixed bugs about Measure
v00.04.04.00.07 2016/07/19
- Added the full-screen display in the XY mode
- Modified the Trace data of average sample mode
- Fixed the bug of system halted for wave persistance in the Zoom mode
- Fixed bugs about Measure
v00.04.03.02.03 2015/10/20
- Added commands concerning the type and format of the image
- Added four measurement items (+Pulses, -Pulses, +Edges, -Edges) and
related commands
- Added commands concerning the digital filter
- Added more information to the last setting
.............
-
@tv84: OK, I'll buy your 50 cents. I do like the possibility of fixing the zero offsets. Thanks for your input, especially regarding the GEL and bootloader.
While you all wait for konnor to update his new plugin version with the "pluses" corrected, I'll ask janekivi to correct them in the official 00.04.04.03.05 version if that's really important.
I can make this happen.
Did only Pluses.
DS1000Z_00_04_04_03_05.zip (http://s000.tinyupload.com/index.php?file_id=03335538177579759995)
Thank you, both. :-+
It still makes me laugh from time to time, but better to be rid of the misspelling.
-
thanks janekivi ;D ;D
-
And, curiously, they still haven't put it on the international web page (int.rigol.com).
-
I can confirm that after the update (and an auto calibration -- needed three attempts until it passed), the traces are exactly centered on the trace markers. Have never seen that before on my DS1000Z since I purchased it some four years ago. They were always riding slightly above the markers. Seems like Rigol finally took care of one of the "minor annoyances" that could still make a difference...
I had the same issue and also noticed the better trace alignment after the update but there are still strange things going on with the alignment. Depending on which of the 4 channels are activated, they again jump slightly above the trace marker. When all channels are active they are all aligned perfectly. When I switch them on separately at least channel 2 is again slightly above the trace marker but jumps back to zero when I also switch on channel 3.
Strange.... anyone else?
-
It has just been placed unencoded:
And looking at the timestamps, I assume they haven't yet changed the file for the DS2000A
(https://i.imgur.com/5EPRotK.png)
-
I can confirm that after the update (and an auto calibration -- needed three attempts until it passed), the traces are exactly centered on the trace markers. Have never seen that before on my DS1000Z since I purchased it some four years ago. They were always riding slightly above the markers. Seems like Rigol finally took care of one of the "minor annoyances" that could still make a difference...
I had the same issue and also noticed the better trace alignment after the update but there are still strange things going on with the alignment. Depending on which of the 4 channels are activated, they again jump slightly above the trace marker. When all channels are active they are all aligned perfectly. When I switch them on separately at least channel 2 is again slightly above the trace marker but jumps back to zero when I also switch on channel 3.
Strange.... anyone else?
Same here with channel 2. Also, results are much better if you leave the scope powered for half an hour or so. I guess they have been tweaking some thermal compensation.
-
I ran the update today and then calibrated and now for the first time ever when I turn on all four channels the traces are completely aligned on top of one another with no signal input. I just see a single line. Nice.
-
I ran the update today and then calibrated and now for the first time ever when I turn on all four channels the traces are completely aligned on top of one another with no signal input. I just see a single line. Nice.
Are the traces aligned to the index of the channel anywhere on the display vertically? Meaning, if you move them up or down do hey stay aligned?
-
No, it tends to be misaligned. :-[
-
I ran the update today and then calibrated and now for the first time ever when I turn on all four channels the traces are completely aligned on top of one another with no signal input. I just see a single line. Nice.
Are the traces aligned to the index of the channel anywhere on the display vertically? Meaning, if you move them up or down do hey stay aligned?
I only looked at alignment of all four traces at the zero line with no inputs connected. I am not sure what you mean by moving the traces up or down vertically. Are you talking about alignment between the channels with each other or alignment with graticule lines? How can I move all four channels together vertically?
-
Move them one by one and overlap the channel indexes on the middle, on the top most and on the bottom most grid line. Do you see a single line aligned to the indexes in all three cases? I would be surprised if you do. Not even Tek is so perfectly aligned.
-
v00.04.04.03.05 2018/04/28
- Fixed the login bug of lxi-web
With the last Version 00.04.04.04.05 the login is now working.
You can read the password with this SCPI command:
:LAN:PASSword?
The »Network Settings« login window ...
with
user: rigolan
password: 111111
-
Hello,
Sorry for my English.
I would like to know from you, why the zero level binding disappears from channel marker?
My signal is a square of 13 volts DC.
Probe to the 1X setting and when i turn vertical sensitivity to 200mV and lower, signal is shifted up and down, zero level binding with channel marker disappears, and I can not move signal to see its zero level,
since for ranges of 200mV and below, the offset range is only +- 2V.
Probe switched to the 10X and when i turn vertical sensitivity to 500mV and lower, signal is shifted up, zero level binding with channel marker disappears, but I can moving the signal manually to see the zero level.
This my problem or is it a bug?
-
Hello,
Sorry for my English.
I would like to know from you, why the zero level binding disappears from channel marker?
My signal is a square of 13 volts DC.
Probe to the 1X setting and when i turn vertical sensitivity to 200mV and lower, signal is shifted up and down, zero level binding with channel marker disappears, and I can not move signal to see its zero level,
since for ranges of 200mV and below, the offset range is only +- 2V.
Probe switched to the 10X and when i turn vertical sensitivity to 500mV and lower, signal is shifted up, zero level binding with channel marker disappears, but I can moving the signal manually to see the zero level.
This my problem or is it a bug?
The rigol series ds1054z does not support 500mV, so advise to use the DSER option to unlock it, for the little information that you give that problem I do not have it, because if I use the probes in X1 the maximum that I can test is 1mv.
in spanish
el rigol serie ds1054z no soporta 500mV, por eso aconsejan usar la opcion DSER para desbloquearlo, por la poca informaqcion que das ese problema yo no lo tengo, ya que si uso las sondas en X1 lo maximo que puedosetear es 1mv
-
The rigol series ds1054z does not support 500mV
Sure it does. Maybe you mean 500uV. :popcorn:
since for ranges of 200mV and below, the offset range is only +- 2V.
Correct. If your signal has more than 2V of DC offset then you cannot view it in DC mode.
Do you need zero? You can switch to AC mode and see all of the signal.
b) Using probes on 1x mode is not normal usage. It can cause many problems:
https://www.youtube.com/watch?v=OiAmER1OJh4 (https://www.youtube.com/watch?v=OiAmER1OJh4)
-
Thanks for your answers, but would like to know why the zero level binding disappears from the channel marker and what is reason?
500mV, NOT 500uV!
-
v00.04.04.03.05 2018/04/28
- Fixed the login bug of lxi-web
With the last Version 00.04.04.04.05 the login is now working.
You can read the password with this SCPI command:
:LAN:PASSword?
The »Network Settings« login window ...
with
user: rigollan
password: 111111
I tried it and it did not work?
-
With the last Version 00.04.04.04.05 the login is now working.
The »Network Settings« login window ...
user: rigolan
password: 111111
I tried it and it did not work?
Use it in the web-interface with any browser with your actual IP:
http://192.168.1.12/DS1000Z_NetworkSettings.html (http://192.168.1.12/DS1000Z_NetworkSettings.html)
-
Hi Fkossy,
I cannot find the information in your contributions what firmware you're on and if your scope is "improved"...
Anyway, I'ld always recommend to do a self calibration once in a while (maybe every six months) and after the instrument has been moved to a different location (temperature area). Before performing the "->Utility->(PgDwn)->SelfCal", always let the instrument warm up for an hour or so. If it fails, just try again, on my scope it may take a few attempts to pass (don't know if this is normal but after it passed, the instrument always works satisfactorily).
Moreover, in order to start testing it may be a good idea to press the ->Storage->default keys to be sure to have the scope in a known configuration unless you are sure you want to continue with the last configuration (if it is set up like that).
Good luck and enjoy your DS1000Z
Cheers,
Tom
-
With the last Version 00.04.04.04.05 the login is now working.
The »Network Settings« login window ...
user: rigollan
password: 111111
I tried it and it did not work?
Use it in the web-interface with any browser with your actual IP:
http://192.168.1.12/DS1000Z_NetworkSettings.html (http://192.168.1.12/DS1000Z_NetworkSettings.html)
Ummmm.....
-
The :LAN:PASSword? SCPI command was successful....
-
On my unit, I use "rigolan" as username. "rigollan" didn't work for me.
Wysłane z mojego Redmi 4X przy użyciu Tapatalka
-
Thanks for your answers, but would like to know why the zero level binding disappears from the channel marker and what is reason?
Calibration?
-
On my unit, I use "rigolan" as username. "rigollan" didn't work for me.
Wysłane z mojego Redmi 4X przy użyciu Tapatalka
Thanks. That worked.
-
Interesting...
If you open SparrowApp in "Notepad" there is rigollan in 3 places
-
On my unit, I use "rigolan" as username. "rigollan" didn't work for me.
Thanks. That worked.
Oh, that was the trick!
In the SparrowAPP.out you can find "rigollan" nearby "111111"
But "rigolan" is the right username.
-
Hi Fkossy,
I cannot find the information in your contributions what firmware you're on and if your scope is "improved"...
Anyway, I'ld always recommend to do a self calibration once in a while (maybe every six months) and after the instrument has been moved to a different location (temperature area). Before performing the "->Utility->(PgDwn)->SelfCal", always let the instrument warm up for an hour or so. If it fails, just try again, on my scope it may take a few attempts to pass (don't know if this is normal but after it passed, the instrument always works satisfactorily).
Moreover, in order to start testing it may be a good idea to press the ->Storage->default keys to be sure to have the scope in a known configuration unless you are sure you want to continue with the last configuration (if it is set up like that).
Good luck and enjoy your DS1000Z
Cheers,
Tom
Thanks for your answers, but would like to know why the zero level binding disappears from the channel marker and what is reason?
Calibration?
Hi TurboTom, Hi Fungus,
My firmware 00.04.04.03.02, аll options are open from the seller, except 100MHz.
I performed the calibration two times after two hours.
Zero level disappears from the channel marker when probe 1X setting and vertical sensitivity 200mV and lower and probe 10X vertical sensitivity 500mV and lower.
With the sensitivity above everything is fine.
Signal square, DC voltage 13 volts, channel DC input
-
Does it happen on other channels?
This might be distortion caused by overdriving the input amplifier. Op amps take time to recover if you apply a signal which is far out of their specified input range.
https://www.eevblog.com/forum/testgear/ds1054z-distortion-issue/ (https://www.eevblog.com/forum/testgear/ds1054z-distortion-issue/)
-
Fungus,
Yes, it happen on all channels.
Signal square, DC voltage 13 volts, channel DC input
-
Ok, I'm going to say the oscilloscope is perfectly OK and this is just op-amp distortion.
13V into a channel which is set to 200mV will distort.
(and will distort much more in 1x mode than 10x mode).
-
Fungus
I read about the overdriving, but no one wrote that this happens zero level binding disappears from the channel marker.
Is the zero level loss "normal" when overdriving DS1054?
My DSO203 for $ 100, I look on the same signal and it does not lose the zero level to the minimum sensitivity - 50mV.
It's a bad surprise for me.
-
I read about the overdriving, but no one wrote that this happens zero level binding disappears from the channel marker.
Is the zero level loss "normal" when overdriving DS1054?
"Zero level binding" isn't a real thing so you can't lose it and anything can be "normal" when you distort the input. It's undefined, it depends on the input signal.
You can set the volts/div to 'fine' control, this might let you see all the steps in between 1V and 500mV.
(https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/?action=dlattach;attach=442345;image)
Edit: I just tried it on mine and I can reproduce this using the DS1054Z's built-in test signal if I switch the probe to 1x. Fine control lets me see it gradually.
-
My DSO203 for $ 100, I look on the same signal and it does not lose the zero level to the minimum sensitivity - 50mV.
The DSO203 op-amp isn't as sensitive as the DS1054Z
It's a bad surprise for me.
It's the reality of op-amps. It happens on all oscilloscopes.
-
Fungus
Zero level loss from channel marker at 750mV for probe 10X.
-
So there it is, it's the input amplifier. :popcorn:
-
Fungus
It no problem, is it the way it should be?
Sorry, I know very bad speak English. I hope you understand my question.
-
It happens like that on all Rigol Scopes. The Rigol front ends may be a little bit more sensitive to this than expected, especially so for the DS1000Z series since there is only one "hard switching point" between 500mV and 200mV (x1 range) -- when you can actually hear the relay clicking. All the other ranges are selected by the VGA frontend in the A/D converter. Thsi means, if you supply a rather high input signal and step from 500mV ro 200mV, the analog frontend amplifier is switched to high sensitivity and it doesn't need much signal beyond the displayable range to saturate it. I got trapped by that a few times as well but it isn't much of a problem if you get used to it. Of course, it's a handicap if you've got to zoom in on small details within a high amplitude signal. I guess here you've simply got to look at the price for the instrument and take it as an acceptable compromise. I'ts much more annoying that my MSO4000 isn't performing much better... ::) Got to use my venerable analog TEK 2465 if I've got to do measurements like that...
Cheers,
Tom
-
Fungus
It no problem, is it the way it should be?
Should it be this way? That's a philosophy question.
Your oscilloscope is OK, if that's what you mean. This is normal behavior. :popcorn:
(but not ideal behavior, we can agree)
It happens like that on all Rigol Scopes.
Not only Rigol.
-
Has Rigol supplied a link to this firmware on any site other than its Chinese site? Is there any potential issue with installing the firmware on a scope purchased in North America? I assume that the firmware should be identical for all regions, but I don't understand why it's only showing up on a Chinese language site.
-
Rigol just isn't that organized, apparently, when it comes to their firmware release process. C'est la vie.
Folks here have installed it on NA scopes just fine.
-
Has Rigol supplied a link to this firmware on any site other than its Chinese site? Is there any potential issue with installing the firmware on a scope purchased in North America? I assume that the firmware should be identical for all regions, but I don't understand why it's only showing up on a Chinese language site.
I installed first the Chinese site, then the one that modified janekivi, to correct the error of spelling of "pluses" by pulses, probe back to install the original one worked and then I returned to install of janekivi, so everything perfect.
in spanish
yo instale primero la del sitio chino, luego la que modifico janekivi, para corregir el error de ortografia de "pluses" por pulses, probe volver instalar la original funciono y luego volvi a instalar de janekivi, asi que todo perfecto.
-
Rigol just isn't that organized, apparently, when it comes to their firmware release process. C'est la vie.
Folks here have installed it on NA scopes just fine.
Thanks!
I installed first the Chinese site, then the one that modified janekivi, to correct the error of spelling of "pluses" by pulses, probe back to install the original one worked and then I returned to install of janekivi, so everything perfect.
in spanish
yo instale primero la del sitio chino, luego la que modifico janekivi, para corregir el error de ortografia de "pluses" por pulses, probe volver instalar la original funciono y luego volvi a instalar de janekivi, asi que todo perfecto.
Muchas gracias!
-
Hi,
I just updated the new firmware by janekivi on DS1054z
but still the system info screen is showing Ver: 00.04.04.SP3, Board Ver: 0.1.1
why is like that?
-
s8548a, the normal system info screen doesn't display the entire version number. To reveal more details, press in rapid succession, Menu -> Menu -> Force -> Menu -> Utility -> System -> System Info
Then, you'll see the full version information.
-
Looks like v00.04.04.03.05 is available on the NA site now.
https://www.rigolna.com/products/digital-oscilloscopes/1000z/ (https://www.rigolna.com/products/digital-oscilloscopes/1000z/)
-
Thanks for the update, Miti. That took them a while.
-
I upgraded yesterday and I can confirm that the traces align better to the indexes... if you do the self cal after it warms up. I haven't seen any other "pluses" yet.
-
is there a download link where I can get the file without registering?
-
Here is the site I use:
http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0 (http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0)
-
is there a download link where I can get the file without registering?
Have a look at the Rigol DS1000Z Firmware/Buglist thread (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/msg1184253/#msg1184253). OP always gets updated with the most current direct download link!
Would make a nice sticky here, but oh well...
Kind regards,
Frederik
-
is there a download link where I can get the file without registering?
Just type anything. It doesn't have any verification.
-
It’s not a new update though, it came out in April.
-
hmmm, yep. No need to get excited. Nothing new here. :-(
-
Hi, thanks for all the valuable information in these posts. I have now joined the blog and this is my first post. Unfortunately it's a cry for help.
A couple of days I unlocked the extra features on my 1054Z using the unlock code generator posted elsewhere. I used the option code DSER. All features were shown as "official".
The existing firmware which came with the scope, purchased about a year ago, was 00.04.04.SP3. Today I tried to upgrade the firmware to the latest version which I downloaded from Rigol. I had a few attempts at loading the firmware and the scope said it was unsuccessful several times until it finally seemed to work. However, the firmware version in system information still shows the original version, not 00.04.04.03.05 which is what the scope recognised as the version number when I inserted the USB drive.
Thinking the download was corrupt I downloaded the firmware again and when I inserted the drive in the scope it warned that that version of firmware was already in the machine and I said to upgrade anyway and then it said the upgrade failed. Additional attempts at turning the scope on and off resulted in the same behaviour.
My question is, is the firmware upgraded or not? What's going on? Is it the case that the actual firmware version is not displayed in the System Info?
Thanks.
-
Look at the extended system info by
Pressing MENU, MENU, FORCE, MENU, Utility, (soft button) System, (soft button) System Info quickly one after the other.
-
Look at the extended system info by
Pressing MENU, MENU, FORCE, MENU, Utility, (soft button) System, (soft button) System Info quickly one after the other.
Thanks. I've tried that and still get the same original firmware number.
-
Look at the extended system info by
Pressing MENU, MENU, FORCE, MENU, Utility, (soft button) System, (soft button) System Info quickly one after the other.
Thanks. I've tried that and still get the same original firmware number.
If you are still seeing 00.04.04.SP3, you did not do the MENU, MENU, FORCE, MENU buttons fast enough.
The last version digit is NOT displayed on the normal status page. Indicated by seeing SP# in the version.
Example extended system info
(https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/?action=dlattach;attach=521963;image)
-
I have tried this many times both using the menu button on the left and the menu button above the force button. No matter how fast I press them I do not get the extended system information. When using the menu button above the force button the screen menu goes into a different mode that doesn't include any system information options.
-
Ok, I have worked it out now. I was looking for the screen utility button, not the physical utility button.
It says I have the firmware 00.04.04.03.05.
Thanks for the help.
-
I can make this happen.
Did only Pluses.
DS1000Z_00_04_04_03_05.zip (http://s000.tinyupload.com/index.php?file_id=84621285266561797736)
Hi janekivi,
The file is no longer available, can you replace it please? I just found out there was new FW introduced (but still with the spelling error |O )
Regards, Rob
-
Here I uploaded it, it's that of the janekivi friend, I had it downloaded.https://mega.nz/#!dFZAHQoK!T-I56b2R3sNJmvYrswF6zMD9ewUzs3Xt-aTfK_BoVss (https://mega.nz/#!dFZAHQoK!T-I56b2R3sNJmvYrswF6zMD9ewUzs3Xt-aTfK_BoVss)
-
That leads me to the question: Is there a github / bitbucket / ... for the firmware hacking resources?
Alternatively I could offer to host compiled files on my web server.
-
Seems like 04.04.04.02 is out: http://www.rigol.com/File/ProductSoftWare/20190228/DS1000Z(ARM)update.rar (http://www.rigol.com/File/ProductSoftWare/20190228/DS1000Z(ARM)update.rar)
Changelog specifies new encoder drivers. So far, I didn't install it. Maybe finally a usable acceleration or Rigol addresses the multi-function knob without indents?... Who's the first one to find out? ;)
-
A big firmware day at Rigol!
The release notes only mention one change:
[Updated Contents]
--------------------
v00.04.04.04.02 2018/02/26
- Add new encoder drivers
(Wrong year? We're in 2019 now...)
-
Who's the first one to find out? ;)
Just installed it.
I can't see much difference so far.
-
The encoder reference is just a distraction. You need to find what they broke!
-
pluses fixed?
I thought they already 'fixed' that in the previous one, I don't remember.
But the new one says "Pulses" :(
(https://www.eevblog.com/forum/testgear/new-firmware-ds1000z-00-04-04-03-05-2018-05-09-(2018-02-28)/?action=dlattach;attach=664227;image)
(I was quite fond of that typo)
-
The pulses is correct.
00000000 - File Type: DS1000Z
00000010 - Software Branch/Version: 00.04.04.04.02
00000020 - Bitmask: 00000700
00000024 - # Sections: 10
Offset Section Name SectiSz StartAdr CRC32 Type
00000028 /sys/SparrowAPP.out 001092C5 00000280 A6399A25 00000001 [00000280-00109544] CRC OK
00000064 /sys/SparrowFPGA.hex 000C4372 00109545 53615D42 00000005 [00109545-001CD8B6] CRC OK
000000A0 /sys/SparrowDGFPGA.hex 00046F04 001CD8B7 C26BCA0B 00000006 [001CD8B7-002147BA] CRC OK
000000DC /sys/logo.hex 000BB818 002147BB BE511060 0000000A [002147BB-002CFFD2] CRC OK
00000118 /sys/guiResData.hex 000B6B34 002CFFD3 979D9186 0000000C [002CFFD3-00386B06] CRC OK
00000154 /sys/guiPicData.hex 0001E6BF 00386B07 E31015E7 00000011 [00386B07-003A51C5] CRC OK
00000190 /sys/SparrowConfig.hex 000BB818 003A51C6 A8ACDE94 00000010 [003A51C6-004609DD] CRC OK
000001CC /sys/SparrowWaveTable.hex 000020E8 004609DE 45F4045B 0000000B [004609DE-00462AC5] CRC OK
00000208 /sys/SparrowCalFile.hex 00022EFD 00462AC6 DA1B1AD2 0000000F [00462AC6-004859C2] CRC OK
00000244 00000118 004859C3 00000000 00000032 [004859C3-00485ADA]
Offset CRC32 Flags Filesize Endianes Branch/Version
00000280 F2A44DB6 00000003 001092AD AA5555AA 00.04.04.04.02 [00000298-00109544] CRC OK
00109545 C9AF5D56 00000000 000C435A AA5555AA 00.04.04.04.02 [0010955D-001CD8B6] CRC OK
001CD8B7 138E13B9 00000000 00046EEC AA5555AA 00.04.04.04.02 [001CD8CF-002147BA] CRC OK
002147BB 9B4EA177 00000000 000BB800 AA5555AA 00.04.04.04.02 [002147D3-002CFFD2] CRC OK
002CFFD3 271E3AB5 00000000 000B6B1C AA5555AA 00.04.04.04.02 [002CFFEB-00386B06] CRC OK
00386B07 01873014 00000001 0001E6A7 AA5555AA 00.04.04.04.02 [00386B1F-003A51C5] CRC OK
003A51C6 5DEF7058 00000000 000BB800 AA5555AA 00.04.04.04.02 [003A51DE-004609DD] CRC OK
004609DE 27F4C06F 00000000 000020D0 AA5555AA 00.04.04.04.02 [004609F6-00462AC5] CRC OK
00462AC6 1E61A8F6 00000000 00022EE5 AA5555AA 00.04.04.04.02 [00462ADE-004859C2] CRC OK
File Processed OK
-
Also upgraded to new Version 04040402 successfully. With regard to 'Pulses' the left side Menu was updated to Pulses in last years update but the bottom of screen stats displays remained with 'Pluses'. This update has corrected that so all Pulses are as they should be. :) Now waiting for a complete warm up to run Self Cal and then see if I can notice any other changes in this Version.
-
I just updated v00.04.04.04.02 and calibrated the D1054z rigol, the presses were corrected (pulses) the calibration was fine.The good thing about all this is that they are still working on the DS1000z series :clap:
-
Self Calibration ran successfully and all appears well. On limited testing the response time to adjusting Vertical gain and TB speed appear to be greatly improved. No noticeable lag. Perhaps others can confirm as it does seem radically faster almost instant. If just my scope perhaps the Self Cal recovered how it used to be as I haven't run Self Cal for over a year. ;D
-
Self Calibration ran successfully and all appears well.
I can't imagine calibration is even needed after an update like this. It would only need recalibration if they change the code that manages the vertical gain amplifiers, which would be, like, never.
I haven't run Self Cal for over a year. ;D
OTOH you're supposed to do it a few times per year to compensate for summer/winter/etc.
-
hi,
I did the upgrade for my DS1054Z, everything ok, rebooted the thing, check if upgraded>ok, then calibrate after 50 minutes failed.
now I'm trying calibration second time.
and yes, he was hacked before :)
[edit]
second calibration passed ok, now is fine.reports Model DS1104Z version 00.04.04.SP4, board version 0.1.1,
installed options remained untouched (trigger/decoder/mem-depth/recorder/bw 100M) :)
-
You really need to have scope on for at least half an hour before self cal.
One thing I've noticed is that after self cal all 4 traces perfectly align around zero and that encoders (especially one for horizontal position) have different (more aggressive, faster) acceleration profile.
Pulse are fixed in menu and measurements.
Otherwise works normally.
-
On limited testing the response time to adjusting Vertical gain and TB speed appear to be greatly improved. No noticeable lag. Perhaps others can confirm as it does seem radically faster almost instant. If just my scope perhaps the Self Cal recovered how it used to be as I haven't run Self Cal for over a year. ;D
just installed it out of curiosity, did a calibration. no its still the same laggy on both vert and horz offset. vert and horz gain also still the same (laggy or not it depends on how you feel it), so no magic happened on my scope. but on the horz (time) offset, on previous version, on very quick encoder rotation, the time marker went off the chart very easiy far away, took me few counter encoder rotation to get it back, or easiest press for zero offset. but this version, on counter very fast rotation, the marker goes back to zero, so its nicer and quicker imho. but they are all laggy as before, the only way i know to get better respond is put the acq in stop mode and change to your heart content. math still like 3fps slow. the other thing i noticed is the bottom pluses urban legend is now gone. havent made extensive test on https://www.eevblog.com/forum/testgear/mechatrommer_s-rigol-bug-report-space/?topicscreen (https://www.eevblog.com/forum/testgear/mechatrommer_s-rigol-bug-report-space/?topicscreen) since previous version though... ymmv...
-
Kind of sad to see pulses instead of pluses :-\
-
Kind of sad to see pulses instead of pluses :-\
Same here. It was one of those imperfections that gave it a little character. :)
-
Seems like 80% of the discussion around the new firmware release is about the "pulses".
I'll take that as an indication that the DS1000Z series firmware is pretty solid now. ;)
-
Seems like 80% of the discussion around the new firmware release is about the "pulses".
I'll take that as an indication that the DS1000Z series firmware is pretty solid now. ;)
No, it's because people now are sad for loosing the trademark designation...
-
Kind of sad to see pulses instead of pluses :-\
Same here. It was one of those imperfections that gave it a little character. :)
I want to change it back.
-
I want to change it back.
Since the construction and deconstruction tools exist, we could compile an EEVBlog sentimental language pack for the DS1000z series. xD
-
Since the construction and deconstruction tools exist, we could compile an EEVBlog sentimental language pack for the DS1000z series. xD
:-DD
-
Kind of sad to see pulses instead of pluses :-\
Same here. It was one of those imperfections that gave it a little character. :)
I want to change it back.
This is easy, I have somewhere old utility for this. But from now you need to use it backwards...
-
I want to change it back.
Since the construction and deconstruction tools exist, we could compile an EEVBlog sentimental language pack for the DS1000z series. xD
You guys crack me up! "Only on EEVblog..." :-DD
-
The new encoder driver is kind of annoying about the push feature - if a knob is pushed shortly, the push is not recognized, you need intentionally make a little bit longer push to make it work! I do not remember if this "bug" was present before I updated the FW... Can someone check this just before firmware is updated?
-
I want to change it back.
I won't even upgrade for that matter. I want to keep my collection instrument with modern features. :-+
-
The new encoder driver is kind of annoying about the push feature - if a knob is pushed shortly, the push is not recognized, you need intentionally make a little bit longer push to make it work!
I beg to differ: This change came two firmware releases ago, and I am *really* happy about it, since the nervous multi function key is now tamed. I cannot count the times when I mis-selected a menu item when pushing the knob! Since the update, the mis-selections went down considerably, and I can very well live with the longer push needed. /me is happy!
-
I am happy, now I do not make more erroneous selections, I pressed the encoder and jumped to another option. very pleased with the firmware updates, really the DS1054z me its quality.