Прошу помощи с STM32F051, Периодическое сваливание в HardFault Опции

[nanorobot]

Отлаживаю дивайс на STM32F051. интенсивно используется DMA - все каналы. Периодически (1 раз в 1- 4 часа) происходит HardFault.Ввел обработчик ХардФаулт из Definitive Guide, получил листинг регистров. Не могу полноценно осознать результаты. Судя по содержимому PC, инструкция, вызвавшая HardFault была расположена в RAM. Непонятно. Указатели на функции не использую.
Во вложении кусочек скриншота с регистрами.

Эскизы прикрепленных изображений

 

[Golikov A.]

ну типа

Код

char Array[10];
int *p = (int *)&Array[2];
*p = 10; //пипец %)

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

[Сергей Борщ]

Но передав это поле в функцию просто указателем будет опять обломс....

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

[KnightIgor]

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

Как правильно заметил Golikov A., обломс наступает при переносе библиотек.
У меня есть обработчик SVC, код которого базируется на широко цитируемых в сети примерах от ARM. Там, чтобы получить номер SVC из кода инструкции, есть выражение LDRB R0,[R0, #-2], где в R0 загружен сохраненный PC, который, очевидно, указывает на следующую за SVC инструкцию. Так вот, M0 НЕ ДОПУСКАЕТ отрицательные смещения. Хорошо, что ругня идет еще на этапе трансляции... Чтобы код был универсальным, пришлось сделать

SUBS R0, R0, #2
LDRB R0,[R0]

Сообщение отредактировал KnightIgor - Aug 18 2014, 07:51

[Сергей Борщ]

Как правильно заметил Golikov A., обломс наступает при переносе библиотек.

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

У меня есть обработчик SVC, код которого базируется на широко цитируемых в сети примерах от ARM.

То есть вас удивляет, что ассемблерный код для одного ядра не ассемблируется для другого??? А почему вас тогда не удивляет, что код для Пентиума не ассемблируется под 8086? Простите, но это напоминает анекдот:

- У меня на телефоне фотографии нечеткими получаются.
- Да ладно? Прикинь, а у меня с фотоаппарата вообще звонить нельзя!

[KnightIgor]

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

Я не валю, тем более упорно. Я подцепил вброс Golikov A. (перенос библиотек), который простекает из двух основных проблем программирования: нельзя видеть будущее (и написать библиотеку на все случаи жизни), и нужно обеспечивать совместимость с предыдущей версией. Это хорошо проснуться десятилетием позже и охватить все варианты мудрым взором. Но Вы ведь помните, что сначала был M3, а лишь много позже ARM замутил M0, который вдруг не понимает отрицательных смещений и невыровненного доступа. И куда податься крестьянину? Ответ: перепахать огород. Я, кстати, совершенно с Вами согласен, что строгое программирование (в обсуждаемом случае __packed) может избавить от косяков. Но только честно: пусть в нас кинет камень тот, чей код соответствует MISRA.

То есть вас удивляет, что ассемблерный код для одного ядра не ассемблируется для другого??? А почему вас тогда не удивляет, что код для Пентиума не ассемблируется под 8086? Простите, но это напоминает анекдот:
- У меня на телефоне фотографии нечеткими получаются.
- Да ладно? Прикинь, а у меня с фотоаппарата вообще звонить нельзя!

По поводу 8086 и Пентиума - я изложил в первом абзаце. Если пофилосовствовать же, то меня ничто не удивляет в мире диалектики. Ясно одно: чтобы понять настоящее, надо знать предысторию. Правда, один немецкий филосов сказал, что главный урок состоит истории в том, что никто не извлекает из нее уроков. Кстати, Ваш анекдот в части телефона никто бы не понял еще лет 20 назад. На Ваш анекдот отвечу другим:
- Почему Богу удалось создать мир всего да 6 дней?
- Не нужно было обеспечивать совместимость с предыдущей версией.

[LightElf]

Я не валю, тем более упорно. Я подцепил вброс Golikov A. (перенос библиотек), который простекает из двух основных проблем программирования: нельзя видеть будущее (и написать библиотеку на все случаи жизни), и нужно обеспечивать совместимость с предыдущей версией.

Написать вполне можно. Достаточно следовать простым правилам. В данном случае нарушено простенькое правило: нельзя приводить указатель от меньшего типа к большему. Из указателя на int делать указатель на char можно. А наоборот - нельзя.

Но Вы ведь помните, что сначала был M3, а лишь много позже ARM замутил M0, который вдруг не понимает отрицательных смещений и невыровненного доступа.

До Cortex-M3 был ARM7TDMI. Вполне логично ожидать, что ассемблерный код для одной архитектуры не будет переносим на другую архитектуру. На то он и ассемблерный код.

[KnightIgor]

До Cortex-M3 был ARM7TDMI. Вполне логично ожидать, что ассемблерный код для одной архитектуры не будет переносим на другую архитектуру. На то он и ассемблерный код.

"Логично ожидать?"
Тогда вопросы.
Когда был ARM7TDMI, было уже известно, что будет Cortex-M3?
Когда появился Cortex-M3, и инструкция с отрицательным смещением была допустима, было известно, что появится M0?
Если ARM приводит в 2009 пример для Cortex-M3, а именно на ассемблере (речь идет о SVC, и ARM прямо говорит, что без ассемблерной вставки никак), можно ли верить ARM и использовать код?
Что будем делать с time_t после 19.01.2038?

[Сергей Борщ]

Если ARM приводит в 2009 пример для Cortex-M3, а именно на ассемблере (...) можно ли верить ARM и использовать код?

Использовать для Cortex-M3 - можно. Этот же код для Cortex-M0 - чаще всего нет.

[KnightIgor]

Использовать для Cortex-M3 - можно. Этот же код для Cortex-M0 - чаще всего нет.

Сергей, Вы правы. В 2014 году. Для 2009-2010 высказывание смысла не имеет. Как никто бы лет 20 назад не понял, почему смешно, что телефон фотографировать может, а фотоаппарат не может звонить. Кстати, уже и фотоаппарат почти может, коль WiFi в нем уже есть. А лет 30 назад никто бы не понял фразу: "забыл трубу дома". Подумали бы, что музыкант.

П.С. Не удержусь, расскажу случай с собственным ребенком в садике. Дело было 2 года назад. В стране, где я живу, в саду проводят тесты, насколько хорошо дети владеют языком, чтобы вовремя отправить к логопеду, например, или позаниматься дополнительно в группе. Для этого им показывают картинки, просят назвать предмет, эмоции лица, и т.п. Родители могут молча присутствовать. И вот показывают моему мальцу картинку, на которой изображено что-то закругленно кубическое, красное, с кругом посередине и точками. Он смотрит долго, хмыкает и говорит: "божья коровка". Тетка начинает ставить наводящие вопросы. Реакция та же - жук, и все. Тогда тетка раскрывает ребенку глаза на этот удивительный мир и утверждает, что изображен телефон (для меня было очевидно: телефон с тубкой сверху, наборной диск с дырочками). На что мой малец говорит: "это не телефон, телефон - с кнопочками и картинкой". Вот так. Что скажут его дети на нынешние смартфоны, имея вживленные сети с приемом прямо в мозг?

Сообщение отредактировал KnightIgor - Aug 18 2014, 16:49