Hello,
I am having consistent trouble with these SD cards (below).
About 5 of 7 write/verify cycles fail (or worse), for multiple new cards (>25 brand new cards tried). These are high reliability microSD cards, available from Digikey. So high confidence that there is not a problem with the card itself. Multiple SD to microSD adapters tried, as well as a different USB-SD interface.
Digikey part# 1582-1117-ND
AP-MSD256ISI-1T
Apacer Memory America
MEMORY CARD MICROSD 256MB SLC
Thank you
Hi there,
Welcome to the forums! Thanks for the feedback.
Could you share more information on your system? What OS are you using? What Etcher version?
What is the error Etcher is reporting?
Have you had any issues writing to these SD cards with other tools?
Sorry about all the questions, it’s important for us to have as much information as possible in order to diagnose the issue correctly. Thanks!
The error reported occurs after write and read back, and is ‘1 Failed target’.
Windows 10, I have been having trouble with this for some time, and verified it also happens on the latest 1.5.109.
Usually after about 5-6 attempts I can get a success.
Win32DiskImager never complains (but there is no verify step).
thanks
Since you tested on a lot of targets, it’s unlikely that they all reached EOL or are defective, but as you’re on Windows this might be the case of the OS creating an SVI folder when the flashing process switches from writing to verifying, which creates a short time-gap in which the drive’s content is modified by Windows. This creates the verification failure as the data read back from the drive has some added content that Etcher didn’t write.
You could try disabling SVI (if at all possible) and then trying again with the batch of sd cards you have
Thanks. It appears that following the procedure to disable SVI does increase the percentage of successful verifies significantly (>90-95%, but not perfect). It also disables Windows Indexing (search) which is unfortunate. And despite disabling it at startup it appears to restart again on its own after a reboot.
Maybe the right behavior would be for the application to disable it before the process and restore it after verification?
thank you.
It’s not a simple problem to resolve, but we have an issue open in Etcher’s repository: https://github.com/balena-io/etcher/issues/3197. In the meantime, the solution is to manually disable SVI