Updatetool freezes when flashing config-block

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.

echo Clear Registry...
"%tempdir%\update" /cu

echo Write Bootloader
"%tempdir%\update" /u bootloader,raw,%tempdir%\eboot.img

echo Write Operating System
"%tempdir%\update" /u os,bin,%tempdir%\os.bin

After that is done we will reboot the Device

update /rc

After the Reboot the Script will start again and start Flashing the Registry, Filesystem, Splashscreen and Configblock.

echo Write Registry
"%tempdir%\update" /u registry,raw,%tempdir%\reg.ivr

echo Write Filesystem
"%tempdir%\update" /u filesystem,raw,%tempdir%\fs.ivf

echo Write Splashscreen
"%tempdir%\update" /u splashscreen,raw,%tempdir%\ss.dat

echo Write configblock
"%tempdir%\update" /u configblock,raw,%tempdir%\configblock.cfg

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?

What happened if you try to flash config block on a first step instead of last one?

Could you also enable debug output and collect logs for failed case?

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)?

I have a theory that this problem may be due to a lack of management of pre-existing NAND bad blocks, but logs are required to confirm this

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.

Dear @Troubadix75 ,

The problem you describe looks a lot like 2 BUGs from image 1.6 or older:




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