как тестировать программу микроконтроллера Опции

[nckkm]

Собственно вопрос - пишу программу для микроконтроллера STM32, но как проверить все ли правильно работает?
Как автоматизировать и симулировать проверку всех заявленных функций контроллера?

Я почему спрашиваю, я долго работал с ПЛИСами и там с этим делом было более менее все понятно.

В ПЛИС сам проект описывается на Verilog, потом к нему дописывается Testbench - это вторая программа на том же Verilog, которая симулирует все внешние воздействия / сигналы на микросхему. Так же, Testbench контролирует, что разрабатываемая микросхема выдает правильные отклики и вообще правильные последовательности сигналов.
Таким образом, с помощью Verilog можно абсолютно точно посмотреть что и как происходит внутри любого блока проекта.
Я так даже симулировал от начала до конца запуск ядра Linux в ПЛИС и просматривал сигналы обращения к SDRAM, и прочие..

А как все это делается с микроконтроллерами? И делается ли вообще?
В принципе, я понимаю, можно использовать статический анализ с инструментами типа cppcheck, или писать Unit Test, но кажется мне это все не совсем то, что нужно.. Ну вот какой unit test можно написать для обработчика прерываний или функции ининциализации контроллера DMA?

А если у меня контроллер управляет медленными процессами типа включил вентилятор, выждал 10 секунд, включил печку.. Как тестировать такие функции устройства?

Возможно тема обсуждалась, извините если так, не нашел поиском.

[Falkon_99]

вопрос почти риторический и многогранный, для этого и придумали всякие отладочные платы.
Чтобы проверить устройство на столе (да установки на объект) можно пользоватся светодиодами, установленными заранее на плату.
Если плата еще не готова, то для проверки программы в каждой среде разработки есть симульторы (debager)

[Tahoe]

В ПЛИС сам проект описывается на Verilog, потом к нему дописывается Testbench
...
А как все это делается с микроконтроллерами?

Да, по сути, точно так же.

Ну вот какой unit test можно написать для обработчика прерываний или функции ининциализации контроллера DMA?

А зачем тестировать ИНИЦИАЛИЗАЦИЮ? Это же не самоцель - проинициализировать. Тестировать надо задачу/модуль. Например пересылка данных через DMA - это уже вполне себе объект тестирования. И тот факт, что перед использованием его необходимо инициализировать, это просто часть общей задачи.

[HardEgor]

Собственно вопрос - пишу программу для микроконтроллера STM32, но как проверить все ли правильно работает?
Как автоматизировать и симулировать проверку всех заявленных функций контроллера?

А что надо протестировать корректность логики программы или коректность исполнения в железе?
Я так понимаю надо первое - для этого есть программные эмуляторы, сам не пользовался.
ПЛИС всё-таки регулярная структура, баги хорошо описываются и программные эмуляторы для них имеют хорошие тестирующие свойства. А микроконтроллеры, конкретно STM32, сборная солянка - ядро от ARM, периферия от ST.
Например в Keil есть эмулятор ядра ARM, а вот периферия не для всех контроллеров.

А вот второе сложнее, начинающим стоит воспользоваться evaluation board, залить программу и подавать тестирующие воздействия. Иногда проще сделать готовую плату, если требуется сложная обвязка, и на неё проверять.

[mempfis_]

Собственно вопрос - пишу программу для микроконтроллера STM32, но как проверить все ли правильно работает?
Как автоматизировать и симулировать проверку всех заявленных функций контроллера?

Проверять работоспособность переферии контроллера нет смысла. Это делают за Вас производители контроллера, а всякие разные баги переферии описывают в эрратах, которые тоже стоит иногда листать.
Что касается проверки работоспособности программы, то сдесь всё зависит только от Вас. Если программа простая, то достаточно один раз её отладить с помощью отладчика/симулятора/светодиода/LCD-индикатора. Убрать отладочную информацию, проверить что с функционалом всё в порядке и принять решение о завершении отладки.
Если программа сложная, то не стоит скупиться и выделить один UART только для отладочных целей и выводить в него всю важную информацию.
Программу разделять на осмысленные задачи, каждую из которых можно отладить независимо от других, и обеспечить их максимальную независимость от других задач - задача опроса АЦП, задача контроля GPRS, задача обслуживания LCD-индикатора и т.п. Если есть зависимые задачи, то предусмотреть чтобы крах одной задачи не влиял на другие, зависящие от неё задачи.
Каждая задача должна при выполнении некоторых действий отправляет в debug-порт сообщения.
Например условный лог:

TASK LCD: PRINT MSG: HELLO
TASK GPRS: TRY CONNECT: APN: internet
TASK SERVER: WAITE GPRS
TASK GPRS: CONNECT OK: IP: 10.9.8.7
TASK LCD: LCD LOST
TASK SERVER: SEND DATA: BYTES: 245 TYPE: GPS FIFO
.............................
.............................
TASK LCD: LCD INIT OK
.............................

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

Другой вариант косвенной борьбы с глюками программы - наличие возможности дистанционного обновления прошивки. Если в устройстве есть ETHERNET или GPRS, или любой порт, по которому можно связаться с устройством (RS232, RS485, голый UART), то после завершения написания условно "рабочей и отлаженной прошивки" в первую очередь следует ввести и отладить возможность её обновления дистанционно. Перимущества дистанционной перепрошивки нет смысла описывать.

[Aner]

Для профессиональных разработок на процах пишутся специальные тестовые программы, которые подчас более сложные, чем сама рабочая прога. Просто это проделывали не раз, именно под STM32XXX. Что давала свои результаты как по статистике отказов, технологических, температурных и тп.
И стоит это тоже не дёшево. И тз там своё. На что многие не подписываются, экономя. Но если занимаешся разработкой для серийного выпуска от этого не уйти, там еще и свои тесты и контроль параметров, разбросы.
Тесты пишут исходя из того что нужно. Цыклы, обработчики, DMA и тп более работоспособны, чем инжины внутри, память, интерфейсы. Сбои связанные с питанием, памятью, периферией и их причины более востребованы, чем результат матрицы кватернионов, расчет корреляционных коэффициентов, фильтров калмана и тп.
Но и скороспелых недоучек, софтверных кривописак хватает погорло.

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

[nckkm]

Проверять работоспособность переферии контроллера нет смысла. Это делают за Вас производители контроллера, а всякие разные баги переферии описывают в эрратах, которые тоже стоит иногда листать.

нет, проверять работоспособность переферии не собирался.. только проверка своей собственной программы..

Программу разделять на осмысленные задачи, каждую из которых можно отладить независимо от других, и обеспечить их максимальную независимость от других задач - задача опроса АЦП, задача контроля GPRS, задача обслуживания LCD-индикатора и т.п.

Вот это и беспокоит - поочередная отладка независимых частей.
Каждую часть по отдельности отладил - каждая работает, но как быть уверенным, что они все вместе будут работать?

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

Может какой инструмент есть вроде тестбенча для Verilog - чтобы программно симулировать все возможные ситуации...

[scifi]

Вот это и беспокоит - поочередная отладка независимых частей.
Каждую часть по отдельности отладил - каждая работает, но как быть уверенным, что они все вместе будут работать?

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

Хочется всего и сразу? Если бы такое было, мы бы не слышали постоянно о новых громких багах: всяческие уязвимости каждый день, та же проблема 2000 года, американский шаттл не запускали на орбиту под новый год, чтобы не словить глюки от часов и т.д.
Поэтому к проблеме подходят с разных сторон: те же юнит тесты, логи, сторожевые таймеры, и т.д. и т.п.

[Golikov A.]

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

Основной принцип борьбы с багами - архитектура. Хорошо продуманная программа, с внутренней логикой - залог успеха.
Далее уже идут стандартные ходы стиля написания, типа не плодить глобальные переменные зря, использовать классы если есть С++.

Потом есть устойчивые к ошибкам дизайны и не устойчивы

Ну и в завершении тесты основной линии алгоритма, наработка на отказ, и логи критических багов!

программа с ветвлением + прерывания - это сильно сложнее для симуляции, чем четко определенная по состояниям ПЛИС...

[AlexandrY]

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

Может какой инструмент есть вроде тестбенча для Verilog - чтобы программно симулировать все возможные ситуации...

Инструмент есть и называется он RTOS. Но не любая, а с надежным отладочным движком + микроконтроллер с продуманными отладочными средствами.

Как понимаю вы перешли с Amber на STM32. И видимо потому, что у Amber нет отладочных средств кроме как симуляции на VHDL
А uLinux не та вещь чтобы на поиск одного испорченного указателя тратить дни. Там тогда на всю жизнь хватит отладки.

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

Нынче принято сразу брать микроконтроллер со всей отладочной инфраструктурой. Чтобы была ОСь, в ней уже реализованные логи и удаленный апгрейд, отладочный канал (лучше несколько) через SWD/JTAG, поддержка просмотра всех объектов оси в IDE, полный и отлаженный BSP (лучше даже генерируемый), профайлер, трассер событий и проч. и чтобы все это загружалось и работало максимально быстро.
Такую инфраструктуру мало кто имеет. Я знаю только серию Kinetis от Freescele у которой все это есть.

[Golikov A.]

Нынче принято сразу брать микроконтроллер со всей отладочной инфраструктурой. Чтобы была ОСь, в ней уже реализованные логи и удаленный апгрейд, отладочный канал (лучше несколько) через SWD/JTAG, поддержка просмотра всех объектов оси в IDE, полный и отлаженный BSP (лучше даже генерируемый), профайлер, трассер событий и проч. и чтобы все это загружалось и работало максимально быстро.
Такую инфраструктуру мало кто имеет. Я знаю только серию Kinetis от Freescele у которой все это есть.

этим абзацем вы перечеркнули жизнь всех проектов с LPC, STM, и огромной армией других АРМов, также в топку пошли все без операционные проекты.

Не уверен что подъем контроллера с таким количеством обвески (программной, которую тоже кто-то писал) гарантирует упрощение отладки плохо написанного кода. Мне кажется что как раз наоборот, операционка внесет еще больше неопределенности, начнете виснут во внутренних симафорах и совсем все станет грустно...

[AlexandrY]

также в топку пошли все без операционные проекты.

Мне кажется что как раз наоборот, операционка внесет еще больше неопределенности, начнете виснут во внутренних симафорах и совсем все станет грустно...

Так, не отходим от контекста.

Уважаемый TC начал с того, что отлаживал uLinux с помощью симулятора аппаратной части. С тем же успехом он мог бы отлаживать uLinux скажем в Micro-Cap (модели только будет найти труднее )

Вот альтернативы этому абсурду и рассматриваем.

[Aner]

AlexandrY думаю вы напугали теоретиков и им подобных. Но все же RTOS и ваше описание средств и сервисов дебага ( инструментария ) не есть тестовая программа или программа тестирования. С этими средствами можно отладить программу только. Но не тестировать.

[AlexandrY]

Но все же RTOS и ваше описание средств и сервисов дебага ( инструментария ) не есть тестовая программа или программа тестирования. С этими средствами можно отладить программу только. Но не тестировать.

Наткнулся на показательную статью о юнит-тестировании http://www.drdobbs.com/testing/unit-testin...tions/240156344
Сперва там берутся продемонстрировать как они тестируют функцию sprintf.
И сразу же делают ошибку предполагая функцию sprintf изолированной.
Но даже так упростив это стоит посмотреть сколько возни вызывает тестирование такой простой функции.

А главное все проблемы которые у меня возникали со sprintf эти тесты никогда не обнаружат.
Это во первых выход за пределы стека и разрушение соседних данных или стеков соседних задач.
Во вторых проблемы выравнивания при неправильно установленных границах стека.
В третьих неявное использование сопроцессора с плавающей точкой и таким образом нарушение фрейма контекста в RTOS в которых поддержка FP отдельная опция.

Почему авторы про это забыли? Потому что им не встречались эти баги.
Тогда вопрос. Можно ли написать тест не зная реальных багов?
Видимо нет.
Итого вывод. Юнит-тестирование это пост-процесс, когда все грабли уже пройдены.
Юнит-тестирование не ускоряет разработку и не делает софт надежным, оно только своеобразно документирует пройденные баги.

Поэтому вопрос быстроты локализации багов остается самым важным.

[lekintr]

Ну не знаю, у меня вопрос в отладке микроконтроллеров всегда решался довольно просто и топорно.
Берем подпрограмму, запускаем ее по циклу на длительное время и долбим снаружи всеми возможными данными, которая она обязана сожрать. Если зависла, вылетела, отожрала память, порушился стек, разбираемся. Не вылетела, идем к следующему модулю.
Отличие от ПЛИС, у микроконтроллеров в том, на мой взгляд, что они с одной стороны более "тянучие" на баги, то есть влетает он в баг легко, но и вылетает также легко. А вот ПЛИС, влетае в баг тяжело, благодаря жесткой симуляции, но уж если влетела, вытащить очень трудно.
ТС могу повторить то, что тут уже озвучил сам ТС. Отлаживайте по кускам. Если подпрограмма не зависает от данных в тестовом модуле, она не зависнет и в связке с остальными устройствами. Микроконтроллеры скорее страдают от аппаратных чудес, которые устраивают им разработчики. Кривые клоки, плохое питание, порушенные входные сигналы, испорченные уровни и так далее. Соответственно микропроцессор зависает в 99% случаев не то того, что программа плохо написана, а от того, например, что разработчики забыли подтянуть выводы JTAG и вообще бросили их как попало, ну и там кондесаторы на питанию поставили не те и не там. Вот и начинается поле чудес...

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

Сообщение отредактировал lekintr - Nov 27 2013, 13:06