For production programming we have put together a batch script. The script is started from an USB Stick (autorun Folder).
First thing the script does is copying all needed files to the installed SD-Card because we noticed that some USB Drives do not have the needed stability for flashing. The updater.exe we are using is the one from the V1.7 Image.
Next we will clear the Registry and Flash the Bootloader and the Operating System (V1.7)
%tempdir% contains the path to the temporary folder on the SD-Card where the script placed all the files.
Usually this all happens without Problems. But sometimes update.exe freezes in the last step (flashing the configblock). It opens the progress Window but the Progressbar stays at 0% and update.exe never returns. There are no error messages or anything alike. The same USB Stick produces no problems on other devices.
This is a Problem because the script can not detect the failure and if we turn the Device of and on it wont boot anymore.
How can I prevent this Problem?
If I cannot prevent it: How can I detect it and automatically fix it?
I would still need to flash the splashscreen before the configblock. Because the splashscreen messes up some settings if I do it after the configblock. Also I have been told that I should flash the Filesystem first to make sure errorcorrection for the NAND is enabled.
Since this is nothing I can easily reproduce, enabling the debug output is not an option. This happens in our production line and they cannot operate the bootloader menu. I have never seen the fault when I tried the script.
I will soon receive some devices that have failed like this. Is there something I can check on them (besides trying to reproduce)?
Enabling the debug output would mean that I have to sit in the production line and do the programming. That is currently not possible (because of corona restrictions and other reasons).
But I can confirm that all Devices that have shown this error showed bad blocks when I did the “Repair-Flashing” from the bootloader. And also all of them complained about being unable to load the OS (even though flashing the OS did work). Would this behaviour support your theory?
But I found out that our production line was not using the latest production script. The script they were using would not do the reboot after flashing the os. As I learned from another thread this causes NAND error correction not to work. Could this be the root cause here?
Today I tried to reproduce the error on devices that I received from the line and that did show the error in the line. Even after hours of reflashing over and over again I was unable to reproduce the error to catch the logs.
I think the old image was still running and this would explain the issue you see.
Also it would explain why you’re not able to reproduce it with the new image 1.7