We installed the Toradex 2.1 WEC7 image. We’ve added customizations for SDIO8787 driver, registry settings, IP address and some additions to the file system. This image works on the unit, and we can re-boot and everything works.
I create a backup to USB stick by running Updatetool 2.0.14 from the USB stick, and save to the USB stick a complete backup.
If I try to restore this image using Tegra Winceflash2.3, or UpdateTool-2.0.14, the image doesn’t boot. It does a stack dump. See attached picture for the startup. I’ve tried another USB stick and that didn’t work. I also eliminated the USB HUB from the backup step in case of a problem with the USB data loss issue. Neither of those things worked.
Thank you for contacting support and detailed debug output information.
It seems backup bootloader files are corrupted. Could you please compare two bootloader files and let us know if you find any difference? or Could you please share all the backup files with us and let us see what went wrong. Please upload all files in https://share.toradex.com/ and post the link here.
Note that I can restore this image with NVFLASH2.2 on the Toradex developer kit and it works, but it does not work with NVFLASH2.3. It also doesn’t work with WEC7 Updatetool_6.0.14.
Also, we are setting one item in the config block to enable USB01 as host (enable power on USB regulator). Something like [apalispin_274] altfn=-1 dir=out lvl=1. I’m not sure if the config block could have something to do with this, but I thought it was worth mentioning.
I also changed the config to just flash the registry, OS, and filesystem. Something went wrong, but it looks like I may have triggered a factory default BCT along the way?
On the same Apalis T30 module, I can now flash my package with NVFlash2.3. Could there be something wrong with how the BCT is generated in NVFLASH 2.3? Or is there some config settings I have to set to select the module type?
I am migrating from WEC7 Apalis T30IT 2.1b2 or 2.1b4 to 2.1release. I probably used NVFLASH 2.2 or 2.0 to flash WEC 2.1b2/4 from the factory Linux programming.
I read back the BCT areas of two modules using NVFlash 2.3. One module now works with NVFlash2.3, and the other produces the stack dump shown above. I’ve attached the BCT as a zip file in case there are some clues there to assist.
The bootloader and bootloader2 files in my backup package attached above produce the same MD5 checksum, so they must be the same.
MD5: 136d20e06b83740d78d75dee18f541cb
using the default.bct in 6.0.14 didn’t work updatetool /u default.bct
I am wondering now if the updatetool auto-detect is detecting this wrong module type and overwriting with the wrong values? Does default.bct have to be in the same folder as the update tool? In the 6.0.14 package, it’s in the root folder?
This is a problem relating to ConfigBlock backup and restore.
-install 2.1 WEC7 image
use ConfigBlockEditor to add the following to end of GPIO section: [apalispin_274] altfn=-1 dir=out lvl=1
then setconfig,saveconfig.
Use 6_0_14 update tool to do a full backup. Use NVFlash or UpdateTool to update from 2.1 original image, to one containing the Configblock ARG area.
Stack dump occurs. If I remove the ConfigBlock ARG area from the .cfg, the stack dump doesn’t occur. Also, if you use older 2.2 NVFlash, this doesn’t occur. Seems to be related to latest update tools and ConfigBlock.
We found an issue with in the nvlash loader. The problem was caused by the gpio.bootconf section.
If you use NVFlash to programm your image: Just use the latest nvflash package and replace the loader.nb0. Get the 1.5b1 loader from here.
In case you use the Update Tool replace the following two DLLs in the Update Tool folder. This is the CE 7 version. Get the two fixed DLLs from here.
We will do some more testing intarnally and then will release a new Update Tool boundle and NVFlash Version. Please also provide us some feedback if the fixes solve your issue.
