Вот что мы получили после замены чипа MKE18F512VLL16 на чип STM32H753VIH6:
Увеличенную в 4 раза скорость работы а значит и увеличенную скорость реакции на аварийные ситуации
Увеличенный объем оперативной и постоянной памяти, т.е. шире возможности отладки и больший объем диагностической информации.
Возможность перепрограммировать контроллер через встроенный интерфейс USB с помощью бесплатной утилитой STM32CubeProgrammer
Возможность подключения SD карты и автономного сбора долговременных логов
Прямое подключение интерфейса USB и возможность организовать через него подключение RNDIS и поверх него TCP/IP протокола и далее всех сетевых сервисов как: WEB сервер, FTP сервер, MQTT клиента и прочих. Теперь контроллер легко интегрировать в IoT.
Предыдущие статьи
Ссылка на открытый проект: https://github.com/Indemsys/Backup-controller_BACKPMAN-v1.0
Ссылка на открытый проект https://github.com/Indemsys/Backup-controller_BACKPMAN-v2.0
Замечательной особенностью семейства STM32 является то, что для него за несколько месяцев до кризиса была объявлена полная поддержка Azure RTOS. Т.е. из STM32CubeMX теперь можно сгенерировать проект для Azure RTOS со всем сопровождающим middleware кроме GUIX. Но вместо GUIX предлагается TochGFX.
Трассировка
Перетрассировка много времени не отняла. Спасла способность приложения STM32CubeMX удобно показывать и управлять назначением функций пинов. Переделать надо было лишь несколько участков на плате. Ниже показана участок трассировки под микроконтроллером.
Но корпус BGA потребовал уменьшить допустимые зазоры и ширину проводников с 0.2/0.15 мм до 0.125/0.125 мм. Как следствие пришлось уменьшить толщину меди во внешних слоях в два раза до 0.036 мм
Для силовой электроники это грозит повышением температуры платы и усилением проблем электромагнитной совместимости. С этим мы будем бороться с помощью внешнего кулера, для которого предусмотрен гальвано-изолированный управляющий сигнал, с помощью цифровой обработки сигналов, и придется слегка уменьшить предельные нагрузки в спецификации.
В дальнейшем же не будем рисковать и перейдем на модульную архитектуру.
Когда пришли платы было мгновение небольшого шока, когда обнаружилось отсутствие отверстий во всех переходных:
К счастью, это оказалось всего лишь изменившейся технологией изготовления и плата заработала сразу.
Как стартовать
Старт разработки под STM32 начинается STM32CubeMX. Скачав это приложение уже в нем попутно скачиваем весь пакет Azure RTOS.
Создаем проект в STM32CubeMX , в нем выбираем нужный нам чип. Первым делом конфигурируем тактирование и назначение функций пинов в соответствии со схемой.
При назначении пинов руководствуемся удобством трассировки. После того как у пина выбрали его функцию и не хотим, чтобы она менялась пин надо пристегнуть.
Иначе функция пина может измениться, когда мы начнем назначать и переназначать функции другим пинам. STM32CubeMX умеет автоматически компоновать реализуемые конфигурации функций пинов. Может казаться мелочью, но когда пинов больше сотни, то такие незамеченные изменения могут привести к большим потерям времени.
Дальше не стал мелочиться и включил все промежуточное программное обеспечение поставляемой с Azure RTOS.
Сконфигурировал периферию и тактирование сразу на 480 МГц. Подправил размер стека. И сгенерировал проект для компиляции в IAR. Как ни странно, но получившийся довольно большой проект скомпилировался без ошибок. В USB Mass Storge пришлось только поменять адрес одной конечной точки. Загрузив проект в микроконтроллер тот сразу заработал. Правда в пустом цикле внутри планировщика RTOS.
Чтобы начать писать свое приложение надо сначала как-то передать ему управление.
Это делается в файле app_azure_rtos.c. В нем в функции tx_application_define надо создать вызов своей задачи и уже в ней перейти к исполнению своего приложения.
Надо помнить, что файл app_azure_rtos.c перезаписывается при каждой новой перегенерации проекта в STM32CubeMX, но в нем сохраняются фрагменты кода в пространствах между строками комментариев типа /* USER CODE ... . Поэтому свой код можно писать только в тех отведенных местах.
Во избежание путаницы надо различать весь пакет софта называемый Azure RTOS и ядро операционной системы реального времени называемое RTOS ThreadX. При этом само ядро ThreadX небольшое по размеру, может быть даже меньше FreeRTOS.
Создание BSP
Пакет Azure RTOS славится своим нативным стеком USB, но сгенерированные в STM32CubeMX исходники не будут содержать реального кода инициализирующего стек USB, файловую систему и другие стеки. Файлы app_netxduo.c, app_filex.c, app_usbx_device.h будут пусты. В этом смысле STM32CubeMX еще сыроват.
Нужный исходники можно найти если в STM32CubeMX сгенерировать код из готовых примеров под определенные отладочные платы.
Выбираем наиболее похожий проект- Ux_Device_MSC для платы STM32H735G-DK. Проект выполнен на базе Azure RTOS. После генерации в этом проекте в директории \Drivers\BSP\STM32H735G-DK находятся интересующие нас примеры инициализации. Стираем все файлы в нашем проекте в директории \USBX\App и копируем туда все файлы из аналогичной директории проекта Ux_Device_MSC. Дополнительно копируем файлы stm32h735g_discovery_conf.h, stm32h735g_discovery_errno.h, stm32h735g_discovery_sd.c, stm32h735g_discovery_sd.h.
Однако в проекте Ux_Device_MSC используется порт USB HS, а на нашей плате USB FS. Также есть разница в детекторе наличия SD карты, на нашей плате такого детектора нет. Отличаются частоты тактирования. Поэтому необходим рефакторинг.
С этого момента мы уже не можем использовать генерацию STM32CubeMX, поскольку это перезапишет наши изменения. С STM32CubeMX еще не прощаемся, но переносим его проект в сторону, нам еще понадобится перегенерация, чтобы внедрить ту или иную сложную периферию или разобраться с нюансами настройки тактирования.
Подводные камни при портировании проектов на STM32H
Первый момент заключается в том, что оперативная память в STM32H сильно фрагментирована. Взглянем на диаграмму из мануала показанную ниже
На диаграмме можно найти следующие области, выполняющие роль оперативной памяти: ITCM-RAM, AXI SRAM, SRAM1, SRAM2, SRAM3, SRAM4, Bckp SRAM. И тут надо очень внимательно смотреть как каждая область RAM соединена с периферией и процессором. Не любой периферии доступна любая область RAM.
Хуже то что при генерации проектов в STM32CubeMX эти нюансы не учитываются. Проект по умолчанию может использовать область ITCM-RAM, но эта область недоступна, скажем, движку IDMA модуля SDMMC. При генерации создается несколько файлов линкера с расширением .icf с описанием областей памяти. Но ни один из этих файлов не описывает все области чипа. Т.е. разработчик при портировании должен будет отредактировать и дополнить файлы .icf даже для простейших примеров.
Следует также помнить, что разные области RAM обладают разным быстродействием. Самая быстрая ITCM-RAM (недоступная для SDMMC IDMA, но доступная для MDMA), самая медленная Bckp SRAM. Область ITCM-RAM лучше использовать для стеков задач и быстрых DSP алгоритмов, области SRAM1, SRAM2, SRAM3, SRAM4 поделить между DMA и рабочими переменными, AXI SRAM приберечь для видеобуфера и больших блоков транспортируемых по DMA.
Тут возникает второй момент. Если мы выделяем блок памяти для записи или чтения по DMA, то этот блок не должен кэшироваться. Иначе данные из этого блока будут неправильно прочитаны процессором. DMA никак не инвалидирует кэш. В этом месте натыкаемся на то что пулы памяти выделяемые в Azure RTOS для задач и драйверов обычно общие и поэтому в них нет дифференциации на кэшируемые и некэшируемые области. Опять разработчику придется разгребать эти нюансы.
Ну и наконец масса софта примеров реализации тех или иных функций поставляемого с SDK STM32 плохо согласуется с последней версией STM32CubeMX либо вообще не может быть загружена в этот инструмент. Можно легко нарваться на несогласованное объявление объектов используемых в HAL и в BSP для конкретных плат. Надо внимательно следить за объявлениями и применение объектов типа SD_HandleTypeDef и др.
Здесь приведен демонстрационный проект реализации USB накопителя на базе платы BACKPMAN v2.0 - https://github.com/Indemsys/Backup-controller_BACKPMAN-v2.0/tree/main/Software/Azure_RTOS_USB_MSC
При подключении к USB интерфейсу платы контроллера компьютер определяет ее как внешний USB накопитель. Физически файлы накопителя находятся на SD карте вставленной в разъем на плате.
Демонстрационный проект знакомит с организацией работы Azure RTOS, USB стека и драйвера SD карты. Проект предназначен для среды разработки IAR и отладочный адаптер J-Link.