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