Hard fault на EXTI Опции

[pitt]

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

Спасибо.

[smalcom]

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

[mantech]

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

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

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

[pitt]

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

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

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

[aaarrr]

От чего-же, все-таки, может вылезти Hard fault?

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

[smalcom]

т.е. прога зависнет на обработке прерывания и всего-то

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

[zltigo]

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

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

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

Именно так.

[mantech]

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

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

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

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

Сообщение отредактировал mantech - Oct 18 2015, 20:35

[pitt]

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

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

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

Сообщение отредактировал pitt - Oct 18 2015, 20:42

[zltigo]

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

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

[aaarrr]

- Hard fault viewer чаще всего не дает достаточно информации

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

[zltigo]

- Hard fault viewer чаще всего не дает достаточно информации

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

[pitt]

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

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

[aaarrr]

не написано в известной мне документации как, например: link

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

[AHTOXA]

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

[zltigo]

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

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

[pitt]

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

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

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

Сообщение отредактировал pitt - Oct 18 2015, 23:59

[jcxz]

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

Открываем 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, в котором применяем полученные пунктом выше знания.

[pitt]

[aaarrr]

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

[pitt]

[aaarrr]

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

[pitt]

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

So what is the fault reason then?

[aaarrr]

So what is the fault reason then?

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

[pitt]

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

Сообщение отредактировал pitt - Oct 19 2015, 16:03

[zltigo]

So what is the fault reason then?

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.

[pitt]

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.

[zltigo]

What could be causing this to happened?

An attempt to switch to an invalid state.

[pitt]

An attempt to switch to an invalid state.

Obscurum per obscurius

[aaarrr]

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

[zltigo]

Obscurum per obscurius

Oculos habebat et not videbat

[pitt]

Oculos habebat et not videbat

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

Сообщение отредактировал pitt - Oct 19 2015, 17:41

[ViKo]

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

Код

__asm void HardFault_Handler(void)
{
  TST LR, #4
  ITE EQ
  MRSEQ R0, MSP        ; Main Stack was used, put MSP in R0
  MRSNE R0, PSP        ; Process Stack was used, put PSP in R0
  LDR R0, [R0, #24]    ; Get stacked PC from stack
  B .
}

[zltigo]

А регистры состояния в отладчике видны, как в AN209 показано.

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

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

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

[pitt]

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

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?

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

Est proprium stultitiae aliorum vitia cernere, oblivisci suorum

[zltigo]

Est proprium stultitiae aliorum vitia cernere, oblivisci suorum

Нang the blame on someone else .

[pitt]

Нang the blame on someone else .

Injuriam facilius facias quam feras

[aaarrr]

SP = 0x200043A0

0x200043B4 080064E7

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

[pitt]

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

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





Сообщение отредактировал pitt - Oct 19 2015, 19:22

[aaarrr]

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

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

[pitt]

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

[pitt]

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

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

[smalcom]

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

Проблему я решил.

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

[Golikov A.]

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

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


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

[zltigo]

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

Да.

[mantech]

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

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

[zltigo]

ибо копаться в регистрах в данном случае, это терять время, особенно, если "не очень" в армовском асме, ИМХО, конечно

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

[Golikov A.]

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

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

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

[aaarrr]

По регистрам вы найдете где улетела...

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

[zltigo]

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

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

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

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

CODE

Abort:[D] PC:000000D0 Op:E4940004 CPSR:200000D3
   LR:7FFFE35F SP:40000180
SP[0]:000000D0->E4940004->200000D3->7FFFE35F->
SP[4]:40000180->7FFFE35B->400001C8->00000008
Test:AC0F9D3F
R0:7FFFE35B R1:400001C8 R2:00000008 R3:A100DA57  R4:BFB79FEA  R5:600000D3
R6:0000001F R7:1303D214 R8:67A9084B R9:104B3212 R10:D0F03A0C R11:96195E20
R12:1F496802

ТС локализовал проблему...

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

[pitt]

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

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


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

Absolutely not. I did find what is happening and just now figure out exactly why and what is the case. The short answer is alignment. The exti_s struct is in the one .h file used by two different .c files. One treats it as packed(expected behaviour), another is not. That is how one static variable overwrites another.


Sermo animi est imago: qualis vir, talis et oratio est

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

Help is always possible but desire and patience are required.


Сообщение отредактировал pitt - Oct 20 2015, 14:19

[smalcom]

да используйте уже наконец http://electronix.ru/forum/index.php?showforum=92
или DNS теперь по-умолчанию на edaboard редиректит?

[Golikov A.]

Да русский он, на английском пишет для солидности

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

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

Если вы пакованную структуру передаете в функцию, объявите в функции прием пакованных параметров на вход, и должно полегчать. А еще лучше через typdef сразу объявить пакованную структуру и как структуру и как подставляемую в функцию переменную.