Buyer Beware: Siglent Electronic Load

[2N3055]

Siglent fans, you are not doing any good to Siglent by bashing digby70, a buyer and a newcomer to EEVblog, with words like "bitching" and "Muppet".   

Yeah don't inflame the issue... I said what I said, read again, all of it. If I say something and I'm proved to be wrong ,I apologize. I won't be going back and "rewrite history". I own my mistakes, and it wasn't even mistake but really misunderstanding in terms.. You're very intelligent and decent person, I'm sure you can take balanced look.

And no, no need for Siglent lovers or haters equally... Fact that OP had problems is undisputable. How he reacted, is a matter of discussion.

Also I'm really amused by all of the people who take device firmware upgrade as some easy-peasy thing that is supposed to be completely risk free.
Try updating firmware with flaky power.. There are many things that can go wrong with firmware update.. And maybe 10 years ago, you had to return device to factory to update firmware.

I have few Siglent devices at my disposal and ones that I have do seem to say "verifying image" when doing upgrade.
I don't know what underlying OS /RTOS it uses and what is actual Firmware upgrade code.

So instead of making this a bashing in all directions, I suggested to make it constructive:

Maybe a question to Siglent if they could make it more robust (not to use "foolproof" to insult more people), and maybe being able to detect and reject USB sticks that doesn't work well...

[kcbrown]

My advice to OP: Everybody make mistakes.. God knows I reacted too soon many times in my life..  But please be so kind and fix (edit topic title to something like: False alarm and warning: Siglent Loads are sensitive to USB stick properties..). That would convert a mistake to a useful topic that will warn other users that if they have problem, the USB stick might be the culprit...

But still the DC load could have failed in a more descriptive / well defined manner; for example by checking the USB stick layout and testing the checksum of the firmware image to see if the image is actually complete. A message saying 'USB stick incompatible' or 'firmware image corrupt' is way more descriptive than the device getting into a non-working state.

There's really no excuse whatsoever, in this day and age, to fail to test the firmware image prior to installing it, much less after installing it.  Such verification must happen at both levels because in the absence of fallback firmware, you risk bricking the device otherwise.  Bricking the device is a completely unacceptable outcome in the event of anything other than a major hardware failure.

Obviously there should be enough flash storage to hold two copies of the firmware: the one that is currently in use, and the one that is being upgraded to.

[kcbrown]

Also I'm really amused by all of the people who take device firmware upgrade as some easy-peasy thing that is supposed to be completely risk free.
Try updating firmware with flaky power.. There are many things that can go wrong with firmware update.. And maybe 10 years ago, you had to return device to factory to update firmware.

Yes, there are many things that can go wrong with the update process itself.  But save for actual hardware failure, there's no excuse for such failures to result in the device attempting to use the resulting corrupt firmware installation.   Even yanking the power in the middle of the update process should not cause the device to fail to boot from a good firmware image because there should be enough flash to hold at least two separate copies of the firmware.

I have few Siglent devices at my disposal and ones that I have do seem to say "verifying image" when doing upgrade.
I don't know what underlying OS /RTOS it uses and what is actual Firmware upgrade code.

Image verification should happen twice.  The first should be of the image on the USB stick.  The second should be of the image in flash after it's been written.

So instead of making this a bashing in all directions, I suggested to make it constructive:

Maybe a question to Siglent if they could make it more robust (not to use "foolproof" to insult more people),

Certainly this request should be made, but c'mon. Flash firmware upgrades have been a thing for at least a decade now.  If flash firmware upgrades were a relatively new thing such that the techniques were still being figured out, it might be understandable to see a problematic implementation.  But at some point, the way to do something becomes standard and obvious practice, and failure to adhere to that standard is clearly deserving of criticism.

and maybe being able to detect and reject USB sticks that doesn't work well...

Honestly, I don't understand this issue with USB sticks at all.  This ain't the early 2000's, you know, when USB sticks were just becoming a thing.  We're talking about a 20 year old technology here.  The standards are well-developed and well-known.  The filesystems are even older than that!   The filesystem code and the USB storage driver code has been around in open source form for about that long as well.   No, at this point, there is no excuse whatsoever for having limits on the size or formats (when the formats are one of the standards in use) of USB sticks that will work here.  FAT32 as a filesystem supports volumes up to 2 terabytes, and has been around since 1996.   So no, there is no excuse at all for being unable to deal with any USB stick of that size or less, save for when there's a hardware fault with the USB stick.

[2N3055]

Honestly, I don't understand this issue with USB sticks at all.  This ain't the early 2000's, you know, when USB sticks were just becoming a thing.  We're talking about a 20 year old technology here.  The standards are well-developed and well-known.  The filesystems are even older than that!   The filesystem code and the USB storage driver code has been around in open source form for about that long as well.   No, at this point, there is no excuse whatsoever for having limits on the size or formats (when the formats are one of the standards in use) of USB sticks that will work here.  FAT32 as a filesystem supports volumes up to 2 terabytes, and has been around since 1996.   So no, there is no excuse at all for being unable to deal with any USB stick of that size or less, save for when there's a hardware fault with the USB stick.

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.

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..

[kcbrown]

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.

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.

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..

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.

[2N3055]

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.

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.

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..

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.

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]

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,...

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.

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.

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.