Verify bootloader has image download failure rate of less than 1 in 100 (Compact 7)
3/12/2014
This bootloader test performs 100 iterations of the following:
- Downloads the image to device
- Records the boot time
- Resets the device
The test creates and modifies three files in the release directory to store test data:
1. BootstressTotalRan.txt - number of times the device has been reset.
2. Bootstress.txt - contains the number of times the test is to run, as well as the reset-to-boot up times (in milliseconds) of each run.
3. BootstressLastTick.txt - contains the system time of when the system last rebooted. This is used to calculate the reset-to-boot up time.
Note: If you wish to abort the test, delete the BootStress*.txt files to stop your device from resetting on boot.
Test Prerequisites
Your device must meet the following requirements before you run this test.
- The creation of a special run-time image (described further below) that will automatically launch BootStress.exe during boot
- Platform Builder connection to the device (KITL)
Subtests
The table below lists the subtests included in this test.
| SubTest ID | Description |
|---|---|
1 |
Starts the test by initiating the first download-measure-reset iteration. Subsequent iterations will rely on BootStress.exe executing on boot. |
Setting Up the Test
There are two modules used by the boot stress test:
- DownloadStress.dll
- BootStress.exe
DownloadStress.dll is the Tux DLL that starts the bootloader test. It does so by setting up the appropriate files in the release directory, and resetting the device to initiate the download-measure-reset loop.
Once DownloadStress.dll resets the device to begin the test, BootStress.exe takes over as the primary test module and is executed during every subsequent device boot. It calculates and records the time elapsed since the last reboot until the executable is called again. In order to execute BootStress.exe on boot, a special run-time image must be created, as described below.
Using a flag in the build environment, "IMGBOOTTEST=1", BootStress.exe can be included in the run-time image by modifying the platform.bib and platform.reg files as follows.
1. Modify the platform.bib file to include Bootstress.exe:
IF IMGBOOTTEST
bootStress.exe $(_FLATRELEASEDIR)\bootStress.exe NK SH
ENDIF IMGBOOTTEST
2. Modify the platform.reg file to run Bootstress.exe at startup:
IF IMGBOOTTEST
[HKEY_LOCAL_MACHINE\init]
"Launch200"="bootStress.exe"
ENDIF IMGBOOTTEST
3. In your build environment, set IMGBOOTTEST=1.
4. Rebuild your image (ie. "Build->Make Run-Time Image" from Platform Builder, or "makeimg" from a build window).
Running the Test
1. Follow the steps in the "Setting Up the Test" section to set up the test.
2. Using Platform Builder, download the pre-built image to device.
3. Run "s tux -o -d downloadstress" from the Target Control window.
By default the test resets the device 100 times. You can modify the command line to specify number of times the device will be reset using the "-t" option.
For example, to reset the device 10 times, run: s tux -o -d downloadstress -c"-t 10".
Verifying the Test
In order to pass the test, the user should verify that bootStressTotalRan.txt indicates that the test performed the required number of reboots.
At the end of the test, a result summary is printed with the following format:
********************************
Reboot test Complete:
Boot Time for each reset:
257.715 seconds
214.736 seconds
Test ran 2 times
Average Boot Time = 236.00 seconds
Std Dev = 21.51 seconds (9.11%)
********************************
Troubleshooting the Test
If the test fails, open these two files in the release directory to get test run information.
1. BootstressTotalRan.txt - number of times the device has been reset.
2. Bootstress.txt - Boot time for each reset.
Check the bootloader output (using a serial cable, for example) for clues about what went wrong.
Note: If you wish to abort the test, delete the BootStress*.txt files from the release directory to stop the device from resetting on boot.
For additional platform specific issues, consult the CTK articles on the TechNet wiki.