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

    

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

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

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

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

 

 

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

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

 

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

 

 

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


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

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

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


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

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

 

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


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

Понятно, что воспоминания о молодости и какие раньше были деревья зелёные процессоры хорошие и изученные - Вам дороги.

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

И другие разработчики, уже тоже лет 10 как, его успешно используют. А также есть fault-ы, которые тоже помогают в ловле багов.

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


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

При рестарте анализируйте соотв-ий регистр, где фиксируется причина рестарта. (не знаю как ОНО в ARM называется).

Причиной, кроме WD, может быть авария по питанию (при этом узел контроля питания сгенерирует прерывание или ресет) и, возможно, и.т.д.

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


Ссылка на сообщение
Поделиться на другие сайты
А в используемых Вами Cortex-M уже лет так 10 точно (не 83-й канеш, куда там ;) наличествует MPU...

В STM32F100, используемом ТСом, MPU нет ;) 10 лет, не 10, а вот нет :(

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


Ссылка на сообщение
Поделиться на другие сайты
В STM32F100, используемом ТСом, MPU нет ;) 10 лет, не 10, а вот нет :(

Это почему это? STM32F100 - это же вроде обычный Cortex-M3. Почему тогда там нет MPU?

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


Ссылка на сообщение
Поделиться на другие сайты
Это почему это? STM32F100 - это же вроде обычный Cortex-M3. Почему тогда там нет MPU?

Дык не реализовали; 100-й, 103-й, 105-й, 107-й (надысь ds смотрел) без MPU. В ProgrammingGuide на F100xx/F20xx/L1xxx английским по белому - "за наличие MPU смотрите в ds на конкретный контроллер". Вот L152 с MPU, о чём и в "features" и в общем описании отмечено.

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


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

склоняюсь к версии "дикого" указателя (неверное значение адреса или размера блока для копирования). Уж больно симптомы к этому располагают - ОЗУ зачищается (частично), а код не перезапускается (нет начального тестирования по словам ТС -значит сработал не RESET - и WDT с питанием скорее всего ни при чем). Возможно, неверный указатель на функцию забрасывает исполнение в случайное место.

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


Ссылка на сообщение
Поделиться на другие сайты
склоняюсь к версии "дикого" указателя (неверное значение адреса или размера блока для копирования). Уж больно симптомы к этому располагают - ОЗУ зачищается (частично), а код не перезапускается (нет начального тестирования по словам ТС -значит сработал не RESET - и WDT с питанием скорее всего ни при чем). Возможно, неверный указатель на функцию забрасывает исполнение в случайное место.

 

Есть полезная функция в Кейле

http://www.keil.com/support/man/docs/armcc...59124940593.htm

 

7.136 --protect_stack, --no_protect_stack

Inserts a guard variable onto the stack frame for each vulnerable function.

 

The guard variable is inserted between any buffers and the return address entry.

A function is considered vulnerable if it contains a vulnerable array. A vulnerable array is one that has:

Automatic storage duration.

A character type (char or wchar_t).

In addition to inserting the guard variable and check, the compiler also moves vulnerable arrays to the top of the stack, immediately preceding the guard variable. The compiler stores a copy of the guard variable's value at another location, and uses the copy to check that the guard has not been overwritten, indicating a buffer overflow.

 

/*******************************************************************************
*     Функции проверки переполнения стека
        Parameter: none
        Return:
КЛЮЧ КОМПИЛЯТОРА
--protect_stack
*******************************************************************************/
void * __stack_chk_guard = (void *)(0xDEADBEEF);     // initialize guard variable

// Called by stack checking code if guard variable is corrupted
void __stack_chk_fail(void)
{
    // переполнение стека
}

// тестер
void teststack(void)
{
    char buf[4];
    strcpy(buf, "123456"); // больше размера буфера
}

 

 

 

 

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


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

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

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

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

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

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

Войти

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

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