Я делал так:
Отдельно заливал бутлодер, настраивал контроллер так, чтобы он всегда с него грузился. Дальше возможно два варианта - либо по состоянию какой нибудь ноги контроллера определять, хочет ли пользователь, чтобы работал загрузчик, или же выходить в основную программу. Другой вариант - ожидание внешней команды (например, мой загрузчик работал по USART, и в течении 100 мс ждал команды, а затем уходил в основную программу, если команду не получил). В данных вариантах даже если загрузчик не сможет полностью обновить прошивку из за сбоев, всегда будет работать первым бутлодер (если конечно он сам не повредиться, за этим лучше следить либо в нём самом, либо защитить его лок-битами)

Вариантов решения Вашей задачи достаточно много: приведу 1.
Лучше делать 2 проекта:
1. BootLoader
2. USER proram

Boot естественно размещаете в секции Boot, USER с адреса 0x0000. В секции векторов прерывания ставие
jmp на соответствующие адреса секции USER, кроме USART-a (он исп-ся для закачки програамы USER)
Старт на BootrLoader - он настраивает USART и разрешает прерывания от него, инициализирует свои
переменные (min 16-20 ячеек RAM ими придется пожертвовать в USER а если USER уже написан, то поскать в нем). После инициализации BootLoader отдается USER-у на адрес 0x0000. При замене программы USER -
дергаете USART - преравание от него попадут BootLoader-у и он обработав его на всякие ошибко и
пароли вернется не к USER-у а в свой main и тогда весь RAM будет в его распоряжении. Дальнейшее -
дело техники и Вашей фантазии.

Как-то закручено и неестественно получается.
Почему бы просто не выставить фуз BOOTRST, а вектора переключать в BOOT секцию с помощью бита IVSEL. Получатся два абсолютно независимых проекта.
Из BOOT'а в основную программу переходить - jmp 0x0, наоборот (из USER в BOOT) - по WDT сбросу.
Сигналить из основной программы бутлоадеру о наличии обновленной прошивки через оговоренную ячейку EEPROM.

>Как-то закручено и неестественно получается....
>фуз BOOTRST
Вот те раз - закручено, а по-моему так прще простого.
Я же написал: Старт кристалла на BootLoader - это и подразумевает установку BOOTRST.
А вот где держать вектора: здесь понятно 2 варианта в USER секции или Boot секциии,
если нет иасходников на USER а только hex файл прошивки, тогда ес-но в Boot, если же есть исходники,
то можно и в USER (выгадываем на каждом вызове прерывания время на лишний jmp).
В конце концов USER инициализируется после BootLoader - он решит где их размещать.
Но не делать же 2 вариана Boot - так получится один унмверсальный. Преимущество моего способа
в том, что USER не обязан знать о существовании BootLoader-a кроме выделения для него нескольких
адресов RAM (это можно делать в файле конфига линкера), кроме того не требуется лишних pin-ов
на кристалле для определения "куда стартовать"

>Из BOOT'а в основную программу переходить - jmp 0x0, наоборот (из USER в BOOT) - по WDT сбросу.


Можно и так, если конечно USER сам знает когда делать обновление, хотя можно обойтись и jmp на старт Boot
Если же все идет от оператора то переход из USER в BOOT см. мой порст выше - по рывку за USART!!!

>Сигналить из основной программы бутлоадеру о наличии обновленной прошивки через оговоренную ячейку EEPROM.
А вот это ради Бога - я же написал "тут дело техники и Вашей фантазии"

Ваш способ имеет право на жизнь. Но - выделить несколько адресов RAM, держать "в уме" что один из векторов "обслуживается" другим проектом - это есть зависимость одного проекта от другого... На мой взгляд проекты BOOT/USER надо строить полностью независимо друг от друга.
Насчет пинов, лишних пинов BOOT'у не нужно, а когда понадобится нечто вроде HW write-protection'a или HW реквеста обновить прошивку можно пользовать пины с ISP разъема, например MISO/MOSI.

BOOT по минимуму должен уметь:
a. Прошивать.
b. Проверять то, что прошил.
c. запускать то, что прошил.

USER:
По минимуму должен работать одинаково как с прошитым BOOT'ом, так и без него.

Я бы добавил :
0. Проверять имеющееся приложение перед тем, как на него перейти.

Это комбинация пунктов "b" и "c"