Перейти к содержанию

    

Непонятный рестарт программы

Имеется устройство на базе микроконтроллера STM32F100RC. Для него разработано программное обеспечение под Keil 4.22a:

Total RO Size (Code + RO Data) 76796 ( 75.00kB)

Total RW Size (RW Data + ZI Data) 7776 ( 7.59kB)

Total ROM Size (Code + RO Data + RW Data) 76944 ( 75.14kB)

Устройство (весовой терминал ротационных промышленных весов) установлено на промышленном объекте у заказчика в количестве 3 штук.

 

Наблюдается следующий эффект. Через произвольное время (от 3 до 30 минут) происходит сброс программы. Причём сброс странный. Статические переменные обнуляются, но сброс не "ловится" при отладке (установка breakpoint как в в начале SystemInit(), так и в начале main()). Мало того, при рестарте программы должно производиться тестирование дисплеев из 7-сегментных индикаторов (в начале main()), но оно не происходит.

В программе используется WDT IWDG, но это не его рук дело. Эти явления происходят на всех 3 устройствах. До этого я разработал более 20 аналогичных проектов на этом же устройстве с аналогичной структурой программы, но подобного никогда не наблюдал.

 

Буду благодарен за любой совет.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Буду благодарен за любой совет.

Мощную помеху в линии питания (для эксперимента запитайте устройство от аккумулятора, а не от сети) или радиопомеху не исключаете ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Наблюдается следующий эффект. Через произвольное время (от 3 до 30 минут) происходит сброс программы. Причём сброс странный. Статические переменные обнуляются, но сброс не "ловится" при отладке (установка breakpoint как в в начале SystemInit(), так и в начале main()). Мало того, при рестарте программы должно производиться тестирование дисплеев из 7-сегментных индикаторов (в начале main()), но оно не происходит.

Так может это и не сброс, а именно обнуление ОЗУ вследствие программной ошибки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Так может это и не сброс, а именно обнуление ОЗУ вседствие программной ошибки?

Или стек переполняется, например, при интенсивных прерываниях, и собой затирает данные в ОЗУ ...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Так может это и не сброс, а именно обнуление ОЗУ вследствие программной ошибки?

Обнуляются все статические переменные (по крайней мере я проверил 7-8 разного типа). А какая может быть ошибка чтобы выйти на инициализирующий сброс статических переменных?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А какая может быть ошибка чтобы выйти на инициализирующий сброс статических переменных?

memset(x, 0, y), например. Не выходит оно никуда, просто самостоятельно стирает содержимое памяти.

Поделиться сообщением


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

Нет. Во-первых в данной системе нет интенсивных прерываний:

1) системные часы (каждую миллисекунду);

2) АЦП - 1 раз в 10 миллисекунд;

3) КПДП передатчика SPI (каждую миллисекунду);

4) 2 прерывания UART (не работали, поскольку не было компьютера верхнего уровня).

Во-вторых, как я уже писал, аналогичная система и в других проектах (даже есть более нагруженные).

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Во-вторых, как я уже писал, аналогичная система и в других проектах (даже есть более нагруженные).

Хорошо. Ловим сброс чисто аппаратно. Подпаиваем на плату светодиод и при сбросе зажигаем его. И в программе делаем так, чтобы выключить его можно было только оператору, например, нажатием кнопочки ...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
memset(x, 0, y), например. Не выходит оно никуда, просто самостоятельно стирает содержимое памяти.

Проверил. Самое подозрительное:

memset(Display->Code,'\0',strlen((char *)Display->Code)); //Очистка кодовой строки

где Display->Code указатель на массив байт (unsigned char *).

Остальные memset все просты и явны.

 

Может быть функция strlen(), а тем более с аргументом-указателем на член структуры может глючить? Хотя в аналогичных проектах всё это работает безукоризненно.

 

Изменено пользователем Вячик13

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
... ничего кроме трёхфазных асинхронников там нет.

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

Если дело в этом, то запитка от аккумулятора в качестве эксперимента (а я вам настоятельно советую попробовать этот вариант) может и не помочь, т.к. помехи проходят сквозь эфир. Да, вместо аккумулятора можно использовать обычный UPS, физически (вилкой) отключенный от розетки и питающийся от аккумулятора. Это в том, например, случае, если ваш прибор питается от 220В и запитать его прямо от аккумулятора затруднительно или неудобно ...

Поделиться сообщением


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

Спасибо, но вряд ли. Если это аппаратный сброс, то в любом случае должна была сработать подпрограмма тестирования индикаторов. А она гоняет по индикатору "палочки", а затем отображает дату и версию программы. я бы это увидел.

 

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

Если дело в этом, то запитка от аккумулятора в качестве эксперимента (а я вам настоятельно советую попробовать этот вариант) может и не помочь, т.к. помехи проходят сквозь эфир. Да, вместо аккумулятора можно использовать обычный UPS, физически (вилкой) отключенный от розетки и питающийся от аккумулятора. Это в том, например, случае, если ваш прибор питается от 220В и запитать его прямо от аккумулятора затруднительно или неудобно ...

В период наблюдения явления на площадке ещё шли монтажные работы и ничего такого не включалось

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В период наблюдения явления на площадке ещё шли монтажные работы и ничего такого не включалось

Болгарка, дрель, перфоратор, сварочник ? Нет ? Вы уверены ?

И еще, я бы все-таки стек попробовал увеличить ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Болгарка, дрель, перфоратор, сварочник ? Нет ? Вы уверены ?

И еще, я бы все-таки стек попробовал увеличить ...

Тогда проконсультируйте, пожалуйста, как. Я в Keile этого никогда не делал. Где это находится?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Тогда проконсультируйте, пожалуйста, как. Я в Keile этого никогда не делал. Где это находится?

Сходу не припомню, давно не занимался. Вот, что нашлось за первую же минуту:

 

http://www.keil.com/support/man/docs/rlarm...ar_cfgstack.htm

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Остальные memset все просты и явны.

Вам указали на одну из тысячи возможностей. Не надо понимать буквально. Любой цикл в вашей программе, который что-то пишет или просто копирует в память, может снести всю вашу ОЗУ например при разрушении переменных, от которых зависит адрес назначения или счётчик цикла.

Симптомы указывают на вполне типичный баг в работе с указателями. Странно не знать этого после "20 проектов"...

И в борьбе с такими багами часто помогает и защита памяти и обработка всех fault-ов. Чего у Вас также явно нет. Что опять же странно после "20 проектов"... :laughing:

 

memset(x, 0, y), например. Не выходит оно никуда, просто самостоятельно стирает содержимое памяти.

У меня в таких ситуациях срабатывает ловушка по записи по недопустимому адресу (записи в регион где нет ОЗУ, и поэтому закрытый от записи в MPU) когда указатель такого цикла доходит до границы ОЗУ. Автор явно не знает про MPU. :laughing:

.... Или STM32F100 - это не Cortex-M3? Лень смотреть в даташит....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация