Boot Loader Validation

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

Reply to
raj
Loading thread data ...

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
Reply to
Thad Smith

Think ECU = Engine Control Unit (automotive)?

Reply to
Vic

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~

Reply to
Dave

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.