Bootloading over radio

I currently have 9 wireless temperature and humidity sensors around the house for testing purposes. If I need to update their software, I collect them and do the update with an ISP programmer and then put each back to their proper place. This is annoying, but still quite doable. However, I'll soon have around 20 sensors around the house, and some in the crawlspace and other hard to reach places. I thus started to think more about the logistics of deploying a software update.

Over the air software updates are the proper solution to the problem. The microcontroller I'm using has a dedicated bootloader section at the end of flash, to which the reset vector can be pointed at, as well as a facility to move the interrupt vectors there also. The plan is to have the bootloader send a packet to the receiver notifying it of the type of reset that has occurred, as well as battery voltage, application program version number and whether the CRC of the application area is valid. This is the command mode. The receiver will then respond by commanding the execution of the application program, by commanding the reprogramming of the application memory or by some other commands such as device address programming.

If the execution of the application program is requested, the bootloader restores the microcontroller to a state similar to that after a reset condition, and jumps to the original reset vector of 0.

Reprogramming the application memory is done page by page, where each page is 128 bytes. The bootloader requests a chunk of data indexed by the page and chunk indexes. When all chunks of a page have been received, the page is erased and programmed. When the entire application program area has been programmed, the bootloader returns back to the command mode.

I'm still somewhat unsure what to do with the possible changes in radio configuration (frequency, bitrate, bandwidth, modulation and so on). One possible solution is to store the radio configuration in EEPROM so that both the application program and bootloader can use the same settings. However, the bootloader needs to store a separate failsafe configuration if the configuration in EEPROM is incorrect.

There also needs to be a facility in the application program to get execution back to the bootloader. Here lies the biggest pitfall. If the application program misbehaves, it might be impossible to return to the bootloader without physically accessing the device. Proper testing should thus be done before submitting an update to devices in hard to reach places.