I am working in a firmware upgrade "failsafe" feature for our hardware based on the ADSP-21469. We are using an SPI Flash to boot it, the device is the M25P80 from STm. The idea is to prevent the user from bricking the device, by having an older, functional copy of the current firmware. Under normal operation, the latest production firmware is loaded. If, under an upgrade, something goes wrong, you put the device into a special state where this older but functional firmware would be loaded and it would make the device recoverable. In our device, the concept is simple and would depend on the status of DPI09 pin, which is tied to a debounced switch.
- If you don't press the switch, normal firmware will be loaded from Sector 2 of SPI Flash (each copy of our firmware is 2 sectors long)
- If you turn on the device with the switch pressed (logic 1 in our circuitry), the older firmware will be loaded from Sector 0. Sectors 0 and 1 will never ever be rewritten during a firmware upgrade.
To test the concept of using the DPI pins during boot I made two little applications LED1 and LED2 which light up two different LEDs. They're written in C and all they do is put a DAI pin in high and loop forever. I've tested them and they work.
In the boot kernel I've decided to use the code from EE345 for SPI Flash using the 21469 and then mod it to read the status of the DPI09 pin. Unfortunately, as I debug the situation, it seem that the DAI/DPI pins are unusable during boot, so they're tristated and cannot be actually read. I'm actually using Method 1 / Approach 1 from this EE.
Here's the piece of code I've added to it:
SRU(LOW, DPI_PBEN09_I); // DPI Pin 9 is Input
SRU(LOW, DPI_PB09_I); // Good practice
SRU(DPI_PB09_O,FLAG4_I); // Tie input to FLAG4 input
ustat1 = FLAGS;
bit tst ustat1 FLG4;
if tf jump skip;
I do believe that the Second Stage Loader (Method 2) from the EE could solve this, but I'd rather get confirmation first.