Comments 8
Существенный вопрос при тестировании на железе, но точного ответа не знаю. Надеюсь подскажите.
Предпосылка следующая. Идет поиск ошибки приводящей к зависанию микроконтроллера. В код то там, то здесь делаются вставки, типа контрольных точек, которые выводят сообщения в дебажный порт. Таким образом проверяется, что в таком то месте программы контроллер еще бегал.
Вопрос такой. Можно ли гарантировать, что если выполнялась команда вывода сообщения в порт (RS232/RS485), т.е. байты переданы в буфер приемопередатчика, а на следующем такте (или очень близко к этому моменту) происходит зависание контроллера ( к примеру аппаратное исключение «деление на ноль» или «закончился стек»), то приемопередатчик все-таки выдаст отладочные байты наружу? Т.е. насколько приемопередатчик работает независимо от микроконтроллера?
Предпосылка следующая. Идет поиск ошибки приводящей к зависанию микроконтроллера. В код то там, то здесь делаются вставки, типа контрольных точек, которые выводят сообщения в дебажный порт. Таким образом проверяется, что в таком то месте программы контроллер еще бегал.
Вопрос такой. Можно ли гарантировать, что если выполнялась команда вывода сообщения в порт (RS232/RS485), т.е. байты переданы в буфер приемопередатчика, а на следующем такте (или очень близко к этому моменту) происходит зависание контроллера ( к примеру аппаратное исключение «деление на ноль» или «закончился стек»), то приемопередатчик все-таки выдаст отладочные байты наружу? Т.е. насколько приемопередатчик работает независимо от микроконтроллера?
Зависит от контроллера.
Реально может так «глюкать» что для примера отключает UART от питания или например на ходу меняет тактовые частоты. Тут все довольно железно специфично.
Реально может так «глюкать» что для примера отключает UART от питания или например на ходу меняет тактовые частоты. Тут все довольно железно специфично.
Выходит, что UART как правило «независим» от контроллера и будет выдавать данные из своего буфера при зависшем контроллере. Кроме тех случаев, когда в случае сбоя будет послана команда:
1. на отключение UART;
2. на настройку параметров UART;
3. на изменение тактовой частоты.
Думаю из всего множества возможных вариантов, данная тройка имеет существенно малую вероятность. Т.е. доверять отладке через вывод в дебажный порт в целом можно, но это не гарантия. Правильно?
1. на отключение UART;
2. на настройку параметров UART;
3. на изменение тактовой частоты.
Думаю из всего множества возможных вариантов, данная тройка имеет существенно малую вероятность. Т.е. доверять отладке через вывод в дебажный порт в целом можно, но это не гарантия. Правильно?
В микроконтроллерах даже отладка через JTAG не дает полной гарантии, т.к. есть свои тараканы. Любая операция несет какие-либо побочные эффекты. Например, при остановке ядра JTAG-ом — таймеры могут продолжать тикать, обычно можно настроить останов периферии при останове ядра, но не всегда и не везде.
Но если не заморачиваться сильно, то отладочный вывод в UART является простым и довольно надежным решением. Так самый удобный способ отловить причину аппаратного исключения — сделать обработчик с разбором стека и выдачей его в UART.
Но если не заморачиваться сильно, то отладочный вывод в UART является простым и довольно надежным решением. Так самый удобный способ отловить причину аппаратного исключения — сделать обработчик с разбором стека и выдачей его в UART.
Вообще, по моему опыту, последовательный порт весьма надежно работает.
Еще можно светодиод на GPIO повесить — там достаточно одной записи в регистр для изменения его состояния. При помощи осциллографа можно таким образом очень точно интервалы времени измерять
Еще можно светодиод на GPIO повесить — там достаточно одной записи в регистр для изменения его состояния. При помощи осциллографа можно таким образом очень точно интервалы времени измерять
Вот интересно, как же Вы реализуете стенд тестирования? Тот же датчик температуры взять (какой нибудь DS1820) — время измерения 800-1000мс. За минуту можно сделать не более 60 измерений — правильно? Да и сама тестируемая система меняется довольно медленно. Похоже в любом случае тестирование будет долгим?
Вот другой пример. Я разрабатывал устройство и одно из требований к нему — когда контроллер не активен, то раз в сутки включать насос на 5 секунд, чтоб не закисливался. Как проверить такую функцию?
Вот другой пример. Я разрабатывал устройство и одно из требований к нему — когда контроллер не активен, то раз в сутки включать насос на 5 секунд, чтоб не закисливался. Как проверить такую функцию?
Суть в том, что бы тестирование было автоматическим. В этом случае длительность теста не имеет особого значения, хоть на час запустить, хоть на месяц.
Ну для датчика температуры, т.к. это не основная функция устройства, просто проверялось, что полученная с него температура в диапазоне комнатной (т.к. там относительно сложный алгоритм преобразования из raw данных в температуру, при любом сбое значение температуры будет неадекватным. Примеры стендов по основным функциям привел вроде в статье.
А для включения раз в сутки на 5 секунд — сделать устройство, подключаемое вместо насоса, которое будет считать, сколько раз и на сколько времени было включение. И оставить на неделю.
А для включения раз в сутки на 5 секунд — сделать устройство, подключаемое вместо насоса, которое будет считать, сколько раз и на сколько времени было включение. И оставить на неделю.
Sign up to leave a comment.
Тестирование встраиваемых систем — один аспект, о котором почему-то мало говорят