Jump to content

    
Sign in to follow this  
VslavX

Odd address trap и LPC23xx

Recommended Posts

У меня в тестовой прошивке есть такой небольшой чудный кусочек кода:

{
    ungigned long *p;
    dprintf("\r\nNon aligned DWORD read.. ");
    dflush();
    p = (unsigned long*)(0x209 + LPC_ISRAM);
    dprintf("%08X", *p);
}

 

Назначение этого кусочка - протестировать работу соответствующего обработчика исключения. Код прекрасно отработал на S3C44BOX, S3C2410, IXP42x, SAM7xx, PXA2xx/3xx и много лет все было чудесно. И вот, "понимаете, в машине в которой мы ехали, случайно, совершенно случайно, оказался цемент" ©. Я "совершенно случайно" запустил этот код на LPC2388, и... не увидел свой любимый "ODD ADDRESS TRAP".

Смотрим документацию, "усер мануал" на LPC23xx вообще не содержит слова "unaligned". В-общем, красота - при невыравненном адресе - на LPC23xx читается/пишется переставленный мусор, и все это МОЛЧА. Такая низость в самом деле имеет место, или я чего-то недопонимаю?

Share this post


Link to post
Share on other sites
Такая низость в самом деле имеет место, или я чего-то недопонимаю?

Имеет, еще на LPC21xx налетал. Впрочем, это не низость, а скорее вариант нормы :)

Share this post


Link to post
Share on other sites
Имеет, еще на LPC21xx налетал. Впрочем, это не низость, а скорее вариант нормы :)

Я бы сказал, что это - весьма и весьма "нетрадиционный" "вариант нормы". Норма - это список ARM-ом в моем первом посте. А так выглядит как очередная подляна от NXP, причем - совершенно необъяснимая :(. Само исключение есть, генерируется извне ядра контроллером шины, почему бы не проконтроллировать еще и адрес - непонятно :(.

P.S. Надо будет на их новые Кортексы глянуть - может там исключение добавили.

Share this post


Link to post
Share on other sites
P.S. Надо будет на их новые Кортексы глянуть - может там исключение добавили.

 

в кортексах вообще нет проблемы обращения к невыравненным адресам

Share this post


Link to post
Share on other sites
У меня в тестовой прошивке есть такой небольшой чудный кусочек кода:

{
    ungigned long *p;
    dprintf("\r\nNon aligned DWORD read.. ");
    dflush();
    p = (unsigned long*)(0x209 + LPC_ISRAM);
    dprintf("%08X", *p);
}

 

Назначение этого кусочка - протестировать работу соответствующего обработчика исключения. Код прекрасно отработал на S3C44BOX, S3C2410, IXP42x, SAM7xx, PXA2xx/3xx и много лет все было чудесно. И вот, "понимаете, в машине в которой мы ехали, случайно, совершенно случайно, оказался цемент" ©. Я "совершенно случайно" запустил этот код на LPC2388, и... не увидел свой любимый "ODD ADDRESS TRAP".

Смотрим документацию, "усер мануал" на LPC23xx вообще не содержит слова "unaligned". В-общем, красота - при невыравненном адресе - на LPC23xx читается/пишется переставленный мусор, и все это МОЛЧА. Такая низость в самом деле имеет место, или я чего-то недопонимаю?

Да есть такая фигня при чтении.

Посмотрите еще и запись.

Share this post


Link to post
Share on other sites
в кортексах вообще нет проблемы обращения к невыравненным адресам

Угу, спасибо - заинтересовался и посмотрел, наконец, описание M3 - ничего, вкусненько. Будем ждать LPC17xx.

Share this post


Link to post
Share on other sites
В-общем, красота - при невыравненном адресе - на LPC23xx читается/пишется переставленный мусор, и все это МОЛЧА. Такая низость в самом деле имеет место, или я чего-то недопонимаю?

 

У меня есть файл arm7tdmi_instruction_set_reference.pdf, там написано следующее:

 

If the memory address is not word-aligned, the value read is rotated right by 8 times
the value of bits [1:0] of the memory address. If R15 is specified as the destination, the
value is loaded from memory and written to the PC, effecting a branch.

Share this post


Link to post
Share on other sites

If the memory address is not word-aligned, the value read is rotated right by 8 times
the value of bits [1:0] of the memory address. If R15 is specified as the destination, the
value is loaded from memory and written to the PC, effecting a branch.

Именно это я подразумевал под словом "переставленный". Для ARM7TDMI, который работает только в LE - будет такой вариант как Вы отцитировали. Для старших ARM-ов работающих в BE/LE вполне могут быть и отличия.

В любом случае - в результате невыравненного доступа получаем отнюдь не тот результат какой ожидали, а поскольку исключения нет - то "дорогая не узнает, какой у парня был конец" ©. Очень весело отлавливать такие проблемы при портировании 200К строк С-шного кода с 8-битника, например. NXP - "низачот", первый раз такой облом вижу. В 70-ых на PDP такое счастье как OAT было, а вот в 21-ом веке - не судьба.

Share this post


Link to post
Share on other sites
В любом случае - в результате невыравненного доступа получаем отнюдь не тот результат какой ожидали

 

А Вы ожидайте "правильный" (в соответсвии с абзацем, который я процитировал). Вдруг Вам так и надо было. "Такие дела" ©.

Edited by meister

Share this post


Link to post
Share on other sites
Очень весело отлавливать такие проблемы при портировании 200К строк С-шного кода с 8-битника, например.

Вообще-то "это отлаживать" - Вам "низачет", ибо нужно не с последствиями бороться а банально этои 200К строк (кстати для 8bit это число строк кода СИЛЬНО СИЛЬНО надуманное - "урежте осетра" как минимум на порядок, тогда еще где-то в 64-128K бинарника поверю ) хоть мельком, но просмотреть. И вообще с этим хорошие компиляторы хорошо справляются - warning-ов хватает, если, конечно перворначальный код не совсем через заденпроходное отверстие писан, но незачем такое и портировать.

NXP - "низачот", первый раз такой облом вижу. В 70-ых на PDP такое счастье как OAT было, а вот в 21-ом веке - не судьба.

Тут странное дело - когда давно поверял работу своего обработчика exception на чем-то вроде LPC2114 - точно работало, а потом на свежих чипах как-то исчезло, хотя недавно переписывал слегка и некоторым удивлением обнаружил, что на одном из китов с LPC2148 тоже отработал!

Share this post


Link to post
Share on other sites
(кстати для 8bit это число строк кода СИЛЬНО СИЛЬНО надуманное - "урежте осетра" как минимум на порядок, тогда еще где-то в 64-128K бинарника поверю )

Я прочитал как 200KB :)

200K строк действительно многовато.

 

 

И вообще с этим хорошие компиляторы хорошо справляются - warning-ов хватает, если, конечно перворначальный код не совсем через заденпроходное отверстие писан, то незачем такое и портировать.

Компиляторы не помогут когда адрес вычисляется диамически. :(

Например, сравнение IPшника приятого пакета с сетевой маской.

Share this post


Link to post
Share on other sites
Компиляторы не помогут когда адрес вычисляется диамически. :(

Например, сравнение IPшника приятого пакета с сетевой маской.

Отнюдь. В реальности буфера под фреймы выделяются выровненые а нормальная разборка ведется по наложенной структуре. При работе с невыровнеными элемсентами структуры полусите предупреждение. Есть масса более ветвистых протоколов, то там в основном и разборка побайтовая. Если кто-то нагородил нечто непотребное в стиле "я пишу на любом языке, как в машинных кодах", то, простите, портировать такое просто не надо - проблемы будут по любому.

Share this post


Link to post
Share on other sites
Вообще-то "это отлаживать" - Вам "низачет", ибо нужно не с последствиями бороться а банально этои 200К строк (кстати для 8bit это число надуманное)

Увы, не надуманное. "У меня линейка есть" - поэтому я абсолютно спокоен. :)

Самый старый проект был начат в 1992-ом, пережил asm x86, BCC3.1, Watcom, IAR AVR 1.30, IAR MSP, Softune LX16, GCC ARM, GCC PPC, сотни две вариаций и моделей, десяток языков (рус, укр, англ, нем, ...), сотни флагов условной компиляции. Так что 200К - это весьма и весьма скромно, могу Вас заверить. Много лет это "утаптывали ногами" в 128К меги - ей просто не было даже близкой конкуренции по цене, и там _очень_ много финтов направленных на "лишь бы влезло" и "хто украл 10 байт RAMы" - хроника одного байта - во всей красе. На проектах на ARM-ах - еще веселее - 200K - " это только лицо" ©, т.е. приложение. Сейчас моя "зона ответственности" - системный софт - HAL + TN + TCP + FAT + USB-host за 100К грозит играючи перейти. Впрочем, сложность - понятие относительное, посмотрим на исходники Линукса - там никакой "линейки" хватит.

 

хоть мельком, но просмотреть. И вообще с этим хорошие компиляторы хорошо справляются - warning-ов хватает, если, конечно перворначальный код не совсем через заденпроходное отверстие писан, но незачем такое и портировать.

Да это все понятно, компилятором ловится 95% проблем, потом на других ARM-платформах отловили еще 3-4%. А вот вчера меня программеры ткнули носом в листинг - "ldrh R0, [R4, #0x209]" и спросили - "почему бнопня лезет?". И пришлось мне, "случайно, совершенно случайно", стряхнуть пыль с теста обработчика исключения. Профтыкал-с, признаю. И вот этот оставшийся 1% - самое трудное. В сумме несколько десятков человек тестировало пару месяцев изделие, а вот на баг только вчера попали :(.

 

Тут странное дело - когда давно поверял работу своего обработчика exception на чем-то вроде LPC2114 - точно работало, а потом на свежих чипах как-то исчезло, хотя недавно переписывал слегка и некоторым удивлением обнаружил, что на одном из китов с LPC2148 тоже отработал!

Да, интересно. Само исключение есть, и работает - я ж обработчик таки при написании проверял. (как оказалось по черновым тестам - записью невыравненного слова во флеш - по адресу 1) . Но, судя по доке, возникает при обращении к несуществующей памяти и при записи во флэшку. Есть плата на свежем 2148revB и есть китовая от MT на 2148rev- - попробую на них.

 

P.S. Таки купили Вы меня на "надуманное", ну и ладно, сделаю вид что провокации не было :cheers:

 

Компиляторы не помогут когда адрес вычисляется диамически. :(

Например, сравнение IPшника приятого пакета с сетевой маской.

IP-шник - неудачный пример. И вообще протоколы для "внешних сношений". Если учитывать endianess, то разбор такой структуры все равно макросами надо делать, и в них aligment учесть. У меня, например, в TCP в итоге получилось 4 варианта макроса считывания поля IP - BE/LE + aligned/unaligned.

А вот со своими внутренними структурами - там да, некоторый unaligned трабл у прикладников был. Вот еще беспокойство есть насчет оставшегося 1% :(. Предполагался сценарий - "odd address trap" -> "bug report" -> e-mail -> база ошибок. Увы, мечты были грубо разрушены злобным NXP :)

Share this post


Link to post
Share on other sites
Тут странное дело - когда давно поверял работу своего обработчика exception на чем-то вроде LPC2114 - точно работало

 

"Работало", это как, DABT? В том абзаце, что я привел, ничего про DABT написано не было, там написано, что работает, но "специфически".

Share this post


Link to post
Share on other sites
Самый старый проект был начат в 1992-ом, пережил asm x86, BCC3.1, Watcom, IAR AVR 1.30, IAR MSP, Softune LX16, GCC ARM, GCC PPC, сотни две вариаций и моделей.....

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

На проектах на ARM-ах - еще веселее - 200K - " это только лицо" ©, т.е. приложение.

Посторяю - 200K чего? Кода или сишных строк??? Вот прям сейчас сижу в начале обычного проекта: ARM 94 файла 40767 текстовых строк из них всего 21943 стороки с кодом. Бинарник 134504 байта. Процентов 15% пришло с 8bit. Еще 20% вообще сразу живут на всех платформах. Будет развиваится и раздуваться еще несколько лет. Естественно есть и уже перевалившие за 300K бинарника. Говорите, что у Вас "200К строк С-шного кода" причем, как ранее говорили, для чего-либо врезультате влезающего в AVR128 и затем портированых? Так вот не верю.

P.S. Таки купили Вы меня на "надуманное", ну и ладно, сделаю вид что провокации не было :cheers:

Никаких провокаций - просто удивился. Полагаю обосновано.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this