Products > Test Equipment
Buyer Beware: Siglent Electronic Load
<< < (7/7)
2N3055:

--- Quote from: kcbrown on June 26, 2021, 07:33:00 pm ---
--- Quote from: 2N3055 on June 25, 2021, 09:31:29 pm ---PC motherboard updates (which seems to be what people are expecting) are happening either in DOS boot or from OS but with flash in banks. That become more common with UEFI that has more integration with BIOS and OS.
Before that, it was boot to DOS and upgrade firmware.

--- End quote ---

Exactly.  But the point here is that the state of the art is now, and has been for quite a long time, to use flash in banks.

An alternative would be to have a known good image in good old ROM, so that you're guaranteed to have something to boot from (and to upgrade with) in the event an upgrade attempt goes wrong.   ROM has the advantage that you can boot from it even if the flash is malfunctioning.  You might well have an emergency flash upgrader in ROM already, in which case you may as well use a larger ROM and put a full copy of a known good boot image there.



--- Quote ---I agree it is unusual that USB stack on firmware updates is picky . I would presume that code that updates firmware from USB stick is some sort of bootloader, and not running Linux and therefore not having real full USB stack and filesystem as a proper OS has... That might be the problem. I don't know. That part of code may be the part of development platform.. Or ready bought library..

--- End quote ---

That might be, but I don't buy it as a good reason for it.  These devices have JTAG interfaces that can be used (and almost certainly are at the factory) to initially program the flash.  So you don't need the bootloader code to program the flash unless your flash isn't in banks or isn't sufficiently sized to hold more than one image.   But the point here is exactly that the use of banked flash or flash sized large enough to hold multiple images is the standard approach to this problem, and there just isn't any excuse anymore to not use that approach.

About the only complication I can think of is if the operating system itself is executed directly from flash, rather than being loaded into RAM from it.  But RAM, too, is cheap, most certainly in the quantities necessary to house an embedded OS, and executing from RAM instead of directly from flash solves a whole host of problems that you'd otherwise have, such as very slow instruction fetch times while within the operating system.  If the operating system is executing from RAM as it should be, then it would be just as able to upgrade the flash image as anything else, and that eliminates the excuse of not being able to perform upgrades from within code that understands how to read all properly functioning USB sticks.

So the bottom line is that the current state of the art has been what it is for quite some time now, and there's no real excuse that I can think of for these devices to be deviating from it.

--- End quote ---

I don't want this to be considered as an excuse for Siglent for having problems with some USB sticks, but today I took a look at Dave's video about fancy PSU from R&S and that one also couldn't read one properly formatted stick but worked OK with other brand... It does seem that this USB stick compatibility problem is more common with those kinds of devices that use bare metal RTOS and embedded USB stacks, than people think,...

Still, even if a USB compatibility cannot be made such that work with absolutely every USB stick disk, device should simply reject it with clear error message. That would be good start. In that case, you could simply try few sticks, pick one that works and keep it dedicated for that purpose.
kcbrown:

--- Quote from: 2N3055 on June 26, 2021, 11:02:26 pm ---I don't want this to be considered as an excuse for Siglent for having problems with some USB sticks, but today I took a look at Dave's video about fancy PSU from R&S and that one also couldn't read one properly formatted stick but worked OK with other brand... It does seem that this USB stick compatibility problem is more common with those kinds of devices that use bare metal RTOS and embedded USB stacks, than people think,...

--- End quote ---

I agree with you there.  But it's unclear why this is.  I can see how that could be the case if they're using an RTOS that stopped development a decade ago or so, but anything newer than that should be able to easily deal with any of the modern USB sticks that are out there.  The sole possible exception might be pure USB3 devices that don't work with pure USB2 interfaces.  But those should be incompatible with all USB2 ports.

It's on the manufacturers to make use of an operating system that is properly maintained.  I would argue that an operating system that cannot properly recognize modern USB sticks is one that is not properly maintained.

For Siglent, there's no excuse at all.  They're using Linux as the operating system in all of the devices I'm aware of (if the electronic load here is an exception, one is left wondering why in the world that is), and that does have proper compatibility with modern USB sticks of all sizes.  Whatever Siglent's issue is, it's almost certainly not in the operating system itself.  Or if it is, they're doing something horribly wrong for that to be the case.



--- Quote ---Still, even if a USB compatibility cannot be made such that work with absolutely every USB stick disk, device should simply reject it with clear error message. That would be good start. In that case, you could simply try few sticks, pick one that works and keep it dedicated for that purpose.

--- End quote ---

I certainly agree with this, but obviously it should be in addition to a properly level of compatibility with modern USB sticks, not a replacement for it.
Caltech-WireWizard:
I'm not entirely convinced it's a Firmware "UPDATE" problem. I received my Siglent SDL1020X-E 2mo. ago on December 12, 2023. First thing after I received it was update the Firmware. No issues. In-fact, I had Siglent Tech Support on the phone while I was doing it in case of any issues. There were no issues during the update. BTW, According to Siglent, the maximum drive size is 4GB FAT32 formatted w/4k cluster size) It's now Feb. 18th 2024 (2mo. of use). I had that same boot error screen. I had no issues leading up to that. All I did was power-cycle it and it booted fine. Then I had it a second time. I suspect corrupt firmware. I reflashed it. No problems since. (here's hopping..... crossing fingers)
slugrustle:
Even if the instrument doesn't have enough flash memory to hold two firmware images, it should at the very least read the entire new image from the USB drive and verify that with checksum before trying to go further.  That doesn't take any more memory on the instrument and should catch issues with bad images, bad flash drives, unsupported drive formats, etc.

Heck, you would think that if there are requirements on USB drive size and partition formatting, the instrument would check that the USB drive meets the requirements and give the user a helpful warning if it doesn't, then refuse to attempt an update in such circumstances.

I agree that the original post was phrased in a slightly drastic way if the poster hadn't tried to work with Siglent or the distributor yet, but I can also understand how frustrating these situations can be.  Certainly, bricked instruments shouldn't happen simply due to drive size or partition formatting.

All of this said, I updated the firmware on a Rigol bench DMM recently, and I was careful to follow the instructions, including plugging the DMM into a UPS during the update.  You never know...  I also stick to USB drives with SLC flash, usually 1GB size with a singe FAT16 partition.  Those seem to work on everything.

Navigation
Message Index
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod