Chris:
I can see some value to the idea of loading a program from external serial mass storage device into the overlayed CODE/XDATA space that you propose for the external SRAM. I would not try to implement the scheme of turning off the internal "boot" code space onboard the chip. I believe there are some significant advantages of keeping an active page of code space with both the boot routines and other common core software drivers.

Another thing to consider is to use a serial SPI FLASH part for the dynamic code loading instead of a serial EEPROM. These FLASH parts are much faster data transfer rate and support huge sizes in to the megabytes. With this greater capacity you could have a whole array of different programs that could be loaded upon demand from various 64K byte sections of the FLASH part. These serial FLASH parts are available from companies such as Spansion, Winbond, Macronix and Numonyx.

The higher speed of these devices (33 or even 50 MHz clocking rates) used in conjunction with a hardware SPI peripheral on the microcontroller could allow for a rather decent performance dynamic code swapping into the SRAM.

One could also implement a similar scheme for those microcontrollers that have the onboard XRAM (often 8K maybe even 16K bytes in size). This would permit a nice system of code swapability but with smaller code module size whilst eliminating the need to implement the external memory part bus of the microcontroller.

Lastly let me comment that keeping the common base section of the code space may offer a more reliable recovery scheme when a watchdog timer is in use. The common code eliminates the need to duplicate the same handlers over and over in each of the various dynamically loaded program inages from the serial FLASH device.

Michael Karas