From the screen shot above,
00:4 is the operating time for the current secession in Days Hours : Minutes.
3 6:24 is the total operating time in Days Hours : Minutes.
StartUp Cnter is the total number of times the DSO has been powered On.
There is a new version of firmware on the Chinese page
https://www.rigol.com/products/detail/DS1000Z it has a date 2023-04-10
Inside in readme file, there are two dates:
[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date] 2022/03/25
[Updated Contents]
--------------------
v00.04.05.02.04 2023/02/28
-Added new nandflash driver and original nandflash compatibility
[Updated Contents]
--------------------
v00.04.05.02.04 2023/02/28
-Added new nandflash driver and original nandflash compatibility
Sounds like a manufacturing change.
Maybe they changed the internal memory on the latest ones coming off the production line or something like that.
the readme says that it is compatible for the rigol ds1000z versions, it would be necessary to see if it works for mine, which I acquired in 2018, since it is to update the nandflash controller, if it is one of those produced recently or all.
just do the chinese update scope works like before
[Updated Contents]
--------------------
v00.04.05.02.04 2023/02/28
-Added new nandflash driver and original nandflash compatibility
Looks like a minor update as only the last digit is changed in the version number. But the rev. history discloses more important information.
The reason for the previous version is now clear:
v00.04.05.02.03 2022/03/25
-add system file backup, solve the problems of red screen when booting, buzzer beeping, keyboard flashing
It must be a frequent issue, because there is related app note on the N.A. web site. And this is exactly what I'd experienced. It does not boot, red screen, and an attempt to apply the proposed fix results in buzzer beeping, keyboard flashing.
To my knowledge, v00.04.05.02.03 was never published. Assuming every update is cumulative, the latest version incorporates a fix for the red screen issue as well. For those running a version older than v00.04.05.02.03, it'll make sense to upgrade to the new version ASAP, just to be on the safe side. IMHO.
Must be a problem for newer hardware versions. My DS1054Z is from 2015 or so, and never had boot problems. Since it's working fine and there are no new features in the recent firmware, I see no reason to upgrade.
Must be a problem for newer hardware versions. My DS1054Z is from 2015 or so, and never had boot problems. Since it's working fine and there are no new features in the recent firmware, I see no reason to upgrade.
Never saw it either.
Maybe the problem was with a different supplier of NAND flash they started using.
The red screen problem has been around for a while (no idea how frequent it is). See
https://www.eevblog.com/forum/testgear/rigol-red-screen-of-death/I've seen a red-screened DS1054z go for peanuts on eBay as "for parts/not working" within the past half year or so. If this update makes it an easy fix, someone got a good deal.
Maybe they are replacing those faulty nands with other manufacturer NAND and this is a reason why this version has new drivers.
It's not a cultivated memory device like eMMC. Rigol still uses raw NAND Flash chips so it's the programmer's burden to perform error handling, bad block management, wear leveling. Longevity of the product depends on how well it is implemented. Only Rigol knows the actual quality of its SW in that regard. In worst case, first bad block appearance results in device failure. "solve the problems of red screen when booting" might mean improvement in Flash housekeeping code.
It's not a cultivated memory device like eMMC. Rigol still uses raw NAND Flash chips so it's the programmer's burden to perform error handling, bad block management, wear leveling. Longevity of the product depends on how well it is implemented. Only Rigol knows the actual quality of its SW in that regard. In worst case, first bad block appearance results in device failure. "solve the problems of red screen when booting" might mean improvement in Flash housekeeping code.
I reverse engineered a fair bit of the DS1054Z firmware, including the NAND filesystem code a few years ago. I can't comment on recent firmwares, because I haven't looked at them, but I was left with the impression (on 00.04.04.03.02, I think) that the flash handling was somewhat basic. This code was present in both the bootloader and the application firmware:
https://github.com/rickyzheng/uffs
In their "mature" instruments, Rigol stores frequently altered data in a separate FRAM chip that's virtually inert against write wear. Not sure for all their recent gear, but at least the DG800/900/2000 series of AWGs still contains an FRAM chip
(MB85RC16).
According to my notes, I had some doubts about the uffs page size being correct for the SKhynix H27U1G8F2B NAND chip's block/spare sizes.
I reverse engineered a fair bit of the DS1054Z firmware, including the NAND filesystem code a few years ago. I can't comment on recent firmwares, because I haven't looked at them, but I was left with the impression (on 00.04.04.03.02, I think) that the flash handling was somewhat basic.
It doesn't need to be very sophisticated. The flash isn't being written to all day long. Just screenshots and the occasional firmware update.
I believe the current state (which has to be saved after every button press) goes in a separate FRAM.
I reverse engineered a fair bit of the DS1054Z firmware, including the NAND filesystem code a few years ago. I can't comment on recent firmwares, because I haven't looked at them, but I was left with the impression (on 00.04.04.03.02, I think) that the flash handling was somewhat basic. This code was present in both the bootloader and the application firmware:
https://github.com/rickyzheng/uffs
Community is power, but full reverse engineering of a system of that complexity seems quite difficult.
UFFS is just a generic code that requires adaption/porting for particular project. Simplification or extension could be done in the process. The design uses raw flash part, so in general, the code needs to be updated each time the part type is changed. That alone creates a good source of bugs.
BTW, UFFS is still of v1.3.6, in which "Dynamic wear-leveling, Static wear-leveling is not implemented", according to the pdf document.
For most people (including the managers) new features are more interesting while improved reliability is something difficult to sell. The only incentive to improve reliability is a high return rate. We know how lazy Rigol is with new firmwares. The fact that a new version (I mean 00.04.05.02.03, not the latest one) has appear suggests that the red screen problem was really noticeable. BTW in that version, the boot code is the same as in 00.04.05.02.02, so perhaps a bad block in flash is not the only cause.
In their "mature" instruments, Rigol stores frequently altered data in a separate FRAM chip that's virtually inert against write wear. Not sure for all their recent gear, but at least the DG800/900/2000 series of AWGs still contains an FRAM chip (MB85RC16).
Yes it is. Looks like Rigol has a huge stock of that parts, as exactly the same part can be found on the DS1054Z PCB. So the hardware is there. Let's hope the NAND Flash is indeed saved from all frequent writes.
By the way, the DGs are a Linux based designs, so in theory, the number of available spare blocks and other related statistics can be read by a command via the debug console
There is a new version of firmware on the Chinese page https://www.rigol.com/products/detail/DS1000Z it has a date 2023-04-10
Inside in readme file, there are two dates:
[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date] 2022/03/25
[Updated Contents]
--------------------
v00.04.05.02.04 2023/02/28
-Added new nandflash driver and original nandflash compatibility
There is again a new firmware on the Chinese Rigol website.
But I'm a bit confused as the version number didn't change - neither in the release notes nor in the header of the GEL-file.
Release notes say "-Added startup exception reminder" and the GEL-file is ~0.7MB larger than the previous one.
Don't want to be the first to blow his scope.
Any volunteers?
[Supported Model] All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date] 2022/03/25
[Updated Contents]
--------------------
v00.04.05.02.04 2023/05/16
-Added startup exception reminder
[History]
--------------------
v00.04.05.02.04 2023/02/28
-Added new nandflash driver and original nandflash compatibility
[...]
From the changes log, that firmware doesn't fix any bugs, and doesn't add extra features for the already existing scopes. Looks like it is for the newer scopes that will be fabricated with a different type of NAND chip.
Probably won't brick the old models, but won't help them either, so I see no reason to upgrade.
The nand flash entry came with the February update and I agree, that this might not be of interest for older scopes.
But the "startup exception reminder" from May could be useful.
I ask myself:
- Why the heck two updates with the same number?
- What does a "startup exception reminder" do, that needs 14% more firmware space?
- Will it
blend brick?
- What does a "startup exception reminder" do, that needs 14% more firmware space?
I don't know either, but a name like "startup exception reminder" doesn't promise anything good, that's for sure.
- Why the heck two updates with the same number?
Poor version control management? (i.e. get current source, patch it, recompile and release - forgetting to increase the version counter)
Can someone please share the direct file urls to the last few firmware revisions? One the chinese site would be great as well. My browser hates their login page and popup.