Использую RTX. Запрограммировал пин на внешнее прерывание(любое измемение). Обрабатываю прерывание простой посылкой сигнала основной системе и взводом прерывания. Работало долго и без проблем. Вдруг стал появляться Hard fault. Вскрытие показало, что плохой коннектор приводит к тому, что пин просто висит в воздухе как антенна. Т.е. я предполагаю, что происходит множество запросов на прерывание, до его обработки. Каким-то образом, это и приводит к Hard fault. Что не так с софтом? Что я недоучел?

Спасибо.

не все флаги может сбрасываете? происходит повторный вход и так до исчерпания памяти.

Вообще-то за такое - 2 по схемотехнике. Нога не должна болтаться в воздухе в 3м состоянии, так и МК запалить - дело секундное.

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

Работаем с тем, что имеем...
От чего-же, все-таки, может вылезти Hard fault? Кстати, это происходит не моментально, а по прошествии некоторого неопределенного времени, но, в конце концов, ВСЕГДА.

Можно строить версии и догадки, а можно обратиться к статусным регистрам и содержимому стека. Второй вариант быстрее и надежнее.

точно. я перепутал.
получается что возможна следующая ситуация: в обработчике прерывания сначала сбрасывается флаг, а потом выполняется какая-то работа. т.о. возможен повторный вызов обработчика.

Дурость написали.



Именно так.

Дурость- не дурость, а пара МК в свое время сдохла из-за этого.



В случае вложенных прерываний так и будет.

Можно и даже нужно. Вот только:
- Hard fault viewer чаще всего не дает достаточно информации
- переполнения стека НЕТ и все маркеры на месте
- в пошаговом режиме(break point в обработчике) все работает как часы

Да, прерывания от подвешенной ноги возникают и обрабатываются. Я специально встроил счетчики вошел/обработал и пока нет Hard fault все как и ожидается, а потом вдруг раз и Hard fault ...
Тут-то и нужны версии и догадки...

Смеяться или плакать предлагаете?

Так возьмите сами. Какая информация нужна - адрес? причина? - все доступно в регистрах и стеке.

Не порите чушь.
Адрес команды вылета, регистры и стек при вылете получаются вне зависимости ни от каких неведомых "вьюверов".

Г.уру, от щедрот переполняющих Вас знаний, не изволили бы Вы обучить порющих чущь Вашему великомудрому умению читать то, что к моему глубокому сожалению, не написано в известной мне документации как, например: link. Кстати, тамже Вам и предоставится шанс познакомиться с "неведомым вьювером".

И что же там не написано?

pitt, посмотрите вот эту тему.

Присоединяюсь к вопросу. По сылке все разжевано буквально. Картинки, правда зачем-то еще напиханы. Видимо в этих-то картинках чего-то Автор и не нашел, а читать буквы и думать не стал .

Спасибо, AHTOXA, обязательно. Завтра попытаюсь сделать скриншот с Hard fault viewer.
Меня огорчает отсутствие идеи отчего может вылететь... Я не один Hard fault разрешил и, в основном, были проблемы с управлением памятью. Тут не в памяти дело...

Попытался просимулировать дома, без RTX : прерываний тьма, Hard fault не происходит. Специально задерживал обработку - фиксировал вход с необработанным прерыванием. НЕТ проблем.

Открываем Cortex-M3 Technical Reference Manual либо юзер-мануал на какой-либо МК с ядром Cortex-M, ищем "Hard Fault Status Register", "Configurable Fault Status Registers", "Mem Manage Address Register", "Bus Fault Address Register", "Auxiliary Fault Status Register" и пр. И внимательно читаем.
Далее - пишем ISR HardFault, в котором применяем полученные пунктом выше знания.

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

Ну а смысл в этой картинке, если MMARVALID=0?

So what is the fault reason then?

The processor has attempted to execute an instruction that makes illegal use of the EPSR.

Thank you, but could you please not just quote Keil web site and give me some more useful clues.
ARM

The UFSR has bit 1 set reporting an attempt to switch to an invalid state. The HFSR has bit 30 set indicating that the Usage Fault was escalated to a Hard Fault. This is consistent with the debugger source window that shows the PC at the Hard Fault handler address.

Thank you.
What could be causing this to happened? As I stated before, I wasn't able to simulate such condition at home without RTX.

An attempt to switch to an invalid state.

Obscurum per obscurius

Прочитайте наконец свой же документ со стр. 12 и ниже.

Oculos habebat et not videbat

Aliena vitia in oculis habemus, a tergo nostra sunt.
Docendo discimus

Я в обработчике HardFault нахожу адрес программы, с которого процессор улетел. Больше мне, собственно, ничего не нужно. А регистры состояния в отладчике видны, как в AN209 показано.

Чукча не читатель. Чукча писатель вопросов. Ответов, даже столь разжованных, как этом самом AN209, он не понимает .

LR и стек все-же нужен - отследить вызовы, ибо далеко не всегда виноват именно код в этом месте.

From my .map:

os_dly 0x20003fc8 Data 24 rt_list.o(.bss)
__initial_sp 0x200043e0 Data 0 startup_stm32f40_41xxx.o(STACK)

SP = 0x200043A0
R14= FFFFFFF1

0x200043A0 20001E94
A4 08000000
A8 0
AC 0
B0 0
B4 080064E7


Code:
0x080064E4 BLX, r1
0x080064E6 POP (r4, pc)




Does it mean that I've exhausted RTX(idle) stack?



Est proprium stultitiae aliorum vitia cernere, oblivisci suorum

Нang the blame on someone else .

Injuriam facilius facias quam feras

Внимание, вопрос: что находится в stack frame по этому смещению?

If I understood your question correctly, but I'm not sure....

Нет, я задавал вопрос более общего характера. Итак, что находится в stack frame по смещению 0x14?

Проблему я решил.
К моему сожалению, все это копание с регистрами ни к чему не привело. Извините, не могу понять, как оно помогает другим. Справился путем комментирования кусочков кода...
К еще большему сожалению, не понял природу проблемы, которая заключалась в том, что в СТАТИЧЕСКОЙ переменной типа exti_s(структура, описывающая EXTI), портился указатель на обработчик прерывания. Причем, его портила другая и тоже СТАТИЧЕСКАЯ переменная совершенно другого типа, но из того же файла. Почему?!
Буду весьма благодарен, если квалифицированно, без раздувания ноздрей, закатывания глаз, выкатывания губ и глубокомысленных замечаний об'ясните, а иначе, пожалуйста, не утруждайте себя, используйте энергию в мирных целях.

В любом случае, большое спасибо тем, кто старался помочь.

покажите sym-файл, сразу или потом покажите исходники.



чот я не понял. вы исправили ошибку?

правильнее сказать методом тыка обнаружили место куда вбить костыль чтобы ошибка перестала проявляться как раньше.

Без кода одна статическая переменная может портить другую статическую переменную только из вредности. Это я опускаю тот факт что вообще переменная переменную испортить не может а вот программа работая с переменными может.


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

Да.

Тут что-то явно глубже обработчика EXTI. Автору надо внимательно пересмотреть код, особенно тот, что модифицирует эти переменные, ибо копаться в регистрах в данном случае, это терять время, особенно, если "не очень" в армовском асме, ИМХО, конечно

"копатся в регистрах" к ассемблеру имеет дело второе - результат "копания" это нахождение по адресам места в исходнике которое приводит к вылету. И абсолютно НИЧЕГО сложного в этом нет, если голова на плечах есть и возможность думать. Ну а если по принципу "а чего тут думать - трясти надо", то тогда, конечно "время терять" .

Ну вы как всегда категоричны.

вот вам сценарий программа на 5 секунде работы портит память, а через 4 часа обращается по указанному в этой памяти указателю. В результате улет и трам пам пам. По регистрам вы найдете где улетела, а почему улетела - нет. Опять же есть вариант долгой цепочки не фатальных пакостей которая кончается бедой, так что не всегда анализ регистров - абсолютное добро которое решит все проблемы.

ТС локализовал проблему порча вектора в переменной, теперь надо локализовать когда это происходит, и тщательно проанализировать почему....

А автор не нашел, несмотря на наличие содержимого stack frame и "мурзилки" с его описанием. Чем тут можно помочь?

Вы же уже сами сказали - испорчена совершенно конкретная область памяти. Круг поисков ОЧЕНЬ сузился. Фактически до рассмотрения ошибок работы с соседними переменными.

Вообще-то я писал и про стек. По нему видна в том числе и цепочка вызовов, посему найти виноватого в том, что какая-нибудь memecpy() вызывает вылет, совершенно реально.
Вот, например, моя типичная диагностическая распечатка в лог при вылете:



Что он там "локализовал", не понимая НИЧЕГО в собственно процессе локализации, никому не ведомо.