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

Стека точно хватает?

Вопрос интересный... Яровские установки = default

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

увеличил размер стека в 1.5 раза. не помогло.

Причина HardFault описана в Fault регистрах. В той же книге они описаны. Я всегда сначала там роюсь, а потом адрес, с которого улетел, смотрю.

Если Вы имеете в виду регистры CFSR и HFSR то в M0 их нет, только в M3/M4. А адрес с которого улетело, есть адрес в области RAM. Программа же расположена во FLASH, и не использует никаких трюков с выполнением из RAM и указателей на функции. Отсюда мой ступор.

С CM0 знаком меньше. Может, таблица векторов прерываний переназначилась на ОЗУ?

Явно в какой-то процедуре затирается стек (LR странный), и при возврате из нее процессор попадает в никуда. Стек затирается видимо ввиду нарушения границ какой-то локальной переменной (массива), объявленной в процедуре. Почему так редко? Ну может наступает некое условие раз в час, например, особое время суток в часах реального времени. А может происходит неверная инициализация DMA, который влазит на чужую область памяти. Например, принимается пакет извне (через UART и т.п.), пакет содержит поле длины, эта длина оказывается изредка неправильной, проверка границ не происходит, DMA грузится слишком "длинно" и влазит в чужой огород.

Если глянуть на регистры R1 и R2, можно также увидеть, что они указывают в RAM. Возможно по их значениям и карте памяти для секции RAM можно определить, какие переменные там есть, и, таким образом, по имени переменных и по тексту кода "вычислить" процедуру, которая ломает стек. Да и R3 содержит 0x4B0 = 1200 - больно круглое число, чтобы быть случайным. Это указывает на какой-то счетчик (например, из for ()). Вот гляньте, нет ли в коде процедуры, которая чего-то там прописывает с этой длиной.

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

Благодарю за развернутый ответ. Буду копать в указанных направлениях.

Это и не обязательно. Cortex может сохранять адреса возврата из функций на стеке. Если Вы его каким-либо образом разрушаете, то при попытке возврата выполнение может
улететь куда угодно (или сразу в fault).


Там не только LR странный, но и PSR к примеру.
Сдаётся мне, что это никакое не содержимое регистров в момент fault-a, а просто ТС привёл нам мусор.
Вот например, что выдаёт мой обработчик критических ошибок при возникновении
BUS FAULT: неточная ошибка при обращении к данным (imprecise data bus error) (ловушка 123):
Нажмите для просмотра прикрепленного файла
Всё чётко видно где произошло, при каких регистрах и стеке.

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

Пристойно? И 24й бит PSR тоже?
И биты 0...8 тоже? А ведь они говорят, что этот fault у вас случился типа внутри ISR с номером 0x160. У вашего M0 столько источников прерываний??? Я даже у M3 более примерно полусотни-то не видел....
То что Вы приводите не имеет никакого отношения к регистрам либо "их копиям в верхушке стека".

Извините, если что не так. Вы меня неправильно поняли. "Пристойно" они выглядят не в приведенном случае, а в том, когда я программно создаю ситуацию HardFault от кнопки.
а текущий случай не укладывается ни в какие рамки. Возможно ситуация осложнена модификацией стека, или чем либо еще, но она именно такова.

Тогда эта модификация стека произошла в вашем обработчике HardFault.
Вы же вроде пытаетесь привести результат стекинга на входе в HardFault?
Вот как раз такого результата быть не может, как я вам выше уже показал.
Скорей всего Вы неправильно определили положение верхушки стека прерванной программы.

Осознавая недостаток собственной компетенции обработчик взял из Definitive Guide

Со стеком разобрался. Нашел точку в которой происходит HardFault.
Точка - chSemSignal(&semAdc) - использование сервиса RTOS Nil(ChibiOs) от Jiovanni di Sirio.
В чем там косяк - только предстоит выяснить.

Всем спасибо за помощь.

Вы упустили выбор MSP / PSP, посмотрите в книге перед тем обработчиком, который показали.
О, так у вас ОС есть. А с ней оба регистра указателя стека используются.

Thank. День прожит не зря. ))

Гляньте, выровнена ли переменная/структура (и ее поля) semAdc: для M0 это критично. Если M3 скушает структуру типа:
__packed {
U8 a;
void *p;
},
и не подавится (то есть, когда указатель p явно по нечетному адресу), то в M0 попытка обратиться через *p вызывает hard fault. На это я наткнулся, когда переносил библиотеку с M3 на M0. Т.к. структура у меня должна была оставаться __packed, пришлось перетасовать поля, чтобы указатели были по четным адресам.

Если структура __packed, то выравнивание полей значения не имеет - компилятор собирает каждое поле побайтово.

данная инструкция выполняется сотни раз в секунду а HF случается раз в часы. т.е. дело видимо не в не в выравнивании, а в стечении неких обстоятельств. Проблему решил, правда, не "в лоб" а обходным маневром - отказался от использования семафора, и вот уже более полусуток проблема не проявляет себя. Хотя желание разобраться в сути проблемы до конца есть.

У меня указатель был расположен после U8. В то время как вся структура была размещена с выравниванием 4, поле указателя имело адрес 4*n+1. Инструкция LDR R0, [Rx,#5] вешала систему. Фактически структура была что-то типа:
void *
U8
void *
..
Я сделал
void *
void *
U8
..
после чего все заработало.

P.S. KEIL 5.x

Полагаю, вы чего-то недоговариваете. Если структура была обявлена без квалификатора packed, то компиляор был обязан выровнять указатель на его размер, т.е. на 4 байта, пропустив перед ним необходимое количество байтов. Если структура объявлена с packed, то компилятор пропускать байты не будет, но если процессор не умеет невыровненный доступ (как в случае с Cortex-M0) - компилятор обязан каждое многобайтовое поле считать побайтно и собрать целиком уже в регистрах. То есть он не имел права использовать в этом месте LDR R0, [Rx,#5]. Значит это либо ошибка компилятора (что маловероятно), либо вы использовали явное приведение типа, приведя (void *) к чему-то другому, но забыв packed в приводимом типе.

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

Скорее всего именно так и было (приведение указателя на невыровненные данные к указателю на непакованный тип и разыменование его)

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

я вот только такой пример знаю



в некоторых процах такой маневр приводил к замене не 2, 3, 4, 5 байтов, а все равно к замене 0, 1, 2, 3. Допускаю что такой же ход в кортексе М0 должен взывать падение, я прав?

Не правы.
Здесь совсем о другом разговор. Почитайте топик внимательнее. Здесь разговор о доступе к пакованным данным.

Я попытался откатить код. Слетает. Конечно, не в момент заполнения структуры как таковой: в некую процедуру передается указатель на поле структуры типа (void *), а внутри есть инструкция:
LDR R0, [R0, #0], при этом R0 = 0x20000035, т.к. R0 это и есть входной параметр процедуры и указывает на поле типа (void *), которая размещена после поля U8, почему и такой нечетный адрес. Эта инструкция загрузки с нечетного адреса и вызывает исключение в -M0, в то время как -M3 все кушает без проблем.

Так вот это оно и есть. Против лома компилятор бессилен. Попробуйте передавать указатель типа (void * __packed), если компилятор такое позволяет.

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

Передавать содержимое поля - легитимно. Передавать указатель на поле (указатель на __packed void *) - тоже легально. Вы же передавали другой указатель - указатель на простой void *, потеряв информацию о __packed, поэтому компилятор сделал все правильно, но совсем не то, что вы хотели.

Очень интересная тема !
Подскажите, нет ли в интернете какой-нибудь статьи, где разжёваны все отладочные возможности, которые есть после попадания в Hardfault ?

И ещё вопрос .
Вот тут, что именно произойдёт неправильно?

Я верно понимаю, что не получится прочитать из памяти 32х битную переменную, не выровненную в памяти на 32 бита ?
То есть, ядре М0 вот в этом случае значение b будет всё время некорректным ?
__packed {
U8 a;
U32 b;
},

Почему же. Можно, только компилятор должен превратить обращение к невыровненным данным к нескольким обращениям к выровненным.
CM-3 могло делать это налету - HF не случался, но возникали тормоза.

А почему компилятор не сможет это сделать, если невыровненное поле это указатель void *p; , как в примере выше ?

void *p он обработает без ошибок и HF. Но если p будет указывать на невыровненные данные и будет обращение к этим данным, то в этот момент возникнет HF.
Как заставить обработать эту ситуацию? Не знаю, я забочусь, чтоб p всегда указывал на выровненные данные.

ну типа



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

Вы же согласитесь, что выстрел в ногу произошел во второй строчке кода?

это же условно...

может же быть входной байтовый буфер через который идет структура, который при декодировании вот так сделает. Ну или прям стандарт, протокол вида:
преамбула - байт, код команды - байт, данные - 32 бита, как раз приводит к таким строчкам...

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



Не стреляет))
Даже осторожничает с dw1

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

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

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

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

А вот у меня не получилось завалить. Если p присваивать адрес указателя на байтовый буфер, то все операции далее идут как с невыровненными данными.

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

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

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

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

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

да я вроде без претензий. Это для меня не столько "ё мое ну нафига так сделали?", сколько объяснение почему бездумное копирование и использование в нормальной работе халявных примеров ведет к неприятным последствиям.

в качестве легбеза:
получается лучше все указатели что void* передавать как указатели на пакованный тип? А лучше вообще все так передавать?
Потому что сейчас выравнивание 32 бита, а завтра будет 64 и проблема старых библиотек и реюз кода вылезет заново?

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

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


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

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

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


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

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

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