Есть проблема с исполнением кода на сделанном на отечественном предприятии процессоре 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


Есть идеи?

ЕМНИП, Cortex-M4 позволяет получить довольно много информации о причинах Hard Fault. Скажем, сохранённые в стеке регистры процессора, специальные регистры с информацией о причинах исключения и т.п. Почему бы вам не проделать это всё? Может быть, тогда вопрос решился бы сам собой?

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

http://mvc-nn.ru/продукция/микропроцессоры...кроконтроллеры/

Первый процессор из перечня

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

Любезный, AlexeyT, вам не здесь надо вопросы задавать, а напрямую в славный город НН.
Они должны с вас пылинки сдувать ( вот сказанул, самому смешно), ведь представляете вы, подозреваю, не частную лавочку.
"Микросхемка"-то в специсполнении, стоит как самолёт.


Эти "игрушки" не для общего рынка, для него ST, Atmel, ну даже TI…

Память Вас не подводит, позволяет. Но от анализа регистров легче не становится:

XPSR 0x21000003
CFSR 0x00000100
HFSR 0x40000000
AFSR 0x00000000
MMAR 0xE000EDF8
BFAR 0xE000EDF8

Т.е. выставлены биты ошибок IBUSERR, FORCED. Что IBUSERR - логично, при исполнении проекта из внешней памяти все работает. Что FORCED - непонятно, контроллер прерываний не инициализирован в пользовательской программе.
При этом падение в HardFault происходит при только исполнении программы из внутренней ОЗУ в реальном времени, при пошаговом исполнении той же самой программы из той же самой области памяти через отладчик - все работает.
Собственно и вопрос - в каком направлении есть смысл копать дальше?


Описание на микросхему существует в виде рабочих материалов, цивильное появится примерно к концу ОКРа. На какие именно подробности стоит обратить внимание и выложить их здесь?

Любезный Obam, что заставляет Вас думать, что в славном городе НН не пытались решить проблему? Микросхема ОКРовская (если Вам это о чем-то говорит), требовать техподдержки рано.

Хотелось бы таки предложений по решению

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

Разговоры про отладчик наводят на грустные мысли про прерывания, которые как-то включились, но вектора не прописаны. В пошаговом режиме они запрещены.

скорее на время выполнения иснтрукций, в отладчике оно все дольше.

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

Клок сбрасывали до килогерц - все также.

Мысль об увеличенном времени перехода через границу посещала, но как её измерить - есть идеи?

Располагаем логическим анализатором, подключенным к шине

Интересовали подробности о производителе-разработчике. Вся инфа будет закрыта (только по официальному запросу - гласит сайт). Грустно.

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

Из моего поста совершенно не следует "что в славном городе НН…", а следует только то, что они должны (если солидная фирма) ухватиться за вас и помогать всем чем можно (и иногда чем нельзя). Форумное сообщество в данном случае, ну только, для психологической помощи.
Что такое "Микросхема ОКРовская", не сомневайтесь, знаю.

Кстати, ваша м/с код исполняет из ОЗУ (вы сами об этом писали), но cortex-m имеет регулярное адресное пространство (ни о каких страницах ни 32, ни сколько угодно речи быть не должно, или что, при 32-разрядном PC - ОЗУ с сегментной (по 32кБ) организацией?), частота ядра тоже не бог весть какая (тем более для работы с ОЗУ, тем более "…Клок сбрасывали до килогерц…"), так что выход один - "пинать" производителя и менять на другой экземпляр.

У нас 2 экземпляра, результаты одинаковые. Разработчики микросхемы гоняли на модели - у них все ок. Если есть проблема в реализации кристалла, то наша задача - помочь её им определить.

Высказанные выше конструктивные идеи: 1) прерывания и 2) увеличенная задержка при обращении через границу блоков проверяем.

Нет ли еще идей?

Сообщение отредактировал AlexeyT - Jul 21 2015, 07:44