[Ruslan1 16]

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

Извините если глупость сморожу, но может просто технологический дефект во время изготовления? две штуки не статистика.

[AlexeyT 0]

Извините если глупость сморожу, но может просто технологический дефект во время изготовления? две штуки не статистика.

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

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

 

Кроме того, дефект кристалла не объясняет работоспособность программы при пошаговом исполнении в debug'е

Изменено 21 июля, 2015 пользователем AlexeyT

[jcxz 191]

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

1. Проблема именно при передаче управления в другой 32К сегмент?

2. Или при длинном переходе (исполнение инструкции, позволяющей больший диапазон расстояний перехода)?

Проверьте точно. Расположив источник вызова и целевой адрес близко к границе.

А если пересечение границы происходит без передачи управления, просто код находится на границе сегментов?

 

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

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

При пошаговой отладке, отладчик может незаметно автоматом их включать.

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

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

 

Если второе - какие именно инструкции перехода по адресу вызывают сбой? Пробовали разные (B/BL с разными длинами смещения, BX/BLX, MOV PC, ...)? есть ли разница по инструкциям?

Смотрели map-файл? Не создаётся-ли промежуточная функция подскока для данного вызова? Например IAR, при вызове функций, находящихся далеко (за пределами макс. дальности инструкции BL),

создаёт спец. функцию (обзывает её Venner) возле источника вызова, на которую и прыгает BL, а внутри находится одна инструкция LDR PC, [PC, #0] с целевым адресом.

Может компилятор генерит что-то подобное?

 

3. Так как в пошаговом режиме проблема не проявляется, может источник проблемы совсем не выполнение кода в текущем потоке?

Может возникает какое-то прерывание или исключение, а у Вас не проинициализирован NVIC и таблица прерываний? Проинициализируйте их, запрет прерываний может не помогать, так как есть

немаскируемое прерывание и исключения.

 

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

В каком состоянии находится 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

не похоже на код, это какой-то мусор. По этим адресам вообще память есть? По каком адресам расположен сегмент кода?

Может у Вас элементарный баг в программе и управление улетает по случайнвм адресам?

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

[-=Sergei=- 0]

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

 

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

 

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

 

 

Делайте фейковую константу по этому адресу где происходит сбой. Перекомпилируйте код, проверяйте далее. Теперь код точно не будет в этой ячейке.

 

И вот еще ссылка на анализ ситуации в HardFaulte.

http://community.arm.com/servlet/JiveServl...20for%20ARM.pdf

 

[AlexeyT 0]

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

Секция 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

 

[Golikov 0]

А там никаких конвейеров нигде не рушиться? если барьеров памяти и инструкций напихать что будет?

[AlexeyT 0]

А там никаких конвейеров нигде не рушиться? если барьеров памяти и инструкций напихать что будет?

 

 

Эммммм... Какие барьеры и куда напихать? Прошу пояснить

[scifi 1]

.

[jcxz 191]

Это не мусор, это фрагмент кода).

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.

 

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

[AlexeyT 0]

Покрутить тактирование, питание и посмотреть, будут ли изменения.

Про тактирование уже писали - сбрасывали до 100 кГц, результат такой же.

Сейчас проверили и с питанием - во всем диапазоне напряжений питания результат такой же.

 

А там никаких конвейеров нигде не рушится? Если барьеров памяти и инструкций напихать, что будет?

Будем пробовать, т.к. на этом проекте падаем при возврате в основную функцию из вызываемой.

 

Вы отладчиком в окне дизассемблера прошлись? Удалось найти инструкцию, на которой "всё падает"?

Да, и не раз. Повторюсь - при пошаговом исполнении из отладчика (s) программа работает до тех пор, пока пользователю не надоест запускать пошагово.

При запуске на исполнение из отладчика (g) - падаем вскоре после начала работы основной функции main.

В этом конкретном случае падаем в вызываемой функции putc, во втором вызове по ходу исполнения основной программы.

При первом вызове она отработала нормально.

 

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

С переполнением стека сталкивались в самом начале. С тех пор стека МНОГО:)

MSP = 0x20014870 при запуске программы, MSP = 0x20013B00 при падении. Используется 0xD70 из выделенных 0x4000

 

Вам нужно привести регистры сохранённые при стекинге при входе в fault.

R0 = 0x40002000, R1 = 0x00000052, R2 = 0x40002000, R3 = 0x000003e8

R12 = 0x2000084C, LR = 0x0800BE47, PC = 0x07FF4FBE, xPSR = 0x21000000

!!! PC улетает ниже области, где лежит программа( Но почему при первом вызове той же процедуры все работает???

 

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

По ресету управление передается на 0х0, где должен лежать загрузчик. Как в эмуляторе, так и на железе.

 

Сам загрузчик не встроенный в МК что-ль???

Таки да. Микросхема ОКРовская, есть нюансы. Есть вывод, в зависимости от которого обращения в область 0х0-0х1000 отправляются либо на внешнюю шину, либо на внутреннюю ПЗУ с кодом загрузчика.

[jcxz 191]

R0 = 0x40002000, R1 = 0x00000052, R2 = 0x40002000, R3 = 0x000003e8

R12 = 0x2000084C, LR = 0x0800BE47, PC = 0x07FF4FBE, xPSR = 0x21000000

!!! PC улетает ниже области, где лежит программа( Но почему при первом вызове той же процедуры все работает???

Точка возврата в LR правильная, а команда 0800_BE46: 4E21 MOV R1, #78 уже не была выполнена.

Хмммм.... да уж....

Я бы ещё попробовал позаменять регистр возврата LR на какой другой или вернуться через стек POP {PC} или попробовать выровнять целевую точку возврата на 4...

Но походу явно тут торчат ослиные уши "отечественного предприятия".

[AlexeyT 0]

или попробовать выровнять целевую точку возврата на 4...

Как это можно сделать средствами компилятора для проекта на С?

 

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

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

Но они маскируемые, и по умолчанию (в программе) не разрешены. Если разрешить их обработку из отладчика, после какого-нибудь из breakpoint'ов, то попадем в исключение DebugMonitor (№=12).

Это правильная логика работы, или здесь

торчат ослиные уши

?

[jcxz 191]

Как это можно сделать средствами компилятора для проекта на С?

на си - вряд-ли. Сделайте отдельную функцию на асме в пределах 32К исходной точки вызова.

А уже из неё - выровненный вызов за пределы 32К.

 

Но они маскируемые, и по умолчанию (в программе) не разрешены. Если разрешить их обработку из отладчика, после какого-нибудь из breakpoint'ов, то попадем в исключение DebugMonitor (№=12).

Это правильная логика работы, или здесь ?

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

Там, среди прочих, вроде есть разрешение DebugFault. Видно Вы случайно разрешили его. Его вроде только отладчик может

использовать/разрешать. Проверьте.

[AlexeyT 0]

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

Регистр такой есть. SCB->SHCSR (0xE000ED24). Но в нем устанавливаются только UsageFault, BusFault, MemFault. По умолчанию все обработчики были запрещены.

При их разрешении и намеренных ошибках процессор стал падать не в Hard, а в Usage или Bus.

 

Но вот основной косяк объяснению не поддается .

Имеем один и тот же простейший проект, с чуть разными картами памяти. 64 КБ разбиты на 2 части по 32 КБ.

В первом случае (Проект55) в верхнюю область памяти закинуты лишь 3 простых пользовательских функции.

Во втором (Проект56) - в верхнюю область линкер на свое усмотрение закинул и часть системных.

При этом Проект55 - работает, Проект56 - падает в UsageFault.

 

Активные регистры при падении:

LR=0xFFFFFFF9 (9 - использовался основной стек),

MSP=0x20005370 (использовано 0xF0 из 0x1000),

PC=0x08008080 (UsageFault_Handler),

xPSR=0x01000006 (UsageFault)

В стеке лежат:

LR=0x080080CB (следующая после команды _dadd),

PC=0x08008184 (SUBS - вроде ничего страшного. А вот команда перед ней, BMI.W 0x0800033C - условно-подозрительная)

xPSR=0x01000000.

 

______55.zip

______56.zip

[AlexeyT 0]

Тестовая программа стала работать при вот таких изменениях:

 

1) НЕ РАБОТАЛО (сваливалось в Hard Fault):

 

main()
{
.....
qq = simple_proc_int(ww,ee);//Hard Fault
...  
}

2) ЗАРАБОТАЛО:

main()
{
...
*(volatile unsigned int*)(0x30010000) = 0xFFFF5500;    // пишем во внешнюю шину неважно какие значения 
*(volatile unsigned int*)(0x30010000) = 0xAAAAFF01;    // пишем во внешнюю шину неважно какие значения
*(volatile unsigned int*)(0x30010000) = 0xFFFF5500;    // пишем во внешнюю шину неважно какие значения

qq = simple_proc_int(ww,ee);//нормально проходим, в Hard Fault не сваливаемся!
...  
}

Здесь

int simple_proc_int(int a, int B)
{
int c = 0;
c += a<<2;
c += b<<3;
return c;
}

- элементарная тестовая функция, записанная в другом 32-кБ сегменте памяти.

 

 

Память данных условно разбита на 2 сегмента по 32 кБ. "Условно" - потому что с точки зрения процессора, вся память представляет собой единый массив до 128 кБ.

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

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

Проект59 - в верхней части находятся тестовые и часть системных функций. Но обращения стоят только в начале и конце процедуры main. Проект НЕ исполняется, падает в UsageFault при выполнении процедуры a = simple_proc_dbl(b,c).

 

Вроде бы времена обращений - но при пошаговом исполнении из-под отладчика проект59 также не работает.

 

Кто-то может предположить причины такого бреда?

_______.rar

Изменено 28 июля, 2015 пользователем IgorKossak
[codebox] для длинного кода, [code] - для короткого!!!