Проблемы с исполнением кода Опции

[AlexeyT]

Есть проблема с исполнением кода на сделанном на отечественном предприятии процессоре ARM Corteх-M4F.

Кристалл флэш-памяти не имеет, прошивка загружается извне во встроенное ОЗУ объемом 128 кБ, которое используется как память программ. Есть ОЗУ объемом 68 кБ, которое используется как память данных.

Запустили успешно, но на объемах прошивки, превышающих 32 кБ, процессор зависал.
Путем последовательных упрощений нашли причину: процессор виснет при вызове функций, расположенных в разных 32 кБ сегментах (см.рисунок).

Т.е. если программа вызывает функцию f2(), расположенную в том же 32-кБ участке, что и остальная программа - все ОК. Причем все нормально работает независимо от того, в каком именно 32-кБ сегменте размещена программа. Стоит вызвать функцию (типа printf), размещенную в соседнем 32-кБ сегменте памяти - сваливаемся в HardFault.

Память тестировали - записывали данные, считывали - все ОК, память работоспособна, но при переходе границы 32-кБ блоков происходит HardFault:
PC = 0x0800016A, LR = 0xFFFFFFE9, XPSR = 0x21000003

Дебаггер показал, что падаем в районе вызова команды LDR
0800_01DC: 7047 BX LR
0800_BE46: 4E21 MOV R1, #78 //где-то здесь падаем
0800_BE48: 6D48 LDR R0, [PC, #+0x1B4] //где-то здесь падаем
0800_BE4A: F4F7B6F9 BL #-0xBC94
0800_01BA: 0246 MOV R2, R0


Есть идеи?

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

 

[AlexeyT]

Приведите карту памяти МК.

Секция CODE (доступ по I, D шинам)
0x0000_0000-0x0000_0FFF Область для загрузчика, отражается на внешнюю шину
0x0800_0000-0x0805_FFFF Область внутреннего ОЗУ с пользовательской программой
0x1000_0000-0x1FFF_FFFF Область доступа к внешней системной шине
Секция DATA
0x2000_0000-0x2000_03FF Область ОЗУ на внешней системной шине
0x2000_0400-0x2001_FFFF Область внутреннего ОЗУ данных, доступ по D шине
0x3000_0000-0x3FFF_FFFF Область доступа к внешней системной шине
Peripheral
0x4000_0000-0x4002_F00C Периферия
EXT_BUS
0х6000_0000-0x9FFF_FFFF Внешняя системная шина
System
0xE000_0000-0xEFFF_FFFF Системная область ядра

Чтобы отмести подозрения на загрузчик - он не используется, идет напрямую загрузка bin-файла в ОЗУ через SWD. Потом выставляется MSP, VTOR, PC - и запуск на исполнение.

Если первое, то какова конфигурация шин и регионов памяти в данном МК? Во многих МК ОЗУ разбита на банки с отдельными шинами доступа к ним (часто они по соседним адресам).

ОЗУ инструкций не разбита на банки, с точки зрения системы - единый блок

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

Тактирование общее на весь блок памяти, всегда включено

Просто доступ по чтению/записи данных в эти сегменты есть?

Просто доступ на чтение/запись есть на всю ОЗУ инструкций, гоняли тестами.

DMA и прочие bus-master-ы активны? Может конфликт CPU с другим bus-master?

DMA есть, но неактивен, больше ведущих на шине нет.

Также - как работает отладчик с этими сегментами: ставит бряки программные или аппаратные?

Программные

В каком состоянии находится MPU? Инициализировали его?

Явно нет, стоят значения по умолчанию
MPU->TYPE = 0x0000_0800. Унифицированная карта памяти, 8 регионов
MPU->CTRL = 0x0000_0000. MPU запрещен

То что Вы привели в первом посте:
Цитата
0800_01DC: 7047 BX LR
0800_BE46: 4E21 MOV R1, #78 //где-то здесь падаем
0800_BE48: 6D48 LDR R0, [PC, #+0x1B4] //где-то здесь падаем
0800_BE4A: F4F7B6F9 BL #-0xBC94
0800_01BA: 0246 MOV R2, R0
не похоже на код, это какой-то мусор. По этим адресам вообще память есть? По каком адресам расположен сегмент кода?

Это не мусор, это фрагмент кода).
0x0800_01DC – возврат из вызываемой функции putc(вывод символа по UART) в main. Main занимает пространство 0х0800_B8CA-0x0800_BF6C
Затем идет подготовка к передаче нового байта. Вход в следующий putc – 0x8000_01BA, putc занимает адреса 0x0800_01BA – 0x0800_01DC
Память по этим адресам есть (см. карту памяти), программа занимает адреса 0х0800_0000-0x0800_CCC0

[jcxz]

Это не мусор, это фрагмент кода).
0x0800_01DC – возврат из вызываемой функции putc(вывод символа по UART) в main. Main занимает пространство 0х0800_B8CA-0x0800_BF6C
Затем идет подготовка к передаче нового байта. Вход в следующий putc – 0x8000_01BA, putc занимает адреса 0x0800_01BA – 0x0800_01DC
Память по этим адресам есть (см. карту памяти), программа занимает адреса 0х0800_0000-0x0800_CCC0

Вы как-то странно написали... сразу трудно въехать... У Вас идёт команда по адресу 080001DC - возврат из функции и за ней сразу идёт команда по другому адресу...
Это адрес, на который происходит возврат?
Далее идёт загрузка R1 и за ней - загрузка константы с адреса [0x8000BFFE]. 0x8000BFFE по Вашим словам находится сразу за функцией main() -
там похоже лежит таблица констант, используемых в main().
Так вот, я Вас спрашивал - по адресу 0x8000BFFE какие-то данные (согласно map-файлу) есть?
И кстати - адрес 0x8000BFFE (если я правильно посчитал) выровнен на границу 2, а доступ в команде LDR R0, [PC, #+0x1B4] осуществляется к двойному слову (32бит).
В ядре Кортекс можно включить запрет невыровненных доступов к памяти, тогда будет генериться исключение (не помню какое). У Вас это разрешено?
А если оно разрешено, но не разрешены всякие MMfault и UserFault, то будет происходить эскалация до HardFault насколько я помню.
Да и вообще странно, что компилятор генерит такой невыровненный код....
Попробуйте поставить бряк на точку входа в ISR HardFault и выполнить эту команду, а потом попробуйте подровнять адрес на 4 и сделать то же самое.

ЗЫ: Кстати - у Вас putc() похоже какая-то очень простая, раз выход из неё BX LR...

Секция CODE (доступ по I, D шинам)
0x0000_0000-0x0000_0FFF Область для загрузчика, отражается на внешнюю шину
0x0800_0000-0x0805_FFFF Область внутреннего ОЗУ с пользовательской программой
0x1000_0000-0x1FFF_FFFF Область доступа к внешней системной шине

Раз в МК есть разделение ОЗУ на ОЗУ для кода и данных, то может быть что первая часть не поддерживает невыровненный доступ.
Область для загрузчика, отражается на внешнюю шину - а сам загрузчик не встроенный в МК что-ль???

Чтобы отмести подозрения на загрузчик - он не используется, идет напрямую загрузка bin-файла в ОЗУ через SWD. Потом выставляется MSP, VTOR, PC - и запуск на исполнение.

Обычно это (стек и PC) выставляется первым вектором таблицы прерывания, с которого CPU их считывает при подаче reset-а эмулятором.

CFSR 0x00000100

Этим 8-мым битом CPU Вам говорит:
A bus fault on an instruction prefetch has occurred. The fault is signalled only if the
instruction is issued.
И у меня вызывает большие подозрения Ваша строка:
0800_BE4A: F4F7B6F9 BL #-0xBC94
Это вызов функции? Скорее всего именно она и вызывает fault. Точно узнать можно по содержимому стекинга.

Память тестировали - записывали данные, считывали - все ОК, память работоспособна, но при переходе границы 32-кБ блоков происходит HardFault:
PC = 0x0800016A, LR = 0xFFFFFFE9, XPSR = 0x21000003

Вы привели неправильные регистры. Это состояние регистров внутри ISR. Толку от него мало. Вам нужно привести регистры сохранённые при стекинге при входе в fault.
Прочитайте раздел описания ядра кортекс, посвящённый описанию стекинга и формата сохраняемых регистров.
Тогда узнаете значение PC перед срабатыванием fault.

Ещё - проверьте стек. Может он у вас элементарно переполняется.