Устройство на ARM7S, связь с ПК - USB. Все usb-шные процедуры работают из RAM.
Програмка на ПК заливает по USB в ARM новую прошивку. Устройство перегружается и работает далее.
Я понимаю, что если в процессе заливки отрубиться питание, или комп зависнет, то дальнейшая работа устройства будет скорее всего невозможна. Но этот риск берет на себя покупатель.
В течение дня тестировал, ни одного сбоя. Но все таки неспокойно на душе.
Какие еще могут быть грабли? Ваши мысли по этому поводу.

У нас на плате стоит AT45DB. В ней выделен блок размером с прошивку минус бутлоадер. Вначале прошивка заливается в ДБ, потом перезагрузка с выставлением флага и перешифка основной прошивки бутлоадером. Пока нормально не перешьется - флаг не снимается. Так что выдергивать питание можно.

При загрузке всегда должен стартовать "нестираемый"/немодифицируемый бутлоадер, который в зависимости от каких-то условий загружает программу для модификации firmware или передает управление непосредственно самой firmware, если проверка ее целостности проходит нормально. В случае ошибки при модификации firmware МК всегда при включении будет "крутиться" в бутлоадере, ожидая загрузки корректной firmware.

С ARMами не работал, не знаю есть ли там защищенный бутовый блок. Если есть, то можно сделать 100% надежно. В противном случае при сбоях возможна потеря работоспособности.

Могу поделиться опытом обновления прошивки у прибора на MSP430F149. У него специальной бутовой области нет, таблица векторов жестко закреплена, внешней флешки в приборе не было. Внутренний масочный загрузчик использовал ножки, не совпадающие с UART-ом, а перепрошивать нужно было через UART. Сам загрузчик грузился по UARTу в ОЗУ и из него перешивал флеш. 100% надежное перепрограммирование сделать было невозможно.
Для уменьшения вероятности сбоя применил следующий трюк. Вся флеш перешивалась 1-2 минуты. Любой сбой в это время гробил программу. Поэтому прошивку сделал в три этапа:
1. Загрузчик из ОЗУ прошивает свою копию в два сектора флеша с таблицой векторов.
2. Перешивается вся флеш за исключением этих двух секторов.
3. Перешиваются два последних сектора (затирается копия загрузчика) и таблица векторов прикладной программы.
Суть в том, что теперь критичными к сбоям становятся только этапы 1 и 3, а их длительность всего 1-2 секунды по сравнению с общим временем апгрейда 1-2 минуты.

По крайней мере заказчики не жаловались (а устройство было достаточно серийным, бытовым). Видимо процент обращений в их сервис-центры по этой причине не превосходил обычных величин

Уже давно и неоднократно в этом форуме давались примеры реализации "перемещаемой" таблицы векторов для MSP430. Таблица векторов прерываний располагается в ОЗУ. Немодифицируемый бутлоадер при этом может быть расположен в том же секторе, что оригинальные вектора прерываний, т.к. необходимость модифицировать этот сектор отпадает.
Этот способ конечно же не дает 100% гарантии, но значительно, по сравнению с вашим, повышает надежность при модификации firmware.

У вас размер прошивки (с учетом "перспективки") превышает половину размера флеша ?

А я не претендую на истину в последней инстанции. Это просто мои пять копеек в копилку чужого опыта. Вы же не знаете всех обстоятельств той работы. А тогда меня попросили помочь разработать возможность перепрошивки firmware, когда флеш MSP430 была забита под завязку, и основной разработчик ногами запихивал нужную функциональность в память. На все про все мне могли дать пару сотен байт флеша Да и сроки поджимали, проклятое немецкое плановое хозяйство

Да, я понял, о чем речь.
Превышает, и намного.


А как на счет перешивки самого бутлоадера?

Для пользователя эта опция обычно недоступна. А разработчк (сервис, производитель) всегда имеет способ прошить что надо и куда надо.

На крайний случай поставьте на плату SPI FLASH или I2C EEPROM нужного размеру, благо цены на них сейчас смешные, и храните образ прошивки там. А "нестираемый" бутлоадер будет перетаскивать его на место основной прошивки.