Например TDA7294

Форум РадиоКот :: Просмотр темы - Hard Fault Cortex M3
Форум РадиоКот
https://radiokot.ru/forum/

Hard Fault Cortex M3
https://radiokot.ru/forum/viewtopic.php?f=59&t=172644		 Страница 1 из 2
Автор:  Alex-Elektron [ Пн сен 07, 2020 12:28:07 ]
Заголовок сообщения:  Hard Fault Cortex M3
Доброго времени суток! Ранее не сталкивался с падением кода в Hard Fault, но недавно это случилось. Запустил дебаг в Keil, при падении получаю следующую картину:
Изображение
Не могу идентифицировать, на что указывает содержимое регистра SCB->BFAR = 0x20031CDA... Там, как я понял, можно найти причину падения.
Содержимое регистра PC (на сколько понял, в нём сохранён адрес инструкции, вызвавшей падение) при этом ссылается на начало функции main(), на строку, где я присваиваю значение переменной. Но до момента падения код может спокойно и чётко выполняться в течение часа и более.
Изображение

Есть идеи, куда нужно копать?

Добавлено after 1 hour 18 minutes 40 seconds:
Камень использую STM32L151CB-A. У него 128к флэша и 32к оперативы. Оператива начинается с 0x20000000, оканчивается соответственно 0x20007D00. Периферия начинается с 0x40000000. Так вопрос, тогда куда меня посылает дебаг по адресу 0x20031CDA?
Автор:  Мурик [ Пн сен 07, 2020 12:31:31 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Причину легко найти посмотрев в стеке последовательность вызовов функций. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599
Автор:  VladislavS [ Пн сен 07, 2020 13:08:16 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Alex-Elektron писал(а):
Не могу идентифицировать,
Там же галка PRECISERR стоит.
https://www.keil.com/dd/vtr/5094/8687.htm
Автор:  Alex-Elektron [ Пн сен 07, 2020 13:28:19 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Всё верно, галка стоит, смотрим адрес инструкции в PC.
Цитата:
Содержимое регистра PC (на сколько понял, в нём сохранён адрес инструкции, вызвавшей падение) при этом ссылается на начало функции main(), на строку, где я присваиваю значение переменной.

Ну так вот, никак прога не может туда попасть, только через ресет

Добавлено after 3 minutes 34 seconds:
Мурик писал(а):
Причину легко найти посмотрев в стеке последовательность вызовов функций. http://purebasic.mybb.ru/viewtopic.php?id=564#p7599

Жду падения кода, чтобы глянуть на стек вызовов. Уже час прошёл с момента запуска
Автор:  jcxz [ Пн сен 07, 2020 16:23:52 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Alex-Elektron писал(а):
Ранее не сталкивался с падением кода в Hard Fault
Видимо Вы:
а) или раньше не работали с Cortex-M;
б) или очень аккуратный программист.
8)
Alex-Elektron писал(а):
Содержимое регистра PC (на сколько понял, в нём сохранён адрес инструкции, вызвавшей падение)
Не совсем так. Видимо это содержимое PC при котором произошёл HF. Хотя при PRECISERR - это одно и то же.

Добавлено after 1 minute 45 seconds:
Alex-Elektron писал(а):
Ну так вот, никак прога не может туда попасть, только через ресет
Может. Если где-то портите стек.

Alex-Elektron писал(а):
Жду падения кода, чтобы глянуть на стек вызовов. Уже час прошёл с момента запуска
Если причина HF - порча стека, то это ничего не даст. А с большой вероятностью это она и есть.

Увеличивайте все стеки на максимум, заполняйте шаблоном и после некоторого времени работы проверяйте уровень заполненности.
Автор:  Alex-Elektron [ Пн сен 07, 2020 16:43:34 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Цитата:
б) или очень аккуратный программист.
7 лет кортексы прогаю, но всё бывает впервые))
Подсказать можете, где в дебаггере глянуть заполненность ОЗУ?
Автор:  jcxz [ Пн сен 07, 2020 16:48:16 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Alex-Elektron писал(а):
7 лет кортексы прогаю, но всё бывает впервые))
7 лет "прогаете" и не знаете что такое "порча стека"?? Не верю!!! 8)

Alex-Elektron писал(а):
Подсказать можете, где в дебаггере глянуть заполненность ОЗУ?
Не ОЗУ, а стека. Смотрится на вкладке "память" или как она там в кейле зовётся.
Автор:  Alex-Elektron [ Пн сен 07, 2020 18:27:00 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Похоже, проблема с переполнением стека действительно имеет место быть. Заглянул в область оперативы при падении - от макушки до низа была занята. Хочу посмотреть на заполнение стека в процессе, нашёл способ "окраски" с помощью такой функции:
Код:
#define STACK_CANARY_WORD (0xCACACACAUL)

volatile unsigned *top, *start;
__asm__ volatile ("mov %[top], sp" : [top] "=r" (top) : : );
start = &_ebss;
while (start < top) {
    *(start++) = STACK_CANARY_WORD;
}


взял отсюда, вставил в конец стартапа - ничё не окрасилось.

Вопроса два:
1. Как всё-таки окрасить стек, куда правильно воткнуть эту функцию?
2. Что можно сделать для уменьшения расхода стека?

Добавлено after 11 minutes 27 seconds:
К стати, вопрос, что мне хотел сказать дебаггер записью SCB->BFAR = 0x20031CDA, для меня остался открытым. Перешёл по этому адресу, а там космос, память не доступна для чтения, оно и понятно, её там нет и быть не может
Автор:  jcxz [ Пн сен 07, 2020 18:33:56 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
А что должно было "окраситься"? :dont_know:
Alex-Elektron писал(а):
1. Как всё-таки окрасить стек, куда правильно воткнуть эту функцию?
Куда угодно. Главное выполнить её когда ещё стек не порушен.

Alex-Elektron писал(а):
2. Что можно сделать для уменьшения расхода стека?
Переработать алгоритм программы.

Alex-Elektron писал(а):
К стати, вопрос, что мне хотел сказать дебаггер записью SCB->BFAR = 0x20031CDA, для меня остался открытым.
Видимо адрес, по которому обратилась ваша программа (обратилась та команда, адрес которой в PC).
Если произошло разрушение стека, то на это можно вообще внимания не обращать - это не причина HF, причина - разрушение стека.
А вообще - описание регистров ядра есть в мануале на ядро Cortex-M.
Автор:  Reflector [ Пн сен 07, 2020 18:35:11 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Alex-Elektron писал(а):
К стати, вопрос, что мне хотел сказать дебаггер записью SCB->BFAR = 0x20031CDA, для меня остался открытым. Перешёл по этому адресу, а там космос, память не доступна для чтения, оно и понятно, её там нет и быть не может

Тут есть пример, ищи Bad Address Read.
Автор:  iddqd [ Вт сен 08, 2020 10:20:59 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Возможно, у вас большая цепочка вызовов функций, при том что RAM и так занят, а там еще какое-нибудь прерывание стэк жрет - и в какой-то момент стэка однажды не хватает? Далее возможны варианты. Если у вас стэк был НАД переменными - вообще скажите спасибо что упало в hard fault а не просто глючило, перетерев стэком область переменных.

И не знаю как в кейле а gcc умеет репортить использование стэка и показывать наиболее прожорливые по стэку функции, вот как раз на такие случаи. Может прошляпить что-нибудь типа рекурсии или VLA, но так делать не надо. Наверное и в кейле что-то такое есть? Ну и как-то странно вы 7 лет эти штуки программили что не можете убедить их стэк константой заполнить. А "Как всё-таки окрасить стек, куда правильно воткнуть эту функцию?" - ответ на этот вопрос требует как минмум знания лэйаута RAM и понимания кто и что делает до и после вызова этой функции. И как это в кейле.

Я бы вообще
1) сперва проверил что ваша конструкция вменяемое значение адреса стэка в принципе возвращает.
2) а потом - что начало и конец стэка не перепутаны, что из вашего описания не совсем очевидно. А start действительно меньше top?
3) и хрен его знает насколько там оптимизатор прикалывается, оптимизатор на раз видит что результат нигде не используется и норовит забить на всю операцию. Формально volatile есть но лучше проверить что код по факту сгенерился и вызывается.
4) кто-нибудь опосля может что-то инициализировать наверное.

А так - я например стэк повесил в самом низу, если переполняется - hard fault сразу, за факт обращения ниже 0x20000000, еще на моменте сохранения в стэк процом. Порушиться соответственно не успевает (однако часть стэкфрейма потеряна, корректно вернуться нельзя, равно как и трейс будет инопланетный). А у handler'ов на такой случай я свой стэк в msp, выше основного сделал, так они свой стэк получат в любом случае. В L15x наверное можно MPU и без этого обойтись, но в F1xx MPU нету...

Цитата:
Перешёл по этому адресу, а там космос,

При переполнении стэка код дуреет а состояние системы разрушено. Может быть что угодно - состояние системы нельзя считать достоверным. Бывает и похуже чем harffault, у тойот например водитель отпускал педальку - а авто уходило в разгон, потому что стэк вырос ниже области переменныз, перетер переменные - и вообще красота. С тех пор некоторые стали класть переменные выше стэка - harffault лучше чем это. А как у вас - кто ж его знает, весь layout не видно. А куда указывает тот или иной адрес по идее в map-файле пишется. Если кейл конечно умеет что-то такое генерить. Наверное должен, это почти любой вменяемый компилятор умеет.
Автор:  jcxz [ Вт сен 08, 2020 12:02:28 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Похоже здесь народ под "порчей стека" понимает только "переполнение стека". Хотя я вроде ясно выразился именно "порча стека", а не только его переполнение.
Переполнения может и не быть, а содержимое стека испортиться из-за багов в программе (например: из-за обращения по указателю к локальным переменным (на стеке)).
Порчу содержимого стека не увидеть всякими заполнениями шаблоном и просмотром в отладчике. :dont_know:
Автор:  iddqd [ Вт сен 08, 2020 14:34:26 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Как бы я понимаю почему можно прошляпить окончание стэка, особенно если сдуру вызвать стопкой черт знает что. Но вот указателями стэк вынести - относительно нехарактерно, особенно для встраиваемых систем. Конечно дурным использованием указателей можно что угодно сделать - но это и аргумент за то чтобы ими пользоваться минимально, только иначе совсем никак. Так что если кто указателями, натурально, стэк снес - у него проблема, наверное, гораздо фундаментальнее. В таком случае первое что стоит сделать - код доктору статическому анализатору, чтоли, показать и методично починить все подозрительные места.
Автор:  jcxz [ Чт сен 10, 2020 14:02:13 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
iddqd писал(а):
Но вот указателями стэк вынести - относительно нехарактерно, особенно для встраиваемых систем.
Элементарно:
Код:
void Func()
{
  char buf[4];
  char *s = &buf[0];
  ...
  s[4] = x;
  ...
  sprintf(s, "%u", 12345);
  ...
}

iddqd писал(а):
Так что если кто указателями, натурально, стэк снес - у него проблема, наверное, гораздо фундаментальнее.
Элементарная невнимательность. Сначала написал код, а потом что-то добавил не глянув на размер буфера.
Автор:  iddqd [ Чт сен 10, 2020 18:10:31 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
Код:
  sprintf(s, "%u", 12345);
Кошмар, это в фирмвари МК такое?! :shock: За такое сейчас в обычных то программах в приличных местах норовят покрыть матом статическим анализом и проч - чревато крахами а то и уязвимостями :kill:. Эту функцию вообще использовать не следует. Она с самого начала проблемная.
Цитата:
Элементарная невнимательность. Сначала написал код, а потом что-то добавил не глянув на размер буфера.
Поэтому умные люди давно придумали штуки типа правил MISRA, исключающие подобные ситуации. Как мне кажется, при серьезном увлечении МК неплохо бы прочитать что-то такое, чтоли. Тогда писать такой код просто в бошку не придет, на уровне рефлексов просто.

Пардон за флейм, лучше пойду dma по кольцу кодить. Вот оно стремноватое by design, это да. Но там на это есть хорошие причины хотя-бы.
Автор:  jcxz [ Чт сен 10, 2020 18:24:42 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
iddqd писал(а):
Эту функцию вообще использовать не следует. Она с самого начала проблемная.
Это для примера. Разумеется - лучше использовать какой-то вариант sprintf() с контролем размера буфера. Но это не убережёт от ошибок в арифметике указателей.

iddqd писал(а):
Тогда писать такой код просто в бошку не придет, на уровне рефлексов просто.
Не писать код с указателями? Да, можно конечно на яве писать, но при этом потеряв кратно в эффективности и быстродействии кода.
Тогда уж и на бейсике можно. :)))

Можно ведь и котлован под дом копать детским совочком. Ведь ежли экскаватором - то можно и покалечить кого-нить невзначай. А совочком - оно безопаснее ведь, правда?
Вот только почему-то не отказываются от экскаваторов.... :dont_know:
Автор:  Мурик [ Чт сен 10, 2020 20:10:43 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
jcxz писал(а):
Тогда уж и на бейсике можно.
Чем вам бейсик неугодил что вы его приравняли к java? :facepalm:
Для армов бейсиков немного (а те что есть не самые лучшие), а для компа встречаются хорошие экземпляры. :)
Автор:  iddqd [ Пт сен 11, 2020 09:43:06 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
jcxz писал(а):
Это для примера. Разумеется - лучше использовать какой-то вариант sprintf() с контролем размера буфера. Но это не убережёт от ошибок в арифметике указателей.
Поэтому ее должно быть как можно меньше и только по делу, под особым вниманием, логично же.

Цитата:
Не писать код с указателями? Да, можно конечно на яве писать, но при этом потеряв кратно в эффективности и быстродействии кода.
Вообще не использовать указатели не получится - хотя-бы для регистров все же надо. Но вот арифметика там ни к чему - все можно как compile-time constant оформить. Это сильно уменьшает риски. И как сказал один почтенный человек, преждевременная оптимизация - корень всех зол. Глядя на это - а ведь он прав!

Цитата:
Тогда уж и на бейсике можно. :)))

Мне кажется есть 2 полюса:
- Ламеризм типа бэйсика, когда програмер не рубит что и почему, оптимальность - "индусы лучше". За програмера подумает бэйсик. А может и не подумает, как это часто оказывается. Но в этом случае картина выглядит жалко.
- Хакеризм, код изобилует выходками во имя эффективности а то и трюкачества. Код может и эффективный, но баги крайне неочевидные, а попытка что-то менять, особенно другим человеком - ломает все. К тому же програмер и сам через год забудет где свинью разложил.

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

Цитата:
Можно ведь и котлован под дом копать детским совочком. Ведь ежли экскаватором - то можно и покалечить кого-нить невзначай. А совочком - оно безопаснее ведь, правда?
Вот только почему-то не отказываются от экскаваторов.... :dont_know:
Еще можно пригнать состав с динамитом и взорвать. Пусть экскаваторщик выкусит! Сколько он с таким котлованом копаться будет?! А тут бах и готово. Потом правда никто не понимает на что указывает табличка "дом номер 20". Толи эти руины и правда он, толи ее взрывом принесло.

p.s. а на месте жавистов я бы обиделся что их к бэйсику приравняли. Эти по крайней мере бизнеслогику кодят, любителей бэйсика туда никто близко не подпустит.
Автор:  jcxz [ Пт сен 11, 2020 14:34:33 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
iddqd писал(а):
Но вот арифметика там ни к чему - все можно как compile-time constant оформить.
Не можно. Если реализуете задачу сложнее чем мигание парой лампочек. В реальных задачах без указателей или индексов в массивах - не обойтись никак.

iddqd писал(а):
Это сильно уменьшает риски.
Не рискует только тот, кто ничего не делает.
Автор:  iddqd [ Пт сен 11, 2020 23:42:05 ]
Заголовок сообщения:  Re: Hard Fault Cortex M3
jcxz писал(а):
Не можно. Если реализуете задачу сложнее чем мигание парой лампочек. В реальных задачах без указателей или индексов в массивах - не обойтись никак.
Смелое утверждение, а как насчет обосновать? Само по себе это вроде ниоткуда не следует. И при желании можно обойтись и без индексов, и уж тем более без указателей. К тому же для массивов фиксированной длины даже компиляторы умеют ловить наиболее очевидные тупняки, а статические анализаторы и куда менее очевидныве. Правда таковые очень придирчивы, особенно если вопрос касается указателей - и могут отбить охоту так делать вполне естественным образом.

На мой вкус, если в результате оптимизаций заканчивается вынесенным стэком - возникает вопрос: а оно того стоило?!

Цитата:
Не рискует только тот, кто ничего не делает.
Почему-то при этом вспоминаются горы мяса и металла пытавшиеся проскочить перед поездом. Они, несомненно, пытались оптимизировать себе 2 минуты времени, но глядя на результат вышеупомянутый вопрос все же возникает. Как мне кажется, не любая оптимизация стоит рисков. И если кто-то в результате выносит стэк... это даже на PC у раздолбайских програмеров нехилая экзотика.
Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/