Boot Loader Validation

Apr 10, 2006 3 Replies

Boot Loader Validation


Hai all,



We want to do a Boot Loader Validation for an ECU



In our process we first use to flash the Boot Loader and fallowed with application code and calibration File.



Presently we want to validate the Boot Loader under different circumstance as follows (for XC164cs)



Proposed test scenarios



Repeat 'download file to flash' after the performing these cases



  1. Break the CAN Communication at different sector boundaries and mid of the sector


  1. Break the CAN communication after and before downloading the first



128 bytes.


  1. Stretch the inter message period (i.e., the time gap between two messages) for different values (trying between 2 ms to 100ms)

  2. Short the CAN bus for less than 1 sec a) after 29 sec b) before

500ms c) between 1 sec to 29secs


  1. Short the CAN bus for above 5 sec a) after 29 sec b) before 500ms c) between 1 sec to 29secs

  2. Transmit commands 'Connect', 'Unlock' more than one time and try to download the application.


  1. Try with different code sizes - with code of maximum possible size of the Micro and beyond the size.

  2. Check the boot software performance at different voltage levels.


  1. Recycle the ignition while downloading the application.

  2. Recycle the power while downloading the application.


  1. Recycle the power after Connecting/unlocking the ECU i.e., before flashing the code.

  2. Recycle the ignition after Connecting/unlocking the ECU i.e., before flashing the code.


  1. Change the data of locations '0xC1FFFE- 0xC1FFFF' i.e., corrupting the valid application information

  2. Repeat the 'download file to flash' for 50 to 100 times.

Can any one please give your experiences in Boot Loader validation and additional points regarding which i should be through with Precautions to be followed while doing?



Thanking You all raj



OK. What's an ECU?

...

I don't have experience with boot loader exhaustive testing, but you have a pretty good list of tests. Although you had "break communications", I didn't see bit corruption within a single packet listed.

Do you have RFI / voltage spike conditions?

One of the things you may want to do is list the possible failure modes, such as

1) hangs until reset 2) hangs forever 3) loads incorrect code and runs it undetected 4) has holes in programming 5) incomplete programming

You have enough combinations of failure modes that you might want to consider coding the download driver to have random decision points before each transaction item. Have it perform the correct operation with high probability, but perform some deviation, such as skipping a step, inserting a delay, corrupting the output, or repeating a step / series of steps with some small probability. You can then run hundreds or thousands of different tests. Have a way to automatically detect a failure and a way to record the sequence that led up to any detected failure.

Thad

Think ECU = Engine Control Unit (automotive)?

You shouldn't be flashing a new bootloader. If the power fails (or is disconnected--you might be surprised what happens in car dealerships!) after erasing the flash, your box is dead. If it is typical of most auto hardware, it is not recoverable.

~Dave~

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required