Products > Test Equipment

Buyer Beware: Siglent Electronic Load

<< < (6/7) > >>

2N3055:

--- Quote from: RoGeorge on June 25, 2021, 04:07:04 pm ---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".   :(

--- End quote ---

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:

--- Quote from: nctnico on June 25, 2021, 01:09:41 pm ---
--- Quote from: 2N3055 on June 25, 2021, 12:52:02 pm ---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...

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

--- End quote ---

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:

--- Quote from: 2N3055 on June 25, 2021, 04:56:29 pm ---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.

--- End quote ---

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.



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

--- End quote ---

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.



--- Quote ---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),

--- End quote ---

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.



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

--- End quote ---

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:

--- Quote from: kcbrown on June 25, 2021, 08:32:01 pm ---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.

--- End quote ---

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:

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod