Полная версия этой страницы: Считывание с адреса 0x08 для LPC2148
Возникла простая задача - посчитать CRC по Flash памяти для LPC2148. Начал с 0 адреса - вектора резет , до 0x08 адреса - считывание побайтное идет нормально. с 0x08(SWI) адреса - 4 байта при любом считывании считываются не правильно - хотя в IAR + JTAG в окне памяти написаны правильные значения, которые отладчик и показывает в переменных. Но если ввсести промежуточную переменную ( глобальную или локальную ) то видно, что эти 4 байта считались не правильно. Куда копать ?
Цитата(Tannen @ Apr 15 2010, 22:06) 
Куда копать ?
Копать мануал в сторону Memory Mapping Control.
А смысл ? после bootloadera MEMMAP=01 - указывает на начало flash. Если правильно понимаю смысл ре-мапинга, это и есть истинное место положение векторов прерываний. если в HEX файле для них ( таблицы векторов прерываний) указано значение ячеек, то и такое же значение ДОЛЖНО быть и считано . если конечно bootloader не переправляет их ( высказываю в качестве ненаучного бреда ) .
Описание проблемы не понял, но...
Попробуйте MAM отключить. На вопрос "зачем" читайте errata.
На 2138 (ревизию не помню) была проблема с побайтным чтением, процессор попадал в data abort. Чтение dword'ами ситуацию исправило.
Попробуйте MAM отключить. На вопрос "зачем" читайте errata.
На 2138 (ревизию не помню) была проблема с побайтным чтением, процессор попадал в data abort. Чтение dword'ами ситуацию исправило.
Цитата(esaulenka @ Apr 16 2010, 16:42)
На 2138 (ревизию не помню) была проблема с побайтным чтением, процессор попадал в data abort.
Это ещё что за проблема? Где описание?
Цитата(esaulenka @ Apr 16 2010, 14:42)
На 2138 (ревизию не помню) была проблема с побайтным чтением...
Работал начиная с инженерных образцов - такого не было. Однако, при прошивке Flash с неправильным указанием частоты (в 4 раза ниже) процессора IAP был интересный эффект - получаем совершенно рабочую программу, но контрольная сумма считываемая побайтно сбоит. Причем сбои достаточно стабильные, в том смысле, что вариантов битой CRC буквально 2-3. Проявляется далеко не на всех экземплярах - подавляющее большинство работает. Нечто подобное было и при, очевидно, массовых холодных пайках на контроллере - прошивался штатным загрузчиком, но не стартовал, а уходил опять в загрузчик.
с проблемой сталкивался два раза.
Первый раз, на 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.
Первый раз, на 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.
Странно. У меня всё стабильно работало в процессе отладки не менее 500 разных прошивок. В основоном на LPC2132, но и на других 2131,2134,2138,2194,2294 и прочих ни разу не было бага чтобы я не выявил мой это косяк или компилятора, но сомнений в проце ниразу не было.
Побайтное чтение из флэхи часто использовалось для вывода строк по UART и возможно в memcpy (хотя её я редко дизассемблил)
Побайтное чтение из флэхи часто использовалось для вывода строк по UART и возможно в memcpy (хотя её я редко дизассемблил)
Цитата(esaulenka @ Apr 16 2010, 15:12)
Мнение NXP на этот счёт:
Угу, на одной из ревизий. Причем лично мне НИКОГДА не удавалось на обозначенной ревизии получить какой-либо эффект. Собственно эти старички у меня сейчас на большинстве стендового оборудования на полном MAM и работают. Для объектов в конфигурации есть возможность установить в зависимости от ревизии. Побайтовое чтение из Flash сплош и рядом и CRC, и строки, и инициализация железа....
Цитата(esaulenka @ Apr 16 2010, 15:12)
но понял, в чём проблема, сильно позже.
Почему сильно позже? Errata появилась быстро. Или MAM не помогал?
проблема проявлялась, если код обращался к данным вблизи того места, где этот код лежит.
вот, у меня даже записано
С разнообразными const char array[] = {}, константными строками и т.д. проблем и у меня не возникало.
2138 всех ревизий, 2138/01 одной (из двух) ревизий
Потому что наизусть не помню, а привычки "что-то работает не так? иди читай errata" до сих пор не завёл...
вот, у меня даже записано
Код
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
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" до сих пор не завёл...
Цитата(esaulenka @ Apr 16 2010, 18:00)
проблема проявлялась, если код обращался к данным вблизи того места, где этот код лежит.
Вот это не исключаю, т.к. никогда такое не юзал. Но в принципе могу протестить если время будет. 2138 и 2132 нулевой ревизии под боком валяется.
Цитата(esaulenka @ Apr 16 2010, 18:00)
вот, у меня даже записано
А что в этом коде удивительного? Там реально происходит попытка записи во флэш из-за чего и вылетает дата аборт. Причём тут МАМ?
Кстати, аборт вызвала команда STRB R5,[R4,#0x00], но и следующую команду в тумбе проц успел выполнить до того как "залетел" в аборт. Я в тумбе никогда не отлаживался и не писал и даже не знал про такую фичу. Видимо в тумбе команды исполняются парами внутри слова.
Цитата
А что в этом коде удивительного? Там реально происходит попытка записи во флэш из-за чего и вылетает дата аборт. Причём тут МАМ?
Штука вся в том, что адрес в регистре подменяется самостоятельно.
Копирование идёт не по какому-то хитрому указателю, а в локальный буфер, который компилятор в стек кладет (я и строку вызова этой функции привёл).
Более того, копирование с адресов, отличающегося от "глючного" замечательно проходит.
Вот MAM я в том случае отключить не догадался...
Цитата(esaulenka @ Apr 16 2010, 19:49)
Штука вся в том, что адрес в регистре подменяется самостоятельно.
Моё предворительное имхо - это из области бреда сумасшедшего
Чтобы подменялось значение регистра, а точнее при чтении флэхи искажалась не сама команда, а только её поле операнда. Да и исказилось там сразу несколько регистров.Гораздо более вероятно и очевидно, что регистр искажает прерывание/исключение (но не финальный аборт). Это если отбросить вариант, что вызов изначально содержит недопустимый параметр.
Протестил на проце 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 были разрешены. Так что у меня попрежнему одна версия произошедшего - регистр(ы) исказило прерывание и уже потом сработал аборт.
Вот какие регистры у меня вылетают при вызове 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 были разрешены. Так что у меня попрежнему одна версия произошедшего - регистр(ы) исказило прерывание и уже потом сработал аборт.
Цитата
это из области бреда сумасшедшего
Вы знаете, я б с Вами согласился.
Только, блин, я видел это собственными глазами!
Зря, наверное, отписался - доказать-то толком не могу, исследований тоже хороших не проводил.
Постараюсь избавиться от текучки (мечты, эх...) и попробую ещё раз.
Проверяли, правда, всего на двух процессорах, ревизию уже тоже не скажу...
Цитата
регистр(ы) исказило прерывание
Без прерываний, к сожалению, проект работать не хочет, а отдельный тестовый проект собрать руки не дошли.
Против этой теории (самая очевидная, да) говорит то, что а) падает в одном и том же месте и б) во всех остальных местах не падает.
Update: старая тема - вот тут: http://electronix.ru/forum/index.php?showtopic=65449
Там ещё капелька чудесатости, про которую я уже забыл.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.