часто валиться hf. иногда указывает LR и PC на одно и тоже место.... но иногда на 0х0. Как отловить HF с LR и PC равным нулю?

Что видно:
- регистры R0..R3 указывают на память, довольно глубоко, туда, где либо стэк, либо куча лежать могут.
- R12 содержит что-то похожее на ключ, например, доступа во флэш.

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

Поэтому:
- попробуйте увеличить кучу и/или стэк. Это верно как для самописной системы, так и для осей с локальными стеками задач.
- если таки есть запись во флэш, проверить, куда запись идет.

Поставте нормальный обработчик HF и посмотрите подробнее.

Что есть нормальный обработчик? Где его взять? Есть пример?

Есть Fault регистры, по ним можно понять причину сбоя.
В отладчике можно найти команду, на которой улетает.

Всем привет. У меня тоже самое на stm32f103zet6. На обыкновенной команде Line_Config для экрана летит в hardfault. Сегодня целый день мучился,думаю завтра получится, сообщу.

Вот к примеру
http://forum.easyelectronics.ru/viewtopic....p;view=previous

Дальше его можно творчески расширить, чтобы он читал CFSR, HFSR и т.п.

Но судя по вашему первоначальному посту, у вас уже что-то такое есть

Да, именно такой. Но х893 предлагает не такой, как у меня, а нормальный. Вот я и спрашиваю - что значит нормальный?


Проблему решил. Есть связка.... во внешнюю периферию по SPI+DMA пишу данные.... в один момент в регистре дма с адресом памяти ОЗУ было не то значение. По DMA из SPI писалось куда-то не туда, происходил HF.

Например
1
2
3
и еще 100500 описаний хэндлера

Здесь немного более сложный случай...очень вероятно,что исключение возникло в результате команды pop {Rx-Ry,pc} компилятор генерирует эту команду при возврате из подпрограммы,т.е return..в стеке на смешении "PC" почему-то оказался ноль.....
попробуйте локализовать место так
1) объявляем глобальную переменную например int __pc;
2) в теле каждой написанной вами функции первым оператором делаем __pc=__current_pc();
3) возникло исключение-во вкладе disassemble переходим на адрес,хранящейся в этой переменной __pc и по семантике узнаем,в теле какой функции произошло исключение
ну и далее анализируем код..на вскидку-как можно реже пользуйтесь кейловскими(иаровскими) библиотечными функциями..как максимум-только malloc/free,все остальное заменяйте собственными реализациями

Еще топикстартеру надо сверить ревизии, а то мало ли, как в моем случае окажется...

http://electronix.ru/forum/index.php?showt...=121871&hl=

это действительно обоснованный практикой совет или просто по-пугать?
Честно интересуюсь, без стёба.

Видимо, речь идет про конкретный случай. Меня писать свой printf как-то не климатит...

Какой ужас. Рубрика "Вредные советы"

Да нет особого стёба. Я написал свой printf. Точнее просто сделал п/п вывода чисел различных. В том числе с плавучкой.
Вы же должны понимать как стандартный работает. Там через список передаются параметры и шаблон вывода. Получается, что при обработке тратится значительное количество памяти на стеке.
Но проблема, если честно, не в самом объёме а в том, что это достаточно сильно меняющееся число. Ну и когда у вас несколько задач используют printf, то при анализе размеров стека понимаешь, что его надо увеличивать. В зависимости от сложности выводимой информации, народ указывает размеры до 2к. Вот и получается, что использование printf в трёх задачах - 6к озу.
Применение своих п/п вывода экономит эту память. В моём случае скорости особой не требовалось, так как это происходило при выводе на дисплей, принтер, ну и в HTTP задаче.

Никто не призывает отказываться от стандартных п/п. Просто надо знать инструмент, который применяешь. В случае с printf, надо автоматически увеличивать объём стека ну и убедится что вы выделили его достаточно. В частности FreeRTOS это позволяет делать.

Ну вот это уже более развернутый ответ касающийся только printf
а то сразу

В многозадачной среде можно сделать переключение стека при вызове printf, естественно заблокировав его семафором.
Тогда не нужно закладывать дополнительный объём стека для printf для каждой задачи.

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

Сорри за офф ))

Оверинженеринг в вакууме.

Да ладно, это вы Явы не видели Вот там оверинжиниринг в полный рост.

Когда ушел в C++ на ARMах, в голый С не вернусь даже под дулом пистолета )))
Разница по размеру кода щас никого не волнует, да и нету там особой разныцы, зато читаемость и переносимость на порядки выше!
Скорость работы тоже не страдает. Я не использую исключения и работу с ними (пока что).
В обязательном порядке стоит ось, причем сделана обертка вокруг нее, чтобы она стала C++, ну, там классы потоков, программных таймеров, семафором и т.п.
Поменяю ось, поменяю обертку под нее, а весь остальной код во всех проектах вообще не изменится.
Так читаемость и переносимость кода возрастает в разы. Нет глубокой привязки ни к ядру, ни к процу, ни к компилятору, ни к оси.
Экономия времени на новых проектах просто чумовая!
Лень-матушка вынуждает так поступать - категорически ненавижу переделывать свою же работу, лучше сразу сделать нормально

Это и старый добрый Си умеет.
Вам нравится Си++ - почему бы и нет? Может быть, у меня просто такие проекты, но ни разу не ощущал потребности перейти на Си++. А просто так без причины как-то не хочется.

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



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

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

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

А вот в шарпе приоритет отдается динамике. Опять же очень многие вещи завязаны на GC.

Плюсы же дают возможность писать достаточно высокоуровнево, но там где надо - генерируемый код будет не медленее си

Хотя конечно процессоры развиваются и постепенно это будет волновать все меньшее количество людей

Именно! Тут главное - не отставать от поезда, иначе быстро спишут в утиль

Всё-таки чистое программирование и ковыряние в железе - сильно отличающиеся области деятельности. ИМХО, Си - достаточно простой и обозримый язык, чтобы железячник мог им достойно овладеть и строить сложные системы. Си++ уже выползает за пределы этой зоны, такие железячники - уже редкий зверь (вроде Вас). Там, где железо и софт делает один человек, Си никуда не денется.

Все это перешло в глубокий офф, ибо холивар - "C vs C++" - пожалуй самый бессмысленный и беспощадный холивар у программеров.
Одно время был "ASM vs C", я чуток застал те дремучие времена такого холивара (я про контроллеры, т.е. эмбеддерство, НЕ ПК), тоже самое ))
Придет время, C# или что-то подобное сменит C++....

Короче, вот простое сравнение:
Детишки носятся на велосипедах, подрастают и пересаживаются на мопеды/моциклеты, потом личное авто, а у более успешных личный самолет
Чистый С - это велосипед: для здоровья полезен, укрепляет мышцы, прост как 5копеек - починит даже безрукий. Но далеко на нем не уедешь и тем более не увезешь.
Но другое дело - моциклет и т.д .....

Понимаете о чем?

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

То же ООП вполне себе работает и в сях, просто местами оно похоже на закат солнца вручную

Чистый Си как-то практически остановился в развитии. Особенно это хорошо видно, если сравнить его с плюсами. Плюсы заморозились в промежутке 1998-2011. Однако стандарт 2011 дал уже много вкусностей, сейчас есть стандарт 14, в котором часть вкусностей углубили. Дальше речь идет о стандарте 17, в котором это движение продолжается.

В Си же за последние годы было добавлено крайне мало - навскидку атомики, bcd, может еще что по мелочи.

Ой не надо, я тока что пообедал


Это точно!

На самом деле не так сложно. Правда если использовать более базовые функции из библотеки.
Я делал принты через TCP и UDP -- познакомился.



Нет не понимаю. На Javа предлагаете писать или ХML, а может на Rational Rose?



Да нет никакого холивара. Тот же компилятор для С++ написан на С. Только если писать апликации, то конечно С++ кроет С, а вот с системным программированием пока все с точностью до наоборот. У часового мастера и у кузнеца разные инструменты.



От вас подвигов никто и не ждет. Есть же мы для этого

Однажды у меня был один сотрудник, который писал на Вижуал С. Он к эмбеддед программистам приставал, чтобы признали, что на РС тоже реал-тайм можно писать. С ним соглашались, чтобы отстал. И с вами согласимся.

Ну я же говорю - Оверинженеринг. У меня все проекты на С++. Ос - FreeRTOS на си. ни каких обёрток. Там где надо ООП - я использую ООП... делаю классы, инкапсуляцию, наследование, полиморфизм, динамика.... А где надо printf, да ещё он нужен только в одном месте, а именно в обработчике HF - зачем эти синглтоны и обёртки?

Если вам надо отъехать от дома на 10-20 км вы наверно на самолёте полетите.... а я на авто поеду... или даже на мопеде.

Действительно! Мы толкуем о разных вещах.
Холивар пустой и бессмысленный - все равно каждый останется при своем мнении.