Разработка контроллера резервного питания. Технология отладки и тюнинг19.09.2021 19:16

В продолжение разработки рассмотрим технологию отладки платы контроллера и его программного обеспечения. Попробуем адаптер SWD, осциллограф, VT100 терминал через UART, движок FreeMaster, экспорт и анализ в MATLAB. Пройдём через ужас тюнинга. Всё на примере открытого демо-проекта управляемого источника напряжения на базе платы контроллера.

Предыдущие статьи проекта контроллера резервного питания BACKPMAN v1.0

При отладке все средства хороши, но у каждого средства есть свои ограничения. Поэтому средств много. Начнем в хронологическом порядке.

SWD/JTAG адаптер.

Через этот адаптер программируется Flash память микроконтроллера, отлаживается низкоуровневая логика программы, выполняется профилирование, логирование.
В данном случае используется SWD интерфейс. Используем адаптер J-Link в среде IAR. Обладатели J-Link J-Link PLUS,  ULTRA+,  PRO могут использовать бесплатный отладчик Ozone. Но этот отладчик не так удобен, в частности не отображает поток прерываний в реальном времени и длительности ISR. Хотя он все же будет удобнее чем отладочные плагины для Eclipse.
В директории settings проекта находятся файлы используемы отладчиком IAR. В них содержаться все настройки адаптера и SWD интерфейса. В самом отладчике важно правильно указать частоту ядра и частоту семплирования SWO. В таком окне все это указываем:

Частоту семплирования выбираем максимальную. Timestump resolution выбираем тем меньше чем точнее хотим измерять интервалы времени, однако чем меньше это значение тем будет большая вероятность получить переполнение интерфейса.
Частоту CPU не следует выбирать больше 120 МГц, в противном случае панель timeline в отладчике перестает работать.

Что мы можем делать с помощью отладчика J-Link Ultra+ в отладчике IAR:
— Программировать любые области памяти, включая помять на внешних чипах
— Запускать и останавливать программу в любой момент, проходить программу по шагам и на уровне исходного текста и на уровне ассемблера.
— Наблюдать значения переменных и во время останова и во время выполнения программы с некоторой периодичностью обновления.
— Наблюдать значения всех регистров процессора и всей периферии.
— Ставить точки остановка в коде
— Ставить точки останова при чтении или записи в какие-либо переменные или области памяти, причем с условиями.
— Отображать на графике в реальном времени состояния переменных, потока прерываний и длительностей выполнения процедур обслуживания прерываний, событий ITM.
— Отображение стека вызовов.
— И многое другое…

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

Наблюдение за потоком прерываний сообщает очень важную информацию о загруженности процессора и способности системы работать в режиме жесткого реального времени.

Использование событий ITM для профилирования

Одна из самых важных работ в отладке систем с жестким реальным временем — это профилирование, т.е. измерение времени выполнения критически важных участков кода.
Для профилирования в отладчике IAR удобно использовать события ITM. Эти события отображаются на графике времени в реальном времени, и на этом графике можно увидеть целочисленные значения присвоенные событиям и измерить интервалы между событиями. Отправка событий в программе представляет собой простую запись 8, 16, или 32-х битного слова данных в определенный адрес в пространстве модуля ITM

Подключая к своему проекту файл arm_itm.h мы получаем в свое распоряжение макросы для отсылки вида:

#define ITM_EVENT8(channel, value) 
#define ITM_EVENT16(channel, value)
#define ITM_EVENT32(channel, value)

#define ITM_EVENT8_WITH_PC(channel, value)  
#define ITM_EVENT16_WITH_PC(channel, value) 
#define ITM_EVENT32_WITH_PC(channel, value) 

Здесь переменная channel может принимать значения от 1 до 4 (по умолчанию допустимый диапазон в IAR). Это будет номер графика на котором отобразиться событие. А value будет отображено как значение события.
На графике это будет выглядеть так:

Большинство измерений длительностей фрагментов кода в проекте выполнено именно таким способом. Это несколько быстрее чем использование программных вставок для профилирования и макросы отправки событий могут оставаться в релизном коде поскольку практически не влияют на производительность кода.

SWD адаптер имеет еще один удобный механизм отладки — RTT. Но в данном проекте этот механизм не использован. Одна из причин в том что SWD адаптер не имеет гальванической изоляции. Постоянное подключение к плате адаптера и USB интерфейса одновременно создает нежелательную петлю земель. С другой стороны описанные ниже инструменты вполне перекрывают функциональность RTT.

Следует помнить что адаптер J-Link имеет ограниченную пропускную способность. Частота SWD интерфейса не превышает 50 МГц. При достаточной частоте событий и прерываний адаптер испытывает переполнение и перестает правильно отображать графики и фиксировать события. Приходится создавать особые условия для измерений, отключать какие-то потоки данных через адаптер чтобы измерить что-то конкретное.
Вторая проблема — это очень ограниченные возможности в отладчике по представлению и анализу данных. Поэтому SWD/JTAG адаптер не может удовлетворить все потребности при отладке.

Осциллограф

Когда основная функциональность микроконтроллера на плате проверена наступает очередь тестирования внешней аппаратной части.

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

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

Здесь приведены некоторые осциллограммы снятые на плате во время отладки

Другие осциллограммы можно посмотреть здесь

Следует учитывать что работа контроллера сопряжена с быстрой коммутацией сигналов мощностью до киловатт. Такие коммутации вызывают сильные синфазные помехи влияющие на всю схему и в том числе на осциллограф. Обычные осциллографы при работающем DC/DC преобразователе выдают на экране посторонний шум в единицы вольт. С другой стороны осциллографы восприимчивы к синфазным помехам приходящим от удаленных приборов в сети переменного тока, например от светодиодных светильников. Как возникают синфазные помехи и как с ними бороться неплохо показано в ролике EEVBlog. На плате же контроллера кроме DC/DC преобразователя находится еще 3-и источника сильных синфазных помех — преобразователи U4, U5 (RFM0505S), U9 (VX7805–500)

Надежды на использование осциллографов с автономным питанием здесь не оправдаются.
Они покажут точно такой же шум от синфазных помех как и стационарные осциллографы.
Чтобы измерить осциллографом аналоговый сигнал в диапазоне 0–3 В в схеме с работающим DC/DC преобразователем необходим специальный дифференциальный щуп.

Но даже не любой дифференциальный щуп. Например дифференциальный щуп GDP-040D к осциллографу GDS-320, показанному выше, не сможет достаточно подавить синфазные помехи возникающие в плате контроллера. Нужен щуп с подавлением CMRR более 60 дБ на частоте 10 МГц.

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

Вывод через UART и сервер терминала VT100

В простейшем случае можно выводить через UART некий непрерывный поток значений интересующих нас величин. Но этот способ сразу пропустим. Он весьма ограничен.
В данном проекте был сразу внедрен развитый интерактивный пользовательский интерфейс по протоколу VT100. Спецификация VT100 описывает служебные последовательности байт получая которые эмуляторы терминалов типа PuTTY или TeraTerm выполняют позиционирование строк на экране, стирание символов, строк, экрана, подсвечивание и т.д. Служебные байты передаются вместе с выводимой на экран информацией, но отфильтровываются программами эмуляторов терминала VT100.
Преимуществом реализованного здесь пользовательского интерфейса по сравнению с командными интерфейсами является отсутствие необходимости запоминания и ввода имен команд и их аргументов, все действия выполняется по нажатию одного символа меню.
В демонстрационном проекте интерфейса реализованы возможности редактирования энергонезависимых параметров, просмотра состояния сигналов, управление сигналами , просмотр лога устройства, сброс устройства.
В проекте файлы сервера терминала находятся в директории Software/Regulated_power_source/APP/VT100/

Назначение файлов:

Отдельно об окне диагностики позволяющем наблюдать и управлять сигналами на плате. Окно показано ниже и конфигурируется в исходном тексте на С-и вот таким массивом. В окне можно увидеть состояния всех бинарных сигналов на плате и переключить состояние тех из них, которые управляются микроконтроллером. Буквы в квадратных скобках обозначают клавиши, по нажатию которых произойдет переключение сигнала. Если сигнал не бинарный, а представлен числом, как например код ЦАП, то при нажатии на клавишу произойдет переход в режим редактирования числа. Помимо сигналов в окне выводятся вычисляемые переменные и измеряемые величины.

Для экономии экранного пространства бинарным сигналам даны названия соответствующие их названиям на плате.

Ведение лога

Когда наблюдение в реальном времени покажется слишком утомительным и не информативным наступает время писать все важные события в программе в лог для последующего анализа.

В демо-пректе лог ведется в массив находящийся в RAM микроконтроллера. В файле logger.c находится реализация логгера. Количество записей в логе определяется константой EVENT_LOG_SIZE в файле logger.h. Число небольшое — 32, поскольку имеется не очень большой объем RAM. Но при подключении компьютера к контроллеру через программу-терминал можно организовать непрерывную запись лога в память компьютера и тогда размер лога ограничен лишь размером носителя в компьютере.

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

В любом месте программы пользователь может осуществить запись в лог просто написав оператор вызова функции лога типа такого:

    LOGs(__FUNCTION__, __LINE__, SEVERITY_DEFAULT,"U15: Vrms=%0.1f V", Get_float_val(&sys.vrms_u15));;; ;

Следует только не превышать максимальную длину строки и помнить, что лог работает после запуска RTOS и использует мьютексы RTOS с таймаутами. Мьютексы нужны для предотвращения конфликтов одновременного доступа. Естественно при этом лог может записывать любая задача в системе.
Лог имеет структуру напоминающую LIFO.Т. е. новые данные всегда записываются, а старые записи если уже не помещаются, то стираются.

Интерактивный движок мониторинга и управления FreeMaster

Терминал VT100 хорош тем что для него есть множество легковесных утилит под все популярные операционные системы. Можно не беспокоиться что ваш компьютер не подключится через USB к контроллеру с помощью программы эмулятора терминала VT100. Но VT100 — это не полновесный графический пользовательский интерфейс (GUI) с кнопками, графиками, сценариями и разными визуальными компонентами. GUI все же предлагает гораздо большую плотность информации и значит эффективность отладки.
Трудностью на этом пути становиться более сложный протокол взаимодействия с устройствами чем VT100, и который надо внедрить в сами устройства.

Инструмент FreeMaster хорошо подходит чтобы заменить всю функциональность терминала VT100 и добавить новую, но он работает только под Windows.
Его не предложишь широкому кругу конечных пользователей, но для отладки в лаборатории это отличный инструмент. Суть в том что в программе микроконтроллера размещается модуль обслуживания протокола FreeMaster, а на PC устанавливается приложение FreeMaster. Приложение позволяет гибко создавать и настраивать экраны с отображением данных из микроконтроллера в реальном времени.
Данные представляются в виде графиков, в виде числовых значений, в виде HTML виджетов и т.д. Гораздо подробнее по ссылке — FreeMASTER Run-Time Debugging Tool.

Здесь опишу как портирован модуль протокола и драйверы FreeMaster в демо-проекте.

Директория программного модуля FreeMaster находится здесь. В нашем проекте обмен осуществляется микроконтроллером через UART и затем через конвертер UART-USB FT234XD-R с компьютером через USB virtual COM порт. Скорость 256000 бит в сек.

В демо-проекте портирован только драйвер для UART -freemaster_serial_lpuart.c. Но зато драйвер не использует стандартный SDK поставляемый производителем для семеcтва Kinetis. Это делает работу драйвера более быстрой и прозрачной. Непосредственно обработка команд и отсылка данных по протоколу FreeMaster осуществляется в отдельной задаче Azure RTOS. Эта задача реализована в файле FreeMaster_task.c. В задаче использована функция поллинга коммуникационного канала. Но поскольку поллинг вызывается по событию передаваемому из процедуры прерывания приемника UART, то практически нет задержек реакции на команды характерные для поллинга.

Протокол FreeMaster может конфигурироваться для включения той или иной функциональности. Конфигурация задается в файле freemaster_cfg.h. В частности там разрешено и протестировано:

• прием и выполнение команд из приложения FreeMaster,

• независимые коммуникационные потоки (pipes). Через низ осуществляется вывод лога устройства в приложение FreeMaster

• режим осциллографа, когда данные постоянно передаются в приложение на PC

• режим рекордера, когда данные по триггеру записываются в буфер внутри устройства с точным интервалом дискретизации и потом переписываются в приложение на PC.

По умолчанию приложение FreeMaster может читать содержимое любой области памяти в пространстве адресов микроконтроллера. Чтобы было удобнее в приложение FreeMaster можно загрузить .elf файл после компиляции проекта и тогда вместо адресов памяти становиться возможным обращаться непосредственно по именам переменных объявленных в проекте. Однако в проекте может быть очень много переменных. Чтобы не иметь дела с огромными списками переменных приведен пример в файле FreeMaster_vars_map.c как описать только те переменные которые мы хотим видеть. Это называется в документации Target-side address translation (TSA). Тогда данные об адресах описанных переменных приложение ждет не от пользователя, а загружает их непосредственно из подключенного устройства.

И первое, как ни странно, что мы делаем в приложении FreeMaster — это проверяем нагрузку CPU микроконтроллера. Вид окна показан ниже. Очень легко в многозадачной программе на базе RTOS нагрузить процессор так что не будет вовремя выполняться большинство задач. Мы должны оставлять минимум 30% процессору свободного времени чтобы быть уверенными в реализуемости режима работы в жестком реальном времени. В случае нашего приложения загрузка получилась на грани критической.
Это из-за того что очень часто происходят прерываний АЦП. Но иначе было нельзя. Коммутация цепей питания требует быстрой реакции.

График в реальном времени нагрузки процессора. Нагрузка измеряется тысячными долями. Следовательно на графике показана нагрузка в 74%.

Создание управляемого источника напряжения

Для источника напряжения используется расположенный на плате buck-boost преобразователь на микросхеме U23 LTC3789. На вход X14 подается фиксированное напряжение от внешнего источника питания или аккумулятора 16…26 В. На выходе X6 получаем регулируемое напряжение от 2 до 32 В, ток до 10 А (долговременная работа определяется теплоотводом). Минимальное входное напряжение определяется цепью защиты входа от пониженного напряжения на резисторах R69 и R73. Отпаяв R73 входное напряжение можно понижать до 3.4 В.

Управляет референсным напряжением buck-boost преобразователя 16-и битный ЦАП U24 DAC80501. Поэтому диапазон значений для регулирования от 0 до 65535.

Программный модуль FreeMaster в микроконтроллере содержит обработчик команды установки кода в ЦАП. Идентификатор команды в файле FreeMaster_task.h определен как:

#define FMCMD_SET_DCDC_DAC      0x04

Такое числовое значение должно быть послано в качестве идентификатора команды совместно с самим кодом ЦАП из приложения FreeMaster в микроконтроллер чтобы обновить код в ЦАП. Для чтения выходного напряжения и тока через преобразователь достаточно выбрать в окне программы соответствующие переменные для отображения в таблице и в виде графика на панели графиков. Интервал через который будут обновляться данные можно регулировать от 10 мс и меньше (зависит от скорости интерфейса и компьютера) и до сотен и больше секунд в режиме осциллографа. В режиме рекордера интервал зависит от того в каком месте в программе микроконтроллера будет вызываться функция FMSTR_Recorder. В данном случае она расположения в обработчике прерывания АЦП и вызывается через каждые 32 мкс. Значит рекордер работает с частотой 31250 Гц.

Ниже показано окно приложения FreeMaster с процессом регулирования выходного напряжения. Вместо аккумулятора на клеммы разъема X6 подключен резистор 33 Ом в качестве нагрузки.

Управление выходным напряжением. Нагрузка на выходе — резистор 33 Ом

Все окна и конфигурации созданные пользователем в приложении FreeMaster сохраняются в файле проекта. Показанный выше проект находится в файле Project.pmpx.

Как работать с приложение FreeMaster описано здесь pcm_um.pdf

Как создан виджет регулировки напряжения в приложении FreeMaster

Дело в том что приложение FreeMaster не предлагает своей библиотеки готовых виджетов. Вместо этого в окно FreeMaster встраивается HTML страница поддерживающая JScript под стандарт Internet Explorer и HTML виджеты надо искать и вставлять на страницу самому пользователю. Internet Explorer поддерживает и ActiveX компоненты. Кто знаком с программированием под Windows может создать такие компоненты в средах разработки типа MS Visual Studio или RAD Studio.

Но к счастью HTML компонентов в интернете очень много. В данном случае я решил использовать компоненты библиотеки jQWidgets. Лицензия разрешает их свободно использовать в некоммерческих целях. В репозитарий проекта они не помещены, их надо скачать и развернуть в директории widgets.

В результате была создана HTML страница с виджетом BackupCtrl_control_page.htm

Поскольку FreeMaster в среде Windows инсталлирует свой объект автоматизации, то на странице он доступен после того как включить в нее такую строку:

Далее обращения на странице к объекту производятся по имени pcm. Например так:

      function Send_DCDC_DAC_code(event)
      {
        var dac_code = event.args.value;
        Show_DAC_state(dac_code)
        cmd = "SET_DCDC_DAC(" + dac_code + ")";
        retMsg = "";
        pcm.SendCommand(cmd, retMsg);
      }

В фрагменте выше отправляется контроллеру команда с идентификатором SET_DCDC_DAC и данные сопровождающие команду. Сама команда была создана в приложении FreeMsater в окне Application Commands. Текстовое название команды используется в скриптах на HTML странице.

Экспорт и анализ в MATLAB

Когда простого наблюдения за графиками и значениями переменных уже недостаточно и надо на их основе создать алгоритмы обработки, то наступает очередь MATLAB. Есть несколько путей взаимодействия с MATLAB. Один из них — это использовать запись данных из окна осциллографа FreeMaster в файл и выполнение импорта этого файла в MATLAB. Другой путь — это использовать тот же сервер автоматизации что был использован при создании HTML страницы. Вот так выглядит скрипт MATLAB для экспорта данных из окна рекордера:

fmstr = actxserver ('MCB.PCM.1'); % вызов сервера автоматизации FreeMaster 
fmstr.GetCurrentRecorderData;     % загрузить данные из окна текущего рекордера в приложении  FreeMaster
recdata=cell2mat(fmstr.LastRecorder_data); % превратить данные в массив
recnames=fmstr.LastRecorder_serieNames;    % получить имена столбцов

st = 32e-6;  % задать интервал выборки с которым работает рекрдер. 
fs = 1/st;   % определить частоту выборки
datalen= length(recdata); % узнать длину записей
endtime = st*datalen;     % узнать время окончания записи   

% добавляем к массиву записей шкалу времени чтобы можно было использовать массив в Simulink  
recdata = transpose(recdata);
x = transpose(linspace(0, st*(length(recdata)-1),length(recdata) ));
recdata = horzcat(x,recdata)
% массив recdata готов к импорту из Simulink

Скрипт приведенный выше извлекает данные из окна рекордера FreeMaster и помещает их в рабочее пространство MATLAB.

Забегая вперед покажу вид проекта детектора полного заряда аккумулятора в Simulink основанного на данных из рекордера FreeMaster:

Верхний уровень модели. Блок D — это импортер данных рекордера из рабочего пространства MATLABПодсистема детектора полного заряда аккумулятора

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

Менеджер параметров

Несколько слов о дополнительных утилитах проекта.

Когда параметров в программе становиться много приходится думать об управлении ими.

В директории /Software/Regulated_power_source/ParametersManager/ находится исполняемый файл EMBPMAN.exe. Это менеджер энергонезависимых параметров устройства. Его функция проста — ввод названий параметров, их типов, комментариев к ним, условия валидации, форматирование при выводе и т.д. и все в одном простом табличном виде. Менеджер способен генерировать исходные файлы на C-и со всеми необходимыми структурами и массивами для встраивания в конечное приложение.
Т.е. программист вручную в исходных текстах не объявляет параметры, они вводятся в табличном виде в менеджере и потом генерируются в виде текста на C-и.

В директории /Software/Regulated_power_source/APP/Parameters/ находятся файлы BKMAN1_2_Params.c, BKMAN1_2_Params.h, BKMAN1_2_FreeMaster_vars.c, эти файлы как раз сгенерированы менеджером и редактировать их вручную не надо.

В представленном демо-проекте менеджер параметром может показаться излишним поскольку объявлено всего 3-и параметра. Однако впоследствии количество параметров легко увеличится до нескольких сотен с ростом функциональности контроллера. Зарядка аккумуляторов совместно с резервным питанием в автономном режиме требует большое количество настроек, калибровочных и эвристических констант и это не считая специфических настроек связанных с эксплуатацией в определенном промышленном окружении.

Помимо того менеджер одновременно с исходниками на С-и может генерировать: JSON файлы для обмена в технологии IoT, MIB-файлы для управления в составе систем мониторинга на базе SNMP протокола, HTML файлы для встроенного в контроллер WEB сервера. И все это на основе единой базы данных параметров. Хотя и не все из этого может пригодится для разрабатываемого контроллера.

Структуры на С-и сгенерированные менеджером используются в файле Params_editor.c для вывода меню редактора параметров. Чтобы параметры при выводе не образовывали на экране длиннющий список они организуются как иерархическое дерево в виде вложенных подменю. Такая иерархия также конструируется пользователем в менеджере параметров.

Тюнинг, или как выглядят схемотехнические баги.

В результате первых этапов отладки сгорело около 20-и транзисторов, 4-е стабилитрона и 2-е микросхемы и мы пришли к следующим коррекциям схемы и печатной платы:

Баг с номером 8 имел самые катастрофические последствия. К нему привело слепое копирование референсной схемы из даташита производителя. Но оказалось что при резком спаде входного напряжения (например при КЗ на шине 24 В) в затворах ключей напряжение поднимается до 30 В из-за того что на выходе (например на клеммах аккумятора) остается остаточное напряжение. Затворы пробивало и выводило из строя транзисторы.

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

Проект контроллера резервного питания живет своей жизнью в репозитарии https://github.com/Indemsys/Backup-controller_BACKPMAN-v1.0

© Habrahabr.ru