Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)

[rsjsouza]

PNG screenshot with thumb-drive and printer button takes 2 1/2 MINUTES !

One detail: at a certain point in the firmware merry-go-round, the DS4000 series had the same issue. I found out that FAT32 pendrives were terribly slow while FAT16 was very fast. Perhaps you could try this with your DS1000Z?

Was it the exact same pendrive formatted both ways?

I don't own a DS1000Z and that was definitely an issue on the DS4000 at a certain point that manifested itself similarly to what was reported by Fennec - all bases covered (different brands, sizes and formats).

[bitseeker]

If it can handle FAT32 then I don't see why the drive size would make any difference at all. 

Actually it does and there is no problem at all writing to:

USB Stick CNMemory "Spaceloop"
      PCI Device ID: 0x268c
      PCI Revision ID: 0x0009
      PCI Vendor ID: 0x8086
      32Gb, FAT32 formatted via OS X Disk Utility


Can not remember having any trouble writing to USB sticks, apart from ExFAT, OS X Extended,... formatted media. So as long as it is FAT16/32 formatted – no problem at all.

There are definitely issues reading/writing some USB stick/thumb/pen drives. There was a bit of discussion about it back in 2015 having to do with media, allocation table, and cluster sizes: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg782838/#msg782838

[frozenfrogz]

I am aware of that and maybe I expressed poorly what I meant. This was more in regard to "32Gb should not be a problem if FAT32 works".

There definitely needs to be evaluation done on what kind of USB sticks are affected and if we can pin it down to a certain chipset or what-do-I-know
Yesterday I added this silently to the original post where this issue is taking up space número diez in the bug list.

For know, the only work around seems to be trying out different brands and stick with one that gets the job done.

[rstofer]

I have been using an Imation 2 GB Clip device and I can save a .png image in about 5 seconds.  I'm pretty sure this is FAT16.
It also takes about 5 seconds on a Cruzer Glide 256 GB which is FAT32.

I have no idea what is inside either of these devices but they sure seem to work for me!

I have a much smaller stick that I use for software upgrades.  No reason, really, it's just that I don't want to get things confused so I have this stick dedicated to the purpose of upgrading.

[BravoV]

From Rigol manual :

[bitseeker]

Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?

It would've been helpful if Rigol published what maximum cluster size is supported.

[frozenfrogz]

Testing out different allocation unit sizes might be worth trying.
BRB

[BravoV]

Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?

It would've been helpful if Rigol published what maximum cluster size is supported.

The manual is dated Dec 2015, didn't aware if there is newer one. Downloaded it quite long ago though.

Looking at the USB flash drive fiasco, I suspected Rigol programmer probably either was using a really crappy FAT(32/16) library, or they screwed the library by forking/shrinking it too much, maybe to save flash size or RAM memory or even CPU cycles ? 

[frozenfrogz]

I took two USB sticks, one with 32Gb and one with 2Gb and tried to get my Rigol fail on write due to unsupported allocation size. Everything passed.

drive size   |	file system |	allocation unit size |	Rigol write test
2Gb / 32Gb	FAT16	32 kbyte	PASS
2Gb / 32Gb	FAT16	64 kbyte	PASS
2Gb	FAT32	512 byte	PASS
2Gb / 32Gb	FAT32	1024 byte	PASS
2Gb / 32Gb	FAT32	2048 byte	PASS
2Gb / 32Gb	FAT32	4096 byte	PASS
2Gb / 32Gb	FAT32	8192 byte	PASS
2Gb / 32Gb	FAT32	16 kbyte	PASS
32Gb	FAT32	32 kbyte	PASS
32Gb	FAT32	64 kbyte	PASS

(formatted on Windows 7 32bit machine via on-board disk utility)

But as I reported before, there have been no issues with USB drives on my scope (apart from the obvious: NTFS / ExFAT / OS X Extended formatted drives)
I would need an USB drive that is reportedly not working to further investigate...

[smithnerd]

Yeah, the Rigol manual (which version is that from, BravoV?) says maximum 8GB formatted as FAT32. However, there have been problems reported that conflict with the manual. Rstofer just posted success with 2GB FAT16 and 256GB FAT32. Others have had failures with 2GB FAT32.

I upgrade my scope with a 512MB FAT16, which defaults to either 8KB or 16KB clusters on Windows.(Unfortunately, Microsoft doesn't explicitly specify the size ranges. Grrr! e.g., 256 MB–512 MB has 8KB clusters; 512 MB - 1 GB has 16KB clusters. So, to which range does 512 MB apply?

It would've been helpful if Rigol published what maximum cluster size is supported.

The manual is dated Dec 2015, didn't aware if there is newer one. Downloaded it quite long ago though.

Looking at the USB flash drive fiasco, I suspected Rigol programmer probably either was using a really crappy FAT(32/16) library, or they screwed the library by forking/shrinking it too much, maybe to save flash size or RAM memory or even CPU cycles ? 

The library is called MFS, it's part of Freescale/NXP's MQX. Somebody put an (unofficial) mirror of the source code tree on github, if you're curious:

https://github.com/gxliu/MQX-3.7.0/tree/master/mfs

...though some code from later MQX releases (3.7 is ancient) may have been back-ported into Rigol's build.

Edited to add: Freescale MQX(TM) MFS(TM) User’s Guide:

https://raw.githubusercontent.com/gxliu/MQX-3.7.0/master/doc/mfs/MQXMFSUG.pdf

[ankerwolf]

Hello,
Bug #5 I can say:
Pass: Board Version: 0.1.1, Boot Version: 0.0.1.3, Firmware Version: 0.2.3.11, CPLD Version: 1.1

LG Wolf

[frozenfrogz]

Thanks ankerwolf
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)

[Fungus]

Thanks ankerwolf
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)

Nope. I've got boot version 0.0.1.1 and it doesn't happen here.

Edit: Here's my full info...


(Screenshot took about 8 seconds to complete)

[BravoV]

Big jump, just upgraded DS1104Z-S (with FG), from v04.00.00.00 straight to v04.04.03.02, so far no problem, at least at the upgrade process it self.

Just fyi, used an old 8GB USB flash drive with FAT32 and 4096 bytes allocation unit, freshly reformatted and just copy the single .GEL file at the root directory, no other files in it.

[frozenfrogz]

Thanks BravoV,

did you run self-calibration without problems?
That is where issues seem to be sticking their head out.

[BravoV]

Thanks BravoV,

did you run self-calibration without problems?
That is where issues seem to be sticking their head out.

Yes, after the upgrade process finished, turned the power off, power on again, and straight to the long self-calibration process, and it finished without any problem.

Forgot to mention, before doing the upgrade, I did the memory "sanitation" 1st as Rigol document stated, just want to make sure its like fresh from factory, which are :

- Clear the internal volatile memory :
   Buttons pressed = STORAGE > DISK MANAGE > FLASH ERASE

- Restore Power Of Setup restored to "Default" :
   Buttons pressed = UTILITY > SYSTEM > POWER SET = Default

- Then power off the unit.

- Power on, insert the "blank" USB flash drive, to check whether it recognizes the USB first, and it did.
  (PS : "blank" means a freshly formatted 8GB FAT32 with 4K alloc. and without any file in it as its freshly formatted.

- Unplugged the flash drive, brought it to my computer, copied "only" the single .GEL file, as I mentioned above, its the only file in the drive and at the root directory.

- Plugged the flash drive, instantly it recognized the new firmware, proceeded next as my previous post's photos.

Thats all.

EDIT :

Here is the USB drive details from Windows standard check disk result (CHKDSK), formatted under Win 7 x64 from the Explorer, right click at the drive and quick format using default allocation.

Code: [Select]

The type of the file system is FAT32.
Volume USB 8G created 4/19/2016 9:58 AM
Volume Serial Number is 503E-347B
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.
    7,551,380 KB total disk space.
        4,632 KB in 1 files.
    7,546,744 KB are available.

        4,096 bytes in each allocation unit.
    1,887,845 total allocation units on disk.
    1,886,686 allocation units available on disk.

[BravoV]

I did capture the screen using the print feature too, apart from taking the photo using camera.

What I found an interesting change is the screen layout, at least from 4.0.0.0 to 4.4.3.2 , looks like they resized part of the screen real estate abit.

Just watch this animation switching between these two versions. This is untouched PNG file saved using the print, size untouched and converted straight into animated GIF.

[frozenfrogz]

Also: You got a hardware upgrade via USB implant as it seems xD

[BravoV]

Also: You got a hardware upgrade via USB implant as it seems xD

Yep , what a sharp eyes you got there. 

[frozenfrogz]

I added the direct link to last known firmware release that also contained a board / boot version update file to the opening post. (v.00.04.00.00.00)

Please: If any of you does the boot version update, or did the update already, can you leave some info on what version is included here? I would like to add this info as well

[ebastler]

Also: You got a hardware upgrade via USB implant as it seems xD

Yep , what a sharp eyes you got there. 

I noticed that the displayed board version has changed; assume this is what you are referring to?
But what's up with the "USB implant"? I must have missed something there...

[bitseeker]

But what's up with the "USB implant"? I must have missed something there...

In other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.

[frozenfrogz]

I noticed that the displayed board version has changed; assume this is what you are referring to?
But what's up with the "USB implant"? I must have missed something there...

USB implant was actually a joke

The version number does not really make sense, as the more recent ones are labeled 0.1.4 and this unit had 0.1.1 and now is shown as 4.1.1 – the flying spaghetti monster knows why...
As a change in hardware revision usually needs some physical change of components, I implied surgical procedure via USB stick. Must be some kind of futuristic replicator technology...

Edit: What bitseeker said

In other words, it's as if a hardware upgrade was physically implanted via the USB interface. That'd be a nice feature, indeed.

[BravoV]

LOL  , although I haven't thoroughly test all, I guess that big jump 0.1.1 to 4.1.1 probably has something to do with the FG board, at least for service engineer. Since it doesn't show additional field for the FG's firmware version at the screen. Its a DS1104Z-S , not a hacked DS1054Z which doesn't have it.

[frozenfrogz]

Thanks ankerwolf
Sooo.. Maybe we can pin this on boot version <0.1.3?
(still needs a bigger dataset obviously)

Nope. I've got boot version 0.0.1.1 and it doesn't happen here.

Might be interesting if the freeze bug could then be pinned to only affecting boot version 0.0.1.2

Hopefully we can resolve this