[Tannen 0]

Возникла простая задача - посчитать CRC по Flash памяти для LPC2148. Начал с 0 адреса - вектора резет , до 0x08 адреса - считывание побайтное идет нормально. с 0x08(SWI) адреса - 4 байта при любом считывании считываются не правильно - хотя в IAR + JTAG в окне памяти написаны правильные значения, которые отладчик и показывает в переменных. Но если ввсести промежуточную переменную ( глобальную или локальную ) то видно, что эти 4 байта считались не правильно. Куда копать ?

[aaarrr 69]

Куда копать ?

Копать мануал в сторону Memory Mapping Control.

[Tannen 0]

А смысл ? после bootloadera MEMMAP=01 - указывает на начало flash. Если правильно понимаю смысл ре-мапинга, это и есть истинное место положение векторов прерываний. если в HEX файле для них ( таблицы векторов прерываний) указано значение ячеек, то и такое же значение ДОЛЖНО быть и считано . если конечно bootloader не переправляет их ( высказываю в качестве ненаучного бреда ) .

[esaulenka 7]

Описание проблемы не понял, но...

 

Попробуйте MAM отключить. На вопрос "зачем" читайте errata.

 

На 2138 (ревизию не помню) была проблема с побайтным чтением, процессор попадал в data abort. Чтение dword'ами ситуацию исправило.

[GetSmart 0]

На 2138 (ревизию не помню) была проблема с побайтным чтением, процессор попадал в data abort.

Это ещё что за проблема? Где описание?

[zltigo 1]

На 2138 (ревизию не помню) была проблема с побайтным чтением...

Работал начиная с инженерных образцов - такого не было. Однако, при прошивке Flash с неправильным указанием частоты (в 4 раза ниже) процессора IAP был интересный эффект - получаем совершенно рабочую программу, но контрольная сумма считываемая побайтно сбоит. Причем сбои достаточно стабильные, в том смысле, что вариантов битой CRC буквально 2-3. Проявляется далеко не на всех экземплярах - подавляющее большинство работает. Нечто подобное было и при, очевидно, массовых холодных пайках на контроллере - прошивался штатным загрузчиком, но не стартовал, а уходил опять в загрузчик.

[esaulenka 7]

с проблемой сталкивался два раза.

 

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

 

Второй раз, на 2138, memcpy (buff, адрес вблизи memcpy, N) стабильно вылетала в аборт. Реализация memcpy тупая, просто побайтное копирование. Вылечил изменением memcpy.

Я даже писал об этом с год назад, но понял, в чём проблема, сильно позже.

 

Мнение NXP на этот счёт:

Under certain conditions when the MAM is fully enabled (Mode 2) code execution from internal Flash can fail. The conditions under which the problem can occur is dependent on the code itself along with its positioning within the Flash memory.

If the above problem is encountered then Mode 2 should not be used.

[GetSmart 0]

Странно. У меня всё стабильно работало в процессе отладки не менее 500 разных прошивок. В основоном на LPC2132, но и на других 2131,2134,2138,2194,2294 и прочих ни разу не было бага чтобы я не выявил мой это косяк или компилятора, но сомнений в проце ниразу не было.

 

Побайтное чтение из флэхи часто использовалось для вывода строк по UART и возможно в memcpy (хотя её я редко дизассемблил)

[zltigo 1]

Мнение NXP на этот счёт:

Угу, на одной из ревизий. Причем лично мне НИКОГДА не удавалось на обозначенной ревизии получить какой-либо эффект. Собственно эти старички у меня сейчас на большинстве стендового оборудования на полном MAM и работают. Для объектов в конфигурации есть возможность установить в зависимости от ревизии. Побайтовое чтение из Flash сплош и рядом и CRC, и строки, и инициализация железа....

но понял, в чём проблема, сильно позже.

Почему сильно позже? Errata появилась быстро. Или MAM не помогал?

[esaulenka 7]

проблема проявлялась, если код обращался к данным вблизи того места, где этот код лежит.

 

вот, у меня даже записано

0x000388F8  E12FFF1C  BX        R12
0x000388FC  00038901  DD        0x00038901
                 strlen:
0x00038900  2100      MOV       R1,#0x00
0x00038902  E000      B         0x00038906
0x00038904  3101      ADD       R1,#0x01
0x00038906  1C02      ADD       R2,R0,#0
0x00038908  3001      ADD       R0,#0x01
0x0003890A  7812      LDRB      R2,[R2,#0x00]
0x0003890C  2A00      CMP       R2,#0x00
0x0003890E  D1F9      BNE       0x00038904
0x00038910  1C08      ADD       R0,R1,#0
0x00038912  4770      BX        LR

0x00038914  E59FC000  LDR       R12,[PC]
0x00038918  E12FFF1C  BX        R12
0x0003891C  00038921  DD        0x00038921
                 memcpy:
0x00038920  B430      PUSH      {R4-R5}
0x00038922  1C03      ADD       R3,R0,#0
0x00038924  1C18      ADD       R0,R3,#0
0x00038926  E005      B         0x00038934
0x00038928  1C0C      ADD       R4,R1,#0
0x0003892A  7825      LDRB      R5,[R4,#0x00]
0x0003892C  1C04      ADD       R4,R0,#0
0x0003892E  7025      STRB      R5,[R4,#0x00]
0x00038930  3101      ADD       R1,#0x01
0x00038932  3001      ADD       R0,#0x01
0x00038934  1C14      ADD       R4,R2,#0
0x00038936  3A01      SUB       R2,#0x01
0x00038938  2C00      CMP       R4,#0x00
0x0003893A  D1F5      BNE       0x00038928
0x0003893C  1C18      ADD       R0,R3,#0
0x0003893E  BC30      POP       {R4-R5}
0x00038940  4770      BX        LR


вызов 
memcpy (0x40002390, 0x00038910, 0x10)


;    data abort:
R0 = 0x0000008A
R1 = 0x00038911
R2 = 0x0000000D
R3 = 0x40002390
R4 = 0x0000008A
R5 = 0x0000001C

R13 (SP) = 0x40002524
R14 (LR) = 0x00038936
SPSR =     0x00000030

 

 

С разнообразными const char array[] = {}, константными строками и т.д. проблем и у меня не возникало.

 

 

на одной из ревизий

2138 всех ревизий, 2138/01 одной (из двух) ревизий

 

Почему сильно позже? Errata появилась быстро.

Потому что наизусть не помню, а привычки "что-то работает не так? иди читай errata" до сих пор не завёл...

[GetSmart 0]

проблема проявлялась, если код обращался к данным вблизи того места, где этот код лежит.

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

 

вот, у меня даже записано

А что в этом коде удивительного? Там реально происходит попытка записи во флэш из-за чего и вылетает дата аборт. Причём тут МАМ?

 

Кстати, аборт вызвала команда STRB R5,[R4,#0x00], но и следующую команду в тумбе проц успел выполнить до того как "залетел" в аборт. Я в тумбе никогда не отлаживался и не писал и даже не знал про такую фичу. Видимо в тумбе команды исполняются парами внутри слова.

[esaulenka 7]

А что в этом коде удивительного? Там реально происходит попытка записи во флэш из-за чего и вылетает дата аборт. Причём тут МАМ?

Штука вся в том, что адрес в регистре подменяется самостоятельно.

 

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

Более того, копирование с адресов, отличающегося от "глючного" замечательно проходит.

Вот MAM я в том случае отключить не догадался...

[GetSmart 0]

Штука вся в том, что адрес в регистре подменяется самостоятельно.

Моё предворительное имхо - это из области бреда сумасшедшего :) Чтобы подменялось значение регистра, а точнее при чтении флэхи искажалась не сама команда, а только её поле операнда. Да и исказилось там сразу несколько регистров.

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

Изменено 16 апреля, 2010 пользователем GetSmart

[GetSmart 0]

Протестил на проце 2138 с "-" ревизией. Никаких багов не вылетает. Часов 15 и наверное миллион вызовов процедуры. Проект прилагаю. Полностью соответствует исходнику по командам и расположению во флэш. В аборт не залетает при копировании из флэша в раму. Если же сделать вызов memcpy((void *)0x0000008A, (void *)0x00038911, 0x0E) то залетает в аборт с наиболее похожим состоянием регистров. Однако содержимое R3 не соответствует, что говорит, что у esaulenka был вызов всё таки с копированием в раму, а в процессе работы процедуры он исказился на флэш. Следующая команда за STRB R5,[R4,#0x00] вс таки не выполняется, а сразу идёт вызов аборта.

 

Вот какие регистры у меня вылетают при вызове memcpy((void *)0x0000008A, (void *)0x00038911, 0x0E)

data abort:

R0 = 0x0000008A

R1 = 0x00038911

R2 = 0x0000000D

R3 = 0x0000008A

R4 = 0x0000008A

R5 = 0x0000001C

 

R13 = 0x400000C4

R14 = 0x00038936

SPSR = 0x000000FF

 

esaulenka, а точно вызов был memcpy (0x40002390, 0x00038910, 0x10) ? И что это за адрес такой внутри функции strlen? Кстати, все указатели на Thumb-функции являются нечётными, то есть указатель на strlen в реале будет 0x00038901. Может поэтому при выпадении в аборт R1 = 0x00038911, а не 0x00038910.

 

 

В исходнике от esaulenka FIQ и IRQ были разрешены. Так что у меня попрежнему одна версия произошедшего - регистр(ы) исказило прерывание и уже потом сработал аборт.

[esaulenka 7]

это из области бреда сумасшедшего

 

Вы знаете, я б с Вами согласился.

Только, блин, я видел это собственными глазами!

 

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

Постараюсь избавиться от текучки (мечты, эх...) и попробую ещё раз.

Проверяли, правда, всего на двух процессорах, ревизию уже тоже не скажу...

 

регистр(ы) исказило прерывание

Без прерываний, к сожалению, проект работать не хочет, а отдельный тестовый проект собрать руки не дошли.

Против этой теории (самая очевидная, да) говорит то, что а) падает в одном и том же месте и б) во всех остальных местах не падает.

 

 

Update: старая тема - вот тут: http://electronix.ru/forum/index.php?showtopic=65449

Там ещё капелька чудесатости, про которую я уже забыл.