1. Если это возможно, сразу же после программирования неплохо бы убедиться, что обновление программы удалось. Это можно сделать, прочитав флэш-приложение, и сравнить результат с исходным файлом прошивки. Если вы не хотите, чтобы загрузчик выгружал прошивку, вы можете отправить загрузчику вашу прошивку два раза. Первый раз для записи, второй раз для того чтобы загрузчик сравнил с тем что только что записал. Конечно ни один подход не помогает если есть ошибки в канале связи или загрузчике. Большинство стандартных протоколов программирования поддерживают процедуру верификации, но такой подход не обнаруживает случайные искажения.
2. Перед тем как загрузчик начнет программирование, он должен удалить первую страницу приложения. Это позволит установить всю флэш-страницу в 0xFF. Затем прошивать страницы в обратном порядке от конца к началу. При запуске, загрузчик может проверить инструкции на правильность (обычно JMP или RJMP) по адресу 0, чтобы определить, все приложение было запрограммировано успешно. Этот подход, вероятно, потребует специального средства программирования, так как большинство стандартных средств не дают возможность обратного проектирования. Такой подход также не обнаруживает случайные искажения.
3. Вариант 2 прошивать все приложение как обычно, но резервировать последние несколько байт флэш-памяти для специального маркера, содержащий распознаваемый шаблон, например, 0xBEEF. Вы можете сделать это, изменив  шестнадцатеричный файл прошивки с таким инструментом, как srec_cat. Когда загрузчик запускается, он читает маркер байт, и если он находит правильное значение, то понимает, что приложение было записано правильно. Реализовать данный вариант можно с помощью стандартных инструментов программирования, при условии, что прошиваться программа будет с самого начала к концу (что, скорее всего так и будет, но тем не менее не гарантируется). Такой подход также не обнаруживает случайные искажения.
4. Более тщательный вариантом верификации является использование контрольных сумм CRC для проверки всего приложения каждый раз, когда  запускается загрузчик. Этот вариант похож на вариант 3 за исключением того, что вместо маркера в последних нескольких байтах прошивки хранится вычисленное значение CRC. Это также вы можете проделать это с помощью инструмента srec_cat. Не забудьте, учесть оставшееся в конце свободное пространство в разделе RWW, заполнив его смещением или чем-то еще. Когда загрузчик запускается, он вычисляет CRC используя тот же алгоритм CRC как и srec_cat. Это значение сравнивается с хранимым значением и если они совпадают загрузчик считает, что приложение является не поврежденным. Реализовать данный вариант можно с помощью стандартных инструментов программирования, при этом данный подход позволяет обнаруживать случайные искажения. Недостатком является то что задержка перед запуском программы увеличивается.
5. Если вы очень обеспокоены возможными искажениями, вы также можете производить проверку контрольной суммы  CRC  загрузчика согласно варианту 4. Конечно, не так много чего можно предпринять в случае обнаружения искажений, например, попытаться просигнализировать о проблеме и выключиться. В таком случае настает время задействовать программатор ISP.
6. Одним хорошим эффектом использования опции  перезагрузки, хранящейся в EEPROM (обсуждается в вопросе № 10) является то, что данный подход также способен обеспечивать автоматическое обнаружение искажений. Если приложение было записано наполовину или повреждено, оно не получит возможность установить байт APP_RUN и загрузчик будет продолжать исполняться при следующей перезагрузке. Вместо того чтобы искать искажения в приложении, этот подход позволяет оценить неудачное исполнение приложения как проблему. В некотором смысле это даже лучше, чем проверка CRC, потому что на самом деле CRC может быть вычислен у уже испорченного еще задолго до заливки образа прошивки. Конечно, подход с применением EEPROM не является идеальным, поскольку в приложении могут иметься небольшие искажения и сбой может возникнуть после того, как оно запишет байт APP_RUN.

.section .jumps,"ax",@progbits
// The gnu assembler will replace JMP with RJMP when possible
.global _jumptable
_jumptable:
    jmp shared_func1
    jmp shared_func2
    jmp shared_func3

JUMPSTART = 0x3FE0 # 32 bytes from the end of the AT90USB162 4kb boot section
LDFLAGS += -Wl,--section-start=.jumps=$(JUMPSTART)

LDFLAGS += -Wl,--section-start=.text=0x3000

BOOTSTART = 0x3000 
LDFLAGS += -Wl,--section-start=.text=$(BOOTSTART)

Может ли загрузчик обновлять значения фьюзов?

С AVR это невозможно. Для этого вам потребуется внешний программатор.

 Как прошить загрузчик для микроконтроллеров?

Так как загрузчику не просто обновить самого себя, а приложения практически никогда не изменяют загрузчик, то вам потребуется внешний программатор для записи загрузчика в микроконтроллер. В качестве примера программаторов можно привести STK500, AVRISP, AVR Dragon, JTAGICE MKII и т.д. Режимы программирования вы будете задавать в зависимости от вашего типа AVR. Вам не нужно делать ничего особенного, чтобы прошить в микроконтроллер загрузчик. Если у вас есть рабочий внешний программатор, который может заливать прошивки и менять фьюзы, то он вполне подойдет и для заливки загрузчика. Программатор просто читает файл прошивки с загрузчиком и записывает его по указанному адресу. Программатору все равно, что вам посчастливилось писать в область NRWW флеш-памяти.

Как прошить сразу приложение и загрузчик?

Так как, надеюсь, вы создали отдельно приложение и загрузчик отдельно, то в конечном итоге у вас появится два отдельных шестнадцатеричных файла с прошивками (например, app.hex и boot.hex). Возникает вопрос: как залить их обе в AVR. Существует несколько вариантов:

srec_cat app.hex -I boot.hex -I -o combined.hex -I

Также вы можете вручную объединить файлы app.hex и boot.hex файлов с небольшими правками:

Можно ли в загрузчике использовать прерывания?

Да, для этого достаточно сказать процессору, чтобы тот использовал вектор прерываний, расположенный в области загрузчика а не в области приложения. Для этого где-то в начале кода загрузчика (до использования прерываний), надо добавить строки вроде этих:

MCUCR = (1<<IVCE);
MCUCR = (1<<IVSEL);

После чего во время прерываний программный счетчик будет переведен в соответствующее положение согласно таблице прерываний загрузчика. Для нормальной работы, приведенная выше последовательность кода должна быть скомпилирована с включенной оптимизацией, также вручную требуется удостовериться, что в результирующую сборку записаны команды, выполняемые за 4 машинных цикла.

Что должно загружаться в первую очередь — загрузчик или приложение?

Для лучшей работы загрузчиков необходимо чтобы они представляли собой небольшие, надежные и редко изменяемые программы. С того дня как вы отправили свое устройство в эксплуатацию вам действительно больше не захочется изменить на нем загрузчик. Приложение же наоборот требует больше свободы в плане обновления. Если в приложении возникает ошибка, приводящая к отказу или зависанию, или во время заливки прошивки произойдет сбой питания надежный загрузчик, который будет запускаться первым сможет без проблем исправить данную ситуацию.

Как узнать загрузчику когда запускать приложение?

Есть много возможностей. Если устройство имеет кнопку или другой механизм ввода, вы можете послать соответствующий сигнал нажатием. Тогда загрузчик, как правило, запустит приложение сразу. А в случает если кнопка будет не нажата во время сброса, то загрузчик продолжает исполнение. Это пример того как работает загрузчик чипа STK500.

// Bootloader code
const uint8_t app_run = eeprom_read_byte(ADDR_APP_RUN);
if(app_run == APP_RUN)
{
    // In case the app is faulty, clear the eeprom byte so that
    // the BL will run next time. A properly running app should
    // set this back to APP_RUN.
    eeprom_write_byte(ADDR_APP_RUN, 0xFF);
    run_application();
}
// Only run the bootloader once, then go back to the app
// (comment out the next line during app development)
eeprom_write_byte(ADDR_APP_RUN, APP_RUN);

Затем где-то подальше в приложении, в той части кода, при обработке которого вы уже точно уверены, что приложение работает правильно добавьте следующее:

// Application code
eeprom_write_byte(ADDR_APP_RUN, APP_RUN);

Это работает следующим образом: если приложение было с успехом исполнено ранее, то загрузчик будет читать
байт APP_RUN подготавливать к переходу к исполнению приложения. Однако незадолго до запуска приложения байт APP_RUN очищается. Приложение затем снова пишет байт APP_RUN в тот момент когда она считает, что она работает правильно. Таким образом последовательность повторяется. Если с приложением до сброса произошел сбой до того момента как оно производит сброс байта APP_RUN, то после перезагрузки загрузчик будет оставаться на исполнении. Если вы закомментируете указанную выше строку в коде загрузчика, то загрузчик будет оставаться на исполнении только один раз, а в следующие разы после сброса будет запускать приложение.

Как загрузчик запускает приложение?

Существует на самом деле только один способ, вы должны переместить программный счетчик в начало приложения (которое, как правило, является вектором сброса). Если у вас есть приложение на основе
обычной библиотеки AVR-Libc, то в начале вашего приложения будет расположен рантайм языка с, который инициализирует стек и глобальные переменные, а затем располагается ваша функция «main». Вы можете переместить счетчик программы с помощью ассемблерной команды jump или вызовом функции, расположенной по нулевому адресу. Я выбрал команду jump:

asm("jmp 0000");

Disable_interrupt();
Wdt_change_16ms();
while(1);

Disable_interrupt();
// Shutdown USB cleanly
Usb_detach();
Usb_disable();
Stop_pll();
// Put interrupts back in app land
MCUCR = (1<<IVCE);
MCUCR = 0;
// Run the applicat

Продолжение: AVR BootLoader в вопросах и ответах. Часть 2