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

[Вячик13]

Имеется устройство на базе микроконтроллера 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 аналогичных проектов на этом же устройстве с аналогичной структурой программы, но подобного никогда не наблюдал.

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

[aaarrr]

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

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

[Вячик13]

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

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

[aaarrr]

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

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

[Вячик13]

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

Проверил. Самое подозрительное:
memset(Display->Code,'\0',strlen((char *)Display->Code)); //Очистка кодовой строки
где Display->Code указатель на массив байт (unsigned char *).
Остальные memset все просты и явны.

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


Сообщение отредактировал Вячик13 - Jun 18 2018, 10:35

[jcxz]

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

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

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

У меня в таких ситуациях срабатывает ловушка по записи по недопустимому адресу (записи в регион где нет ОЗУ, и поэтому закрытый от записи в MPU) когда указатель такого цикла доходит до границы ОЗУ. Автор явно не знает про MPU.
.... Или STM32F100 - это не Cortex-M3? Лень смотреть в даташит....

[Вячик13]

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


У меня в таких ситуациях срабатывает ловушка по записи по недопустимому адресу (записи в регион где нет ОЗУ, и поэтому закрытый от записи в MPU) когда указатель такого цикла доходит до границы ОЗУ. Автор явно не знает про MPU.
.... Или STM32F100 - это не Cortex-M3? Лень смотреть в даташит....

Нет, не лень. И могу читать даже в оригинале. Но, знаете, как в известном анекдоте про немого мальчика: "А раньше я не разговаривал, потому что всё было в порядке". Представьте себе, за 20 проектов у меня не возникало даже потребности в каких-либо ловушках, поскольку всё работало нормально.

[jcxz]

Представьте себе, за 20 проектов у меня не возникало даже потребности в каких-либо ловушках, поскольку всё работало нормально.

Ну значит - поздравляю! - Вы доросли до серьёзных проектов, сложнее мигания парой светодиодов

[Вячик13]

Ну значит - поздравляю! - Вы доросли до серьёзных проектов, сложнее мигания парой светодиодов

Спасибо, за поздравление. Наконец то оценили. А то с 1983 года, когда я сделал свой первый проект на К1-20 никто ни одного доброго словечка!

[jcxz]

Спасибо, за поздравление. Наконец то оценили. А то с 1983 года, когда я сделал свой первый проект на К1-20 никто ни одного доброго словечка!

Понятно, что воспоминания о молодости и какие раньше были деревья зелёные процессоры хорошие и изученные - Вам дороги.
Но чтобы не жить воспоминаниями о былом, а делать устройства на современном уровне, надо всё-таки стараться изучать эти самые современные МК. А в используемых Вами Cortex-M уже лет так 10 точно (не 83-й канеш, куда там наличествует MPU, который подобные ошибки с заполнением памяти константой часто позволяет находить на раз.
И другие разработчики, уже тоже лет 10 как, его успешно используют. А также есть fault-ы, которые тоже помогают в ловле багов.