Практика работы с BlueNRG-LP: спящий режим, UART, обновление ПО

26 февраля

системы безопасностиучёт ресурсовсветотехникаинтернет вещейST Microelectronicsстатьяинтегральные микросхемыбеспроводные технологиисредства разработки и материалыBLEBluetooth2400 МГцIoTинтернет вещей

Софья Букреева (г. Протвино)

Компания STMicroelectronics представляет новую микросхему SoC BlueNRG-LP со встроенным микроконтроллером Cortex®-M0+ и приемопередатчиком BLE, которая имеет широкий набор аппаратных и программных возможностей для создания малопотребляющих Bluetooth-устройств, способных производить обновление своего программного обеспечения разными способами. В данной статье мы рассмотрим режимы пониженного потребления, процедуру обновления прошивки по эфиру с помощью специального BLE-сервиса и особенности работы UART-загрузчика с функцией защиты памяти.

Реализация спящих режимов в BlueNRG-LP 

Аппаратные методы снижения потребления: режимы Deepstop mode и Shutdown mode

Для снижения потребления микросхема BlueNRG-LP имеет два аппаратных режима: Deepstop и Shutdown. Режим Deepstop позволяет сохранить содержимое ОЗУ и после пробуждения продолжить работу приложения. В этом режиме останавливается тактирование системных шин, остается минимальное питание VDD12o = 1 В, которое позволяет сохранить содержимое памяти RAM0 (16 кбайт), остальные области ОЗУ (RAM1-3) могут быть также сохранены, в зависимости от программной конфигурации микросхемы. Тактирование низкой частотой LSE или LSI может быть включено, в этом случае таймер/счетчик RTC, сторожевой таймер IWDG и радиомодуль BLE остаются активными и используются для пробуждения микросхемы из режима Deepstop. Вне зависимости от тактирования низкой частотой, вывести микросхему из режима можно также подачей импульсов на выводы PA0-PA15 и PB0-PB11. Кроме этого, данный режим позволяет использовать 8 выводов PA4-PA11 для установки постоянного уровня 0 или 1, для вывода низкой частоты или в качестве выхода RTC. После пробуждения необходимо дождаться стабилизации генератора высокой частоты, источник пробуждения можно найти в регистре контроллера питания (PWRC).

Режим Shutdown – это режим с наименьшим потреблением, при котором прекращается подача питания на все стабилизаторы микросхемы, останавливается тактирование, в том числе низкой частотой, и отключается радиомодуль. В режим Shutdown можно войти после исполнения определенной последовательности команд, а единственный способ выхода из режима – подать импульс на вывод сброса микросхемы.

Программная поддержка пониженного энергопотребления в программном пакете BlueNRG-LP DK

В программном пакете BlueNRG-LP DK (STSW-BRNGLP-DK) доступно программное обеспечение (ПО) для поддержки обоих аппаратных режимов пониженного потребления BlueNRG-LP. В предлагаемом ПО запросы на малое потребление согласовываются с активностью на радиолинии, таким образом подбирается наилучший режим по потреблению в текущий момент работы и предотвращается потеря данных. Кроме этого, в этом ПО реализована процедура сохранения настроек и восстановления после выхода из режима малого потребления. Таким образом, после пробуждения микроконтроллер выполняет инструкцию, следующую после обработки запроса на малое потребление.

В предлагаемом ПО поддерживаются следующие режимы:

  • POWER_SAVE_LEVEL_RUNNING. В этом режиме микросхема остается полностью активной, то есть он не является в действительности режимом пониженного потребления, но прописан, чтобы представить все возможные режимы;
  • в режиме POWER_SAVE_LEVEL_CPU_HALT реализована аппаратная остановка процессора, вся периферия остается рабочей и может пробудить его;
  • в POWER_SAVE_LEVEL_STOP_WITH_TIMER реализован режим Deepstop с разрешением низкой тактовой частоты LSE или LSI. Источником пробуждения могут выступать выводы портов, RTC, IWDG или радиомодуль;
  • POWER_SAVE_LEVEL_NOTIMER характеризуется тем, что в нем реализован режим Deepstop с выключенной низкой частотой.

Для запроса на переход в один из режимов необходимо вызвать функцию HAL_PWR_MNGR_Request():



uint8_t HAL_PWR_MNGR_Request(PowerSaveLevels level,

WakeupSourceConfig_TypeDef wsConfig,

PowerSaveLevels *negotiatedLevel)

Аргумент level определяет выбор одного из четырех режимов. Источник пробуждения задается с помощью структуры wsConfig, например, задается пробуждение от RTC или конкретных выводов портов, здесь же настраивается пробуждение по фронту или спаду импульса на выводе. Для проверки исполнения запроса на изменение режима в negotiatedLevel записывается реально установленный режим. Функция возвращает статус успешного изменения режима (SUCCES) либо код ошибки (ERROR), если запрошенный режим не был согласован.

Другие полезные функции ПО режимов малого потребления:

  • HAL_PWR_MNGR_WakeupSource(). Данная функция возвращает источник последнего пробуждения из режима малого энергопотребления;
  • функция App_PowerSaveLevel_Check(PowerSaveLevels level) должна вызываться при запрещенных прерываниях. Она задает желаемый режим малого потребления, а также используется внутри функции HAL_PWR_MNGR_Request() для проверки заданного режима, позволяя предотвращать возможные изменения установки режима из-за прерываний;
  • функция HAL_PWR_MNGR_ShutdownRequest(uint8_t BOR_enabled) позволяет перевести BlueNRG-LP в режим Shutdown, при этом можно разрешить или запретить сброс при снижении питания (BOR).

В режиме Deepstop все порты BlueNRG-LP выключены. Это значит, что если приходит импульс на вывод для пробуждения, микросхема выходит из режима, но связанное с импульсом прерывание теряется. Чтобы избежать этого, в приложении можно задать вызов функции HAL_PWR_MNGR_WakeupIOCallback(), в которой прописать необходимый код обработчика прерывания по сигналу на выводе. Например, источником пробуждения является вывод PA10, но, кроме этого, в приложении этот вывод задан как источник внешнего прерывания, и нужно выполнить ряд команд в обработчике GPIOA_IRQHandler(). Сначала в основном коде приложения пользователь настраивает PA10 в качестве источника пробуждения:



static WakeupSourceConfig_TypeDef wakeupIO = {0,0, WAKEUP_PA10};

Далее в функции обработчика GPIOA_IRQHandler() пользователь добавляет определенный пользовательский код. Но поскольку PA10 является также источником пробуждения, то для выполнения этого кода в случае, если прерывание происходит во время режима Deepstop, пользователь должен использовать следующую функцию:



void HAL_PWR_MNGR_WakeupIOCallback(uint16_t source)
{
   if (source & WAKEUP_PA10)
    { /* Здесь прописать ряд команд из обработчика прерывания по сигналу на PA10 */
       <DO_USER_SPECIFIC_ACTION> 
    }
}

Результаты практических измерений тока потребления

Давайте рассмотрим измерения токов потребления микросхемы при использовании радиомодуля BLE при рассылке оповещений и в фазе подключения. В измерениях были использованы оценочные платы STEVAL-IDB0011V1, имеющие следующие настройки:

  • тестовое приложение BLE_Power_Consumption из пакета BlueNRG-LP DK;
  • напряжение питания 3,3 В;
  • Tx 0 дБм;
  • сохранение всей ОЗУ (RAM0-3 64 кбайт);
  • время запуска 780 мкс;
  • системная частота HSE;
  • частота BLE 16 МГц;
  • интервал рассылки 100 и 1000 мс с длиной пакетов 28 байт;
  • время подключения 100 и 1000 мс при пустых пакетах.

Приложение BLE_Power_Consumption доступно в директории Projects/BLE_Examples пакета BlueNRG-LP DK и позволяет настроить радиомодуль BLE микросхемы в качестве ведомого. Роль ведущего BLE выполняет второе устройство BlueNRG-LP с приложением DTM, подключенное к ПК, где должна быть запущена программа BlueNRG-GUI. С помощью скриптов, которые доступны в той же директории вместе с приложением DTM, осуществляется настройка ведущего и создается соединение с тестируемым BlueNRG-LP. Эти скрипты можно запустить с помощью графического интерфейса BlueNRG-GUI. В таблице 1 приведены значения измеренных токов потребления.

Таблица 1. Значения тока потребления

Работа BLE Измеренный ток потребления, мкА
Интервал рассылки 100 мс 137,898
Интервал рассылки 1000 мс 15,412
Интервал подключения 100 мс 69,546
Интервал подключения 1000 мс 8,816

На рисунках 1 и 2 изображен график потребления BlueNRG-LP при рассылке оповещений для двух интервалов (длина пакета — 28 байт).

Рис. 1. Рассылка с интервалом 100 мс

Рис. 1. Рассылка с интервалом 100 мс

Рис. 2. Рассылка с интервалом 1000 мс

Рис. 2. Рассылка с интервалом 1000 мс

На рисунках 3 и 4 показано потребление BlueNRG-LP при подключении для двух интервалов (пустой пакет).

Рис. 3. Подключение с интервалом 100 мс

Рис. 3. Подключение с интервалом 100 мс

Рис. 4. Подключение с интервалом 1000 мс

Рис. 4. Подключение с интервалом 1000 мс

Обновление программного обеспечения по BLE-радиоканалу для BlueNRG-LP

Концепция и описание работы Over-the-Air

Обновление прошивки «по эфиру» (Over-the-Air, OTA) – процедура получения прошивки ведомым устройством по радиоканалу BLE от ведущего и ее запись во Flash-память ведомого. Процедура OTA выполняется специальным сервисом, который имеет ряд характеристик и может использоваться совместно с другими службами приложения. Упрощенная схема соединения ведущего и ведомого при запуске процедуры показана на рисунке 5. Ведущее устройство, в роли которого может выступать оценочная плата с BlueNRG-LP, подключается к компьютеру посредством USB и управляется через графический интерфейс BlueNRG GUI. BlueNRG GUI предоставляет доступ с компьютера к компиляции и сборке прошивок и к памяти ведомого для передачи нового образа с помощью процедуры OTA.

Рис. 5. Ведущий и ведомый BLE OTA

Рис. 5. Ведущий и ведомый BLE OTA

Весь необходимый программный код сервиса обновления OTA задан в файлах OTA_btl.c и OTA_btl.h, доступных в пакете BlueNRG-LP DK (директория Middlewares\ST\BLE_Application\OTA).

Краткое описание сервиса и его характеристик, заданных в OTA_btl.c:

  • Btl OTA service (OTA_SRVC_UUID) – сервис обновления прошивки;
  • Btl image (IMAGE_CHR_UUID) – характеристика, содержащая информацию о памяти, занимаемой текущим приложением с сервисом OTA;
  • Btl new image (NEW_IMAGE_CHR_UUID) – характеристика, содержащая базовый адрес и размер образа прошивки, которую ведущий собирается отправить через OTA, а также уведомления, запрашиваемые у ведомого для отправки подтверждений во время передачи прошивки;
  • Btl new image content (IMAGE_CONTENT_CHR_UUID) – характеристика, содержащая 16-байтный блок данных образа прошивки, отправляемый ведущим вместе с порядковым номером блока (2 байта) и контрольной суммой для проверки целостности (1 байт);
  • Btl expected image sequence number (IMAGE_SEQ_NUM_CHR_UUID) – характеристика, разрешающая ведомому уведомлять ведущего о готовности принять следующий блок данных и об ошибках.

Процедура обновления OTA начинается с обнаружения ведущим ведомого устройства, на котором запущен сервис OTA. Ведущий прослушивает оповещения, исходящие от устройств по радиоканалу, и выбирает те, которые содержат идентификаторы сервиса OTA. После соединения ведущий отправляет команды ACI_GATT_CLT_DISC_CHAR_BY_UUID для чтения всех характеристик OTA. С помощью команды ACI_GATT_CLT_READ ведущий считывает характеристику «Btl image», чтобы узнать количество свободной памяти ведомого, и выбирает подходящий образ прошивки (файл *.bin) из своей памяти для отправки. Командой ACI_GATT_CLT_WRITE ведущий записывает базовый адрес, размер и нужные уведомления в характеристику «Btl new image» и считывает ответ с помощью ACI_GATT_CLT_READ для проверки. Чтобы включить уведомления от ведомого о его готовности принимать следующий блок данных или информацию об ошибках, ведущий использует характеристику Btl expected image sequence number. Как только ведомый получает эту команду, он отправляет уведомление.

После этих действий начинается передача данных. Ведущий отправляет прошивку блоками по N*16 байт командой ACI_GATT_CLT_WRITE_WITHOUT_RESP (по одной на каждый блок размером N*16). При получении каждой посылки записывается новый блок данных в характеристику Btl new image content. При заполнении внутреннего буфера ведомого данными по N*16 байт они загружаются во Flash-память, и ведомый отправляет уведомление ведущему с указанием номера следующего ожидаемого блока. Он также отправляет уведомление в случае ошибки записи или верификации Flash-памяти, а также сообщает о конечном блоке. В этих случаях процедура загрузки должна быть остановлена. Размер N при использовании увеличенной длины пакета, разрешенной для процедуры OTA, определяется соотношением N = (OTA_ATT_MTU_SIZE – 3 — 4)/16. В микросхеме BlueNRG-LP (стек BLE версии 3.0 и выше с функцией увеличения длины пакета PDU до 251 байт и увеличенным размером ATT_MTU более 23 байт) значение N подстраивается под размер пакета OTA в пределах максимально допустимого размера ATT_MTU ведущего (OTA_ATT_MTU_SIZE). Это позволяет увеличивать размер данных и передавать их в каждом пакете OTA на канальном уровне, а также ускорять процедуру обновления OTA. Для увеличения длины данных функции HCI_LE_SET_DATA_LENGTH() и ACI_ATT_CLT_EXCHANGE_MTU() используются на стороне как передатчика ведущего OTA, так и приемника ведомого OTA и согласовывают максимально поддерживаемые размеры ATT_MTU. Структура пакета OTA с данными показана на рисунке 6.

Рис. 6. Структура пакета OTA

Рис. 6. Структура пакета OTA

Байт контрольной суммы используется для проверки целостности пакета. Байт подтверждения указывает на ожидание уведомления от ведомого во время передачи OTA: 1 – если ожидается уведомление, 0 – если не ожидается.

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

Архитектура и настройка программного обеспечения при использовании процедуры обновления OTA

При использовании процедуры обновления OTA есть два варианта создания архитектуры программного обеспечения ведомого:

  1. Использование диспетчера сброса и разделение области памяти программ на две части: для хранения действительного приложения и для записи новой прошивки через процедуру OTA. Оба приложения в этом случае содержат сервис OTA.
  2. Использование диспетчера сервиса OTA, при этом приложение не содержит сервис OTA и может занимать всю область памяти программ.

В первом случае структура Flash-памяти BlueNRG-LP, использующего сервис обновления OTA, показана на рисунке 7.

Рис. 7. Структура Flash-памяти BlueNRG-LP при использовании сервиса OTA с диспетчером сброса

Рис. 7. Структура Flash-памяти BlueNRG-LP при использовании сервиса OTA с диспетчером сброса

Две области памяти программ обеспечивают возможность обновления прошивки через OTA. При успешной процедуре обновления генерируется сброс, и диспетчер сброса передает управление новому приложению, записанному в одну из областей. Для использования этого метода с базового адреса Flash-памяти 0x10040000, с которого BlueNRG-LP начинает выполнение команд, необходимо загрузить диспетчер сброса с поддержкой OTA. Этот диспетчер будет использовать теги достоверности, хранящиеся в таблицах векторов прерываний и перезаписываемые после каждой успешной процедуры обновления OTA (функция OTA_Check_Application_Tags_Value() в OTA_ResetManager.c). Заголовочные и исходные файлы диспетчера сброса OTA доступны в пакете BlueNRG-LP DK (директория Projects/BLE_Examples/BLE_OTA_ResetManager).

Для создания приложения с поддержкой сервиса OTA, используя исходник OTA_btl.c, необходимо провести ряд настроек проекта приложения (для примера используется программная среда IAR EWARM):

  • В рабочем поле EWARM в настройках препроцессора необходимо прописать CONFIG_OTA_LOWER или CONFIG_OTA_HIGHER, чтобы собрать приложение с сервисом OTA, соответственно, для нижней или верхней областей памяти, а также CONFIG_SW_OTA_DATA_LENGTH_EXT, чтобы разрешить увеличенную длину пакета. Конфигурационный файл линкера нужно скорректировать в соответствии с распределением Flash-памяти, показанным на рисунке 7 (можно использовать файл из директории с приложениями OTA). Кроме этого, необходимо прописать пути к файлам OTA_btl.c и OTA_btl.h.
  • В пользовательском приложении необходимо подключить заголовочный файл OTA_btl.h, вызвать функцию OTA_Add_Btl_Service(), чтобы добавить сервис OTA и его характеристики. Далее нужно добавить:
  • идентификаторы сервиса для сканирования ответов hci_le_set_scan_resp_data(18,BTLServiceUUID4Scan);
  • вызов OTA_Write_Request_CB() в функциях aci_gatt_attribute_modified_event() и aci_gatt_srv_write_event();
  • вызов OTA_Read_Char() в функции aci_gatt_srv_read_event(), чтобы разрешить стеку BLE отправлять ответы;
  • проверку if (OTA_Tick() == 1), чтобы проверять переход к обновленному приложению с помощью функции OTA_Jump_To_New_Application();
  • вызов OTA_Radio_Activity() в aci_hal_end_of_radio_activity_event(), если нужно синхронизировать операции записи во Flash с активностью на радиолинии.

Более простой подход для возможности обновления OTA заключается в использовании диспетчера сервиса OTA, который включает в себя сервис OTA и его характеристики и выполняет роль диспетчера сброса OTA. Структура Flash-памяти в этом случае представлена на рисунке 8.

Рис. 8. Структура Flash-памяти BlueNRG-LP при использовании диспетчера сервиса OTA

Рис. 8. Структура Flash-памяти BlueNRG-LP при использовании диспетчера сервиса OTA

При этом в новое приложение уже не требуется добавлять и прописывать функции сервиса обновления OTA, достаточно активировать диспетчер сервиса OTA с помощью функции OTA_Switch_To_OTA_Service_Manager_Application() из файла OTA_btl.c. При таком методе приложение всегда записывается с фиксированного адреса Flash-памяти.

Заголовочные и исходные файлы диспетчера сервиса OTA доступны в пакете BlueNRG-LP DK (Projects/BLE_Examples/BLE_OTA_ServiceManager). Чтобы разрешить увеличенную длину данных во время процедуры обновления, в настройках препроцессора для приложения диспетчера нужно прописать CONFIG_SW_OTA_DATA_LENGTH_EXT. Для пользовательского приложения необходимо сделать следующие настройки:

  • в рабочем поле EWARM в настройках препроцессора и линкера прописать CONFIG_OTA_USE_SERVICE_MANAGER, скорректировать конфигурационный файл линкера в соответствии с распределением Flash-памяти, показанным на рисунке 8, и прописать пути к OTA_btl.c и OTA_btl.h;
  • в приложении подключить заголовочный файл OTA_btl.h и добавить код для разрешения запуска диспетчера сервиса OTA. Можно использовать функцию OTA_Jump_To_Service_Manager_Application() из c.

Практическая реализация в собственном приложении

Рассмотрим практические примеры реализации процедуры обновления OTA. Для использования примеров требуется следующее программно-аппаратное обеспечение:

  • две оценочные платы STEVAL-IDB011V1 с BlueNRG-LP и кабели USB;
  • приложения из пакета BlueNRG-LP DK:
  • проекты приложений диспетчера сброса и сервиса OTA (OTA Reset Manager и Service Manager);
  • приложения «BLE SensorDemo» и «BLE SerialPort»;
  • приложения BlueNRG Navigator и BlueNRG-X flasher (опционально).
  • пакет STSW-BNRGUI – графический интерфейс для BlueNRG-LP;
  • ПК, соответствующий требованиям:
  • Windows®7 или Windows®10;
  • как минимум 128 Мбайт ОЗУ;
  • 2 порта USB;
  • жесткий диск 40 Мбайт;
  • Adobe Reader0 и выше;
  • IAR Embedded Workbench 8.40.1 и выше.

В проектах SensorDemo и SerialPort, доступных в пакете BlueNRG-LP DK, реализованы оба подхода для выполнения процедуры обновления OTA: при использовании диспетчера сброса и сервиса OTA в самом приложении и при использовании диспетчера сервиса OTA. В таблице 2 приведены имена образов приложений, готовых к использованию.

Таблица 2. Приложения SensorDemo и SerialPort, доступные в директории Firmware\BLE_Examples

Приложения SensorDemo
BLE_SensorDemo_LowerApp_OTA.hex .bin Образ приложения SensorDemo для нижней области памяти программ
BLE_SensorDemo_HigherApp_OTA.hex .bin Образ приложения SensorDemo для верхней области памяти программ
BLE_SensorDemo_Use_OTA_ServiceManager.hex .bin Образ приложения SensorDemo с диспетчером сервиса OTA
Приложения SerialPort
BLE_SerialPort_Server_LowerApp_OTA.hex .bin Образ приложения SerialPort для нижней области памяти программ
BLE_SerialPort_Server_HigherApp_OTA.hex .bin Образ приложения SerialPort для верхней области памяти программ
BLE_SerialPort_Server_Use_OTA_ServiceManager.hex .bin Образ приложения SerialPort с диспетчером сервиса OTA

Реализация первого способа – использование диспетчера сброса и сервиса обновления OTA в приложении

Для выполнения процедуры обновления OTA, используя графический интерфейс BlueNRG GUI и приложение SensorDemo с поддержкой сервиса OTA, необходимо выполнить следующие шаги:

  1. Подключить оценочные платы BlueNRG-LP к USB-разъемам компьютера.
  2. Запустить IAR EWARM и открыть рабочее поле BLE_OTA_ResetManager.eww, выбрать в меню Project → Download → Erase memory, чтобы стереть Flash-память.
  3. Собрать и загрузить соответствующее приложение диспетчера сброса OTA на выбранную плату (BLE_OTA_ResetManager.hex, ~.bin доступны в директории Firmware\BLE_Examples).
  4. Открыть рабочее поле BLE_SensorDemo.eww, создать, собрать и загрузить приложение для нижней области памяти программ на выбранную плату (BLE_SensorDemo_LowerApp_OTA.hex, ~.bin доступны в директории Firmware\BLE_Examples).
  5. Загрузить приложение DTM на вторую плату, которая будет подключена к графическому интерфейсу BlueNRG GUI (DTM_UART_WITH_UPDATER.hex, ~.bin доступны в директории Firmware\BLE_Examples).
  6. Запустить BlueNRG GUI на компьютере и выбрать COM-порт, к которому подключена вторая плата, через выпадающее меню «Port» и нажать «Open».
  7. Выбрать «Tools» → «OTA bootloader», чтобы открыть диалоговое окно действий по обновлению OTA и нажать «Search for devices» для поиска устройств.
  8. После поиска BlueNRG GUI запускает процесс обнаружения и возвращает информацию об адресах и именах устройств, на которых запущен сервис обновления OTA. Список устройств можно открыть с помощью стрелки со списком под кнопкой «Search for devices», где пользователь может выбрать устройство для процедуры обновления прошивки с помощью кнопки «Connect» (рисунок 9). При ошибке выбора устройство можно принудительно отключить нажатием кнопки «Force Disconnection» и вернуться к списку устройств. После подключения и считывания области свободной памяти пользователю предлагается предоставить новый файл прошивки, скомпилированной с корректными стартовым адресом и размером. Для этого можно создать приложение для верхней области памяти программ в рабочем поле BLE_SensorDemo.eww и собрать образ *.bin для отправки (собранный образ со стартовым адресом в верхней области памяти программ BLE_SensorDemo_HigherApp_OTA.bin доступен в директории Firmware\BLE_Examples).

Рис. 9. Процедура OTA: поиск устройств и подключение

Рис. 9. Процедура OTA: поиск устройств и подключение

  1. После сборки с корректным стартовым адресом нажатие кнопки «Update» запустит процедуру обновления прошивки OTA: индикатор выполнения показывает время, необходимое до завершения процесса (рисунок 10).

 

Рис. 10. Процесс обновления OTA

Рис. 10. Процесс обновления OTA

  1. По завершению процесса запускается новое приложение.

При выполнении пунктов 3, 4 и 5 можно использовать готовые собранные образы из директории Firmware\BLE_Examples и загрузить их с помощью приложений BlueNRG-LP Navigator или BlueNRG-X flasher.

Аналогичные шаги могут быть использованы для приложения SerialPort (BLE_SerialPort\EWARM\BLE_SerialPort.eww). 

Реализация второго способа – использование диспетчера сервиса обновления OTA

Для выполнения процедуры обновления OTA, используя графический интерфейс BlueNRG GUI и приложения SensorDemo и SerialPort с поддержкой диспетчера сервиса OTA, необходимо выполнить следующие шаги:

  1. Подключить оценочные платы BlueNRG-LP к USB-разъемам компьютера.
  2. Запустить IAR EWARM и открыть рабочее поле BLE_OTA_ServiceManager.eww, выбрать в меню Project → Download → Erase memory, чтобы стереть Flash-память.
  3. Собрать и загрузить соответствующее приложение диспетчера сервиса OTA на выбранную плату (BLE_OTA_ServiceManager.hex, ~.bin доступны в директории Firmware\BLE_Examples).
  4. Открыть BLE_SensorDemo.eww, создать, собрать и загрузить приложение для работы с OTA на ту же плату (BLE_SensorDemo_Use_OTA_ServiceManager.hex, ~.bin доступны в директории Firmware\BLE_Examples).

Далее нужно повторить пункты 5, 6 и 7 из первого способа. Для создания нового файла прошивки можно открыть рабочее поле BLE_ SerialPort.eww, создать приложение с поддержкой диспетчера сервиса OTA и собрать образ *.bin для отправки (собранный образ с поддержкой диспетчера сервиса OTA BLE_SerialPort_Server_Use_OTA_ServiceManager.bin доступен в директории Firmware\BLE_Examples). Далее нужно нажать кнопку «Update» и дождаться завершения обновления.

Как работать со встроенным UART-загрузчиком в BlueNRG-LP

На этапе изготовления в зарезервированную область памяти BlueNRG-LP прошивается загрузчик, который используется для записи Flash-памяти микросхемы по последовательному протоколу UART. Его активация осуществляется аппаратной установкой высокого уровня на выводе PA10 во время сброса, в противном случае происходит запуск приложения, записанного во Flash-память. Загрузчик позволяет полностью стирать Flash-память или выбирать конкретные страницы для стирания, а также имеет возможность включения защиты памяти от считывания.

В качестве линий приемопередатчика UART используются выводы PA8 (RX) и PA9 (TX). UART-хост для подключения и передачи данных в загрузчик должен передавать данные 8-битными пакетами без четности, без контроля потока, с одним стоп-битом. Скорость передачи определяется загрузчиком автоматически и может составлять до 1 Мбит/с. 

Активация и команды встроенного загрузчика

После активации загрузчика установкой единицы на PA10 при сбросе инициализируется UART-интерфейс, BlueNRG-LP запускает процедуру автоматического определения скорости передачи UART-хоста и начинает прослушивание линии приемника, ожидая от хоста пакета данных 0x7F: один стартовый бит, байт 0x7F без бита четности и один стоп-бит. После вычисления скорости передачи хосту передается байт подтверждения 0x79, который сигнализирует, что BlueNRG-LP готов принимать команды.

Для проверки корректности полученных данных загрузчик BlueNRG-LP использует контрольную сумму, вычисление и отправку которой необходимо обеспечить на стороне UART-хоста. Для этого передатчик в конце каждого пакета с данными должен отправлять байт контрольной суммы, содержащий результат логической операции исключающего «ИЛИ» над всеми пересылаемыми байтами данных. Приемник, проведя операцию «ИЛИ» всех полученных байт, включая байты данных и контрольной суммы, должен получить в результате ноль. Кроме этого, в каждой посылке с командой хост должен отправлять байт с логической инверсией кода команды, иначе загрузчик выдаст ошибку NACK (0x1F). При каждой корректной отправке команды или данных загрузчик отвечает байтом подтверждения ACK (0x79).

Загрузчик BlueNRG-LP поддерживает следующие команды:

  • Get List (0x00) позволяет получить версию загрузчика и список поддерживаемых команд.
  • Get Version (0x01) используется для получения версии загрузчика.
  • Get ID (0x02) используется для идентификации чипа. При получении команды загрузчик передает три байта идентификатора, содержащие версию чипа и байт 0x3F: старший полубайт «3» указывает на то, что подключена микросхема BlueNRG-LP, младший полубайт «F» обозначает размер Flash-памяти в BlueNRG-LP, равный 256 кбайт.
  • Read Memory (0x11) используется для чтения данных из любого адреса памяти ОЗУ или Flash-памяти. После получения команды загрузчик отвечает байтом ACK и ожидает 4 байта адреса и байт контрольной суммы. После получения адреса и проверки контрольной суммы в загрузчик необходимо передать информацию о количестве байт для чтения. Если включена защита от чтения, загрузчик отправляет байт NACK и прерывает выполнение команды.
  • Go (0x21) запускает исполнение загруженного в микросхему кода программы с адреса, указанного в команде. После получения команды загрузчик отвечает байтом ACK и ожидает 4 байта адреса и байт контрольной суммы. После получения адреса загрузчик сбрасывает используемые им регистры к значениям по умолчанию, инициализирует указатель основного стека и выполняет переход в ячейку памяти с адресом, полученным после команды и увеличенным на 4. Например, если получен адрес 0x10040000, загрузчик переходит в ячейку памяти с адресом 0x10040004.
  • Write Memory (0x31) позволяет записывать данные в любой адрес памяти ОЗУ или Flash-памяти. После команды в загрузчик необходимо последовательно передать адрес, количество байт данных и сами байты данных. После получения корректной последовательности загрузчик приступает к записи данных, начиная с указанного адреса. Максимальная длина записываемого блока для BlueNRG-LP составляет 256 байтов. Если включена защита от чтения, загрузчик отправляет байт NACK и прерывает выполнение команды.
  • Erase memory (0x43) позволяет выборочно стирать страницы Flash-памяти. После команды в загрузчик необходимо передать байт с количеством страниц, которые необходимо стереть, и байты с адресами этих страниц. При этом исчисление количества страниц начинается с нуля: при передаче нулевого значения стирается одна страница, при передаче единицы стираются 2 страницы и так далее. Значение 255 в байте количества страниц зарезервировано для запроса на полное стирание Flash-памяти.
  • Readout Protect (0x82) включает защиту от чтения Flash-памяти. После получения команды загрузчик отвечает байтом ACK и активирует защиту. При успешной активации загрузчик повторно отправляет байт подтверждения ACK.
  • Readout unprotect (0x92) отключает защиту от чтения Flash-памяти. После получения команды загрузчик отвечает байтом ACK, стирает все страницы Flash-памяти и отключает защиту от чтения для всей Flash-памяти. Если операция стирания не удалась, загрузчик передает хосту байт NACK, и защита от чтения остается активной. После выполнения команды загрузчик генерирует сброс микросхемы. Если необходимо продолжить работу с загрузчиком, его нужно заново активировать установкой высокого уровня на PA10 при сбросе.

Ниже для примера показаны блок-схемы алгоритма записи во Flash-память BlueNRG-LP на стороне хоста (рисунок 11) и загрузчика (рисунок 12).

Рис. 11. Блок-схема алгоритма записи во Flash-память BlueNRG-LP со стороны хоста

Рис. 11. Блок-схема алгоритма записи во Flash-память BlueNRG-LP со стороны хоста

Рис. 12. Блок-схема алгоритма записи во Flash-память BlueNRG-LP со стороны загрузчика

Рис. 12. Блок-схема алгоритма записи во Flash-память BlueNRG-LP со стороны загрузчика 

Особенности реализации Secure bootloader

Безопасный загрузчик Secure bootloader является функцией встроенного загрузчика BlueNRG-LP, позволяющей аутентифицировать пользовательское приложение, то есть определять подлинность полученной прошивки. При использовании этой функции разрешается запуск только доверенных, прошедших аутентификацию приложений. Безопасный загрузчик BlueNRG-LP использует асимметричные криптографические алгоритмы с парой ключей (открытым и закрытым). RSA-2048 используется с открытым ключом размером 256 байт. Этот метод позволяет аутентифицировать прошивку путем создания и добавления к нему цифровой подписи. Функция безопасного загрузчика запускается записью специального кода активации (0xEC1CC10B) в область памяти OTP.

Для проведения процедуры аутентификации прошивки пользователь генерирует открытый и закрытый ключи. Прошивка подписывается пользователем с использованием закрытого ключа, и сгенерированная цифровая подпись добавляется к прошивке (размер подписи составляет 2048 бит). В область OTP пользователь записывает открытый ключ, который используется безопасным загрузчиком для проверки подписи прошивки. В результате проверки исполняемым становится только тот образ прошивки, который был подписан правильным закрытым ключом, принадлежащим пользователю. Закрытый ключ при этом никогда не передается и не хранится в микросхеме BlueNRG-LP. Общий размер информации в OTP составляет 524 байта и состоит из кода активации, данных открытого ключа и стартового адреса подписанного приложения. Возможность указания стартового адреса прошивки в OTP полезна при использовании диспетчера сервиса OTA для аутентификации приложения с определенного адреса Flash-памяти. После сохранения всех данных необходимо включить блокировку OTP записью любого значения, отличного от 0xFFFFFFFF, по адресу 0x10001BFC.

Для работы с функцией безопасного загрузчика в программном пакете BlueNRG-LP DK доступны следующие служебные утилиты (директория Utility/Secure_bootloader):

  • key_generation.exe генерирует открытый и закрытый ключи для алгоритма RSA-2048. Эта утилита использует команды библиотеки OpenSSL, которую необходимо предварительно установить и прописать путь к ней в переменной среды Windows PATH. Утилита имеет два параметра:
  • -k – создает директорию для сгенерированных ключей;
  • -f – создает директорию для открытого ключа в двух форматах: public_key.c и public_key.py (первый для проектов на С, второй для скриптов на python).
  • create_signed_bin.exe создает подписанную прошивку из бинарного файла. Эта утилита берет неподписанный бинарный файл, расширяет его, добавляет подпись в его конце и создает новый подписанный файл. Утилита имеет три параметра:
  • -k – директория с закрытым и открытым ключами для создания подписи (та же директория, созданная с помощью параметра -k утилитой key_generation.exe);
  • -f – входная неподписанная прошивка в виде бинарного файла;
  • -o – выходная подписанная прошивка в виде бинарного файла.

Файл, сгенерированный параметром –o, и есть подписанное приложение, которое можно записать во Flash-память.

  • store_key_OTP.exe сохраняет всю информацию в память OTP. При запуске утилиты микросхема должна быть в режиме загрузчика. Утилита имеет четыре параметра:
  • -f – директория с файлом public_key.py для сохранения в OTP (та же директория, созданная с помощью параметра -f утилитой key_generation.exe);
  • -p – COM-порт, к которому подключен загрузчик устройства;
  • -a – начальный адрес прошивки (0x10040000);
  • -l – блокирует OTP.

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

Микросхема BlueNRG-LP обладает важнейшими свойствами современных Bluetooth-устройств: сверхмалое потребление и надежная защита данных. Расширенные аппаратные функции микросхемы позволяют использовать ее для множества задач, а готовые примеры приложений и пакет программ для работы с платой на базе BlueNRG-LP существенно облегчают внедрение микросхемы в собственные разработки.

•••

Наши информационные каналы

О компании ST Microelectronics

Компания STMicroelectronics является №1 производителем электроники в Европе. Компоненты ST широко представлены в окружающих нас потребительских товарах – от iPhone до автомобилей разных марок. Лидеры индустриального рынка выбирают компоненты ST за их надежность и выдающиеся технические параметры. В компании ST работает 48 000 сотрудников в 35 странах. Производственные мощности расположены в 12 странах мира. Более 11 тысяч сотрудников заняты исследованиями и разработками – инновационное лидерство ...читать далее

Товары
Наименование
BLUENRG-345MC (ST)
BLUENRG-355AC (ST)
BLUENRG-345AC (ST)
BLUENRG-355MC (ST)
BLUENRG-355VC (ST)
BLUENRG-355MT (ST)
BLUENRG-345MT (ST)
STEVAL-IDB011V1 (ST)