Another consideration to make in a product design is whether you need to have some type of indication on the product that it is in boot loader mode. Do you commit an LED to this, support some displauy on the LCD?

The scheme I use most often is one where I give multi-duty to one of the normal product LEDs that operates in a typically static manner. A power on LED is a good example. I then implement a system of critical state and error reporting for the product that uses this LED in a flashed manner. I'll setup states such as a series of long flashes followed by short flashes. After each flash sequence there is a dead time followed by a repeat of the state being shown.

This "critical_state" flash scheme can be implemented via a simple state machine triggered from a timer interrupt. If it is used for showing that the state of both the boot loader and the application then it is necessary to implement the code to drive it in both places.

I typically will let codes that start with one long flash be boot loader notifications and those from the application be ones that start with two or three long flashes. Here is an example:

Long Short
  1    1      System in mode waiting for host down loader program to talk to it.
  1    2      Application CRC failed. Waiting for host down loader program to start.
  1    3      In active boot loader reprogramming mode - host downloader is talking.
  2    1      EEPROM configuration database is corrupt.
  2    2      USB port Enumeration Failure
  2    3      Unit temperature sensor reporting over temperature for safe operation.
  3    1      Magnetic hall sensor failed (reporting A/D voltage outside normal range).
  3    2      ..you pick your next notification.

I have learned from practical experience that five pulses (either long or short) is a limit for reasonable detection by most users. I have also found that it is essential to not try to pulse out the flashes too fast.

Michael Karas