DFU bootloader это загрузчик, который поддерживает обновление firmware устройства (такая процедура известна как Device Firmware Update, сокращенно DFU). С помощью DFU можно обновить приложение, двоичный код SoftDevice или даже текущий загрузчик.

В момент первоначального запуска активности MCU (startup), что происходит при включении питания или сбросе, код DFU bootloader проверяет наличие в памяти устройства корректного кода приложения. Если такое приложение не найдено, то bootloader переходит в режим ожидания загрузки (DFU mode) и инициирует передачу данных образа необходимого кода (firmware image). Если корректный код приложения при старте найден, то DFU bootloader запускает приложение, если не указано явно перейти в DFU mode (например, удержанием кнопки при включении питания).

После входа в DFU mode, код DFU bootloader инициализирует модуль транспорта (DFU transport module), который отвечает за прием/получение нового firmware image. Этот образ затем проверяется на корректность, копируется в правильную область памяти, и активируется для использования после перезапуска устройства.

[Процесс обновления]

Для проведения процесса Device Firmware Update необходимо наличие двух устройств: DFU target и DFU controller. DFU target это устройство, которое обновляется новым кодом firmware image (в этом образе может содержаться новое приложение, двоичный код SoftDevice, загрузчик, либо комбинация SoftDevice и загрузчика). DFU controller это устройство, которое передает этот образ. Например, в качестве DFU controller может выступать мобильный телефон, с соответствующим работающим приложением, либо nRF5 Development Kit в объединении с nrfutil.

На устройстве DFU target запускается код загрузчика (DFU bootloader). Если загрузчик перевел устройство в DFU mode, то загрузчик ожидает выполнения процедуры Device Firmware Update. Затем DFU controller может инициировать передачу образа firmware, который принимается и проверяется загрузчиком. Если проверка образа показала его корректность, то устройство сбрасывается и копирует образ, чтобы заменить существующее firmware. В зависимости от типа образа может быть заменено приложение, SoftDevice, или даже текущий загрузчик, который принимает обновление. См. далее раздел "Обновления dual-bank и single-bank" для подробной информации о том, где образ сохраняется и как копируется.

В качестве DFU используется утилита nrfutil (версии 1.5.0 или более новая), либо соответствующее мобильное приложение Nordic. Модули bootloader могут использоваться для реализации DFU target. На следующей диаграмме рис. 1 показаны необходимые шаги для обновления firmware, которые должны быть реализованы в загрузчике на DFU target:

Рис. 1. Алгоритм работы DFU target.

События и процедуры процесса обновления ничего не знают об используемом транспортном протоколе, по которому передается образ. Таким образом, можно выполнить обновление firmware, используя любой выбранный транспорт (см. DFU transport [2]) для передачи образа. DFU controller может активировать события обновления путем отправки соответствующего сообщения через транспорт DFU.

[Настройки загрузчика]

Текущее состояние процесса DFU сохраняется на специальной странице настроек загрузчика (bootloader settings page), которая физически находится на последней странице доступного хранилища FLASH (см. распределение памяти [3]).

Информация на странице настроек загрузчика используется, чтобы определить правильное действие после сброса устройства:

• Если образ firmware был передан, он должен быть проверен и скопирован.
• Если приложение установлено, то его контрольная сумма CRC-32 сохраняется на странице настроек. Если сохраненное значение CRC-32 соответствует актуальному приложению, то приложение должно быть запущено. Иначе считается, что приложение было изменено или повреждено, и устройство должно остаться в DFU mode.
• Если никакое приложение не установлено, или отсутствует страница настроек, то устройство также должно остаться в DFU mode.

Страница настроек загрузчика также может использоваться для сохранения информации, которая должна сохраняться между процедурами обновления - например, номера версий firmware, серийный номер и т. п.

[Проверка образа firmvare]

Перед осуществлением Device Firmware Update новый образ должен быть проверен. Некоторая информация (например о совместимости) может быть проверена перед актуальной передачей образа firmware (предварительная проверка, prevalidation). Другая информация, например хэш образа, должна быть проверена после передачи образа (postvalidation).

Предоставленный пакет firmware должен включать образ firmware и init-пакет, который можно использовать для предварительной проверки (prevalidate) образа. Формат init-пакета и процесс актуальной проверки определяется реализацией DFU bootloader. См. описание Init packet [4] для документации по используемой проверке в примере BLE Secure DFU Bootloader [5].

Для обеспечения совместимости проверка образа, validation (которая входит в загрузчик DFU как часть его реализации) и создание образа (обычно реализованное с помощью внешней утилиты) должны использовать одинаковый формат init-пакета. Удобный способ обеспечить общий формат - определить требуемое содержимое init-пакета в файле буфера протокола (protocol buffer file). С таким методом формат пакета может быть определен один раз, и затем использоваться в разных местах. Пример реализации см. в BLE Secure DFU Bootloader [5].

Компания Nordic предоставляет утилиту командной строки nrfutil [6] для создание пакетов firmware с init-пакетом, определенном в файле буфера протокола. См. раздел "Creating a firmware package" в статье [5] для получения информации о том, как использовать nrfutil для создания пакета firmware, совместимого с примером BLE Secure DFU Bootloader. Если Вы поменяете формат init-пакета в своей реализации DFU bootloader, см. документацию nrfutil [6] для получения инструкций о том, как обновить утилиту. Альтернативно Вы можете создать свою собственную утилиту для создания пакета firmware.

[Обновления dual-bank и single-bank]

Чтобы безопасно выполнить обновление DFU, новый образ firmware не должен сразу копироваться в конечное место назначения, пока не будет проверен. Это даст гарантию, что будет активирован только полный и допустимый образ кода. Если во время пересылки образа произошла ошибка, то firmware не должно обновляться.

Такой процесс сохранения принятого firmware в свободную память, и последующего копирования в конечное место назначения для активации называется обновлением dual-bank. Обновления dual-bank является предпочтительным методом обновления, потому что текущее приложение остается в целости до тех пор, пока не будет проверено и активировано новое firmware.

Обновление dual-bank возможно только в том случае, когда имеется достаточно свободного места между концом текущего приложения и началом данных приложения и началом данных приложения, чтобы можно было сохранить образ нового firmware. Если новый образ firmware больше, чем имеется свободного места, то тогда этот новый образ должен передаваться в режиме обновления single-bank. При этом образ firmware сразу перезаписывает существующее приложение. Если в этом процессе произойдет ошибка, в устройстве не останется рабочего приложение, потому что старое приложение будет затерто. В этом случае устройство останется в режиме DFU, и может быть повторена попытка обновления.

Все обновления firmware выполняются, если это возможно, в режиме dual-bank. Однако, если новый образ (SoftDevice, SoftDevice + bootloader, или приложение) больше, чем доступное свободное пространство, то приложение удаляется, чтобы освободить место для образа firmware, и обновление выполняется в режиме single-bank.

По соображениям безопасности Вы можете запретить обновления single-bank в конфигурации DFU (см. описание функции nrf_dfu_find_cache). Однако запрет обновлений single-bank ограничит объем, который может быть обновлен, количеством свободных страниц между приложением и зарезервированной областью данных приложения. Это свободное пространство по размеру должно быть достаточным для комбинированного обновления SoftDevice + bootloader.

[Обновления dual-bank]

Во время обновления dual-bank существующее приложение сохраняется в целости до тех пор, пока не будет активирован новый образ firmware. Если обновление firmware по какой-то причине завершилось с ошибкой, то все равно остается возможность перезагрузить устройство и запустить существующее старое приложение.

Область памяти между концом SoftDevice и началом данных приложения делится на 2 банка, Bank 0 и Bank 1. Bank 0 содержит существующее приложение, Bank 1 используется для сохранения принимаемого образа.

SoftDevice + bootloader. На следующем рисунке показан процесс DFU для комбинированного образа, содержащего загрузчик и SoftDevice. Если переданный образ содержит только SoftDevice или только bootloader, весь процесс тот же самый, но может быть заменен только SoftDevice или только bootloader.

Рис. 2. Операции DFU с памятью FLASH для dual-bank обновления кода SoftDevice и/или кода bootloader.

Передаваемый образ сохраняется в свободной области памяти. Существующие данные приложения могут быть сохранены, см. далее раздел "Обеспечение целостности данных приложения". После проверки новый SoftDevice и новый bootloader копируется для замены существующего firmware. Во время этого процесса код приложения остается нетронутым, но это приложение может оказаться несовместимым, если поменялось API в SoftDevice, или если размер нового SoftDevice отличается от существующего.

Приложение. При обновлении приложения в режиме dual-bank существующее приложение сохраняется до последнего момента, пока не будет обеспечена гарантия целостности загруженного нового образа приложения.

Рис. 3. Операции DFU с памятью FLASH для dual-bank обновления кода приложения.

Оригинальное приложение находится в банке памяти Bank 0. Передаваемый образ сохраняется в Bank 1. После того, как образ нового приложения был принят, в памяти находятся сразу 2 образа приложения. Это дает гарантию, что можно будет запустить старое приложение, если новое приложение не может быть активировано. Если новое приложение может быть активировано, то оно копируется из Bank 1 в Bank 0. Существующие данные приложения могут быть при этом сохранены, для дополнительной информации см. далее раздел "Обеспечение целостности данных приложения".

[Обновления single-bank]

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

DFU bootloader проверяет, можно ли выполнить обновление в режиме dual-bank. Переключение в режим single-bank произойдет только тогда, когда обновление в режиме dual-bank невозможно (из-за нехватки свободной памяти).

Существующие данные приложения могут быть при этом сохранены, для дополнительной информации см. далее раздел "Обеспечение целостности данных приложения".

SoftDevice + bootloader. На следующем рисунке показан процесс DFU для обновления кода SoftDevice и/или кода загрузчика в режиме обновления single-bank.

Рис. 4. Операции DFU с памятью FLASH для single-bank обновления SoftDevice и/или bootloader.

Существующее приложение будет стерто, чтобы освободить место для нового образа firmware. После проверки новый SoftDevice и/или новый bootloader копируется в свое место назначения, чтобы заменить существующий код. После этого устройство перезапускается и входит в режим DFU, потому что в памяти нет приложения (его можно будет теперь загрузить).

Приложение. На следующем рисунке показан процесс DFU для обновления в режиме single-bank.

Рис. 5. Операции DFU с памятью FLASH для single-bank обновления кода приложения.

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

[Обеспечение целостности данных приложения]

Данные приложения наподобие информации BLE-привязки (bonding information), системные атрибуты, или любые данные, которые приложение хотело бы сохранить между моментами сброса, должны оставаться в сохранности по время процесса DFU. Для этого такие данные должны находиться в специальной области памяти, между приложением и загрузчиком, сразу перед началом загрузчика. Это место по умолчанию, которое использует модуль Experimental: Flash Storage [7]. Поэтому если Вы хотите использовать fstorage для сохранения данных своего приложения, то не нужно менять конфигурацию fstorage. Однако по умолчанию размер этой секции памяти устанавливается в 0, это значит, что данные приложения не сохраняются.

Чтобы во время DFU данные приложения не повредились, сконфигурируйте значение DFU_APP_DATA_RESERVED в заголовке nrf_dfu_types.h. По умолчанию резервируется 3 страницы FLASH:

#define DFU_APP_DATA_RESERVED    CODE_PAGE_SIZE * 3

Значение DFU_APP_DATA_RESERVED должно нацело делиться на размер в байтах страницы используемого микроконтроллера, например 0x0400, 0x0800, 0x0C00, и так далее, для размера страницы 0x0400 байт.

Примечание: 0x0400 байт размер страницы для чипов семейства nRF51. У чипов семейства nRF52 размер страницы в 4 раза больше, 0x1000 байт).

[Ссылки]

1. nRF5 SDK v12.3.0 DFU bootloader site:infocenter.nordicsemi.com.
2. nRF5 SDK v12.3.0 Bootloader modules DFU transport site:infocenter.nordicsemi.com.
3. nRF5 SDK v12.3.0 Bootloader modules Memory layout site:infocenter.nordicsemi.com.
4. nRF5 SDK v12.3.0 DFU bootloader examples Init packet site:infocenter.nordicsemi.com.
5. nRF5 SDK v12.3.0 BLE Secure DFU Bootloader site:infocenter.nordicsemi.com.
6. nRF Util.
7. nRF5 SDK Flash Storage.
8. Запуск Nordic Secure DFU bootloader.