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

[nanorobot]

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

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

 

[ViKo]

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

[nanorobot]

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

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

[jcxz]

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

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

Явно в какой-то процедуре затирается стек (LR странный)

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

Всё чётко видно где произошло, при каких регистрах и стеке.

[nanorobot]

...

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

Сообщение отредактировал IgorKossak - Aug 9 2014, 18:30

Причина редактирования: избыточное цитирование

[jcxz]

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

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

[nanorobot]

Пристойно? И 24й бит PSR тоже?
То что Вы приводите не имеет никакого отношения к регистрам либо "их копиям в верхушке стека".

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

[jcxz]

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