Пишу обработчик всех непредвиденных ситуаций. Написал обработчик UNDEF. Вставил в С код строку типа asm(" DC32 0x10101010"); и столкнулся с непредвиденной проблемой. А какую именно инструкцию не поймёт проц? Перепробовал кучу вариантов и все проглатывал. Может, кто подскажет, от какой инструкции сработает прерывание UNDEF.

Строго говоря, это зависит от архитектуры. Для архитектур по V5 включительно, команды вида 0xFFxxxxxx вызовут Undef.

Процессор SHARP LH79525 архитектура 720T.

Это V4T.

В предыдущем посте я наврал немного - такая конструкция сработает только на V5, остальные её просто игнорируют.

Для ARM7 нужно что-то типа: 0xe6000010, где биты 31..28 это условие выполнения (0xE - всегда), биты 24..5 и 3..0 могут быть любыми (собственно инструкция).

Предложенная вами инструкция превратилась вот в это:

И прекрасно проглочена процессором.

Я перебрал кучу вариантов, и все варианты благополучно превращались в удобоваримый код.

У ARM7, как впрочем и у ARM9-10-XScale такой инструкции нет. Есть у ARM11.


Процессором или симулятором?

Прошу прощения, ваша инструкция вызвала UNDEF. Я забыл переключить компиляцию debug/relis. Всё работает отлично, как и должно работать. Большой

Сообщение отредактировал Beginning - Oct 11 2007, 18:42

Пытаюсь сделать data-abort. Выполняю инструкции типа:

x=0xFFFF7004;
asm(" str R0,[R0]");

В datasheet чётко написано:

0xFFFF7000 - 0xFFFF0FFF Invalid Access*

NOTE: *An access to this area will cause a memory abort.


В симуляторе, чётко вижу, что по этому адресу записывается значение. Однако в железе ничего не происходит. В чём, может быть засада?


Пытаюсь сделать perfetch-abort. Выполняю инструкции типа:

x=0x80001000;
asm(" stmdb sp!,{r0}");
asm(" ldmia sp!,{PC}");

Напрямую записать в PC компилятор не даёт.
В симуляторе, чётко вижу, что программа прыгает на адрес 0x80001000. Однако в железе видно тоже происходит прыжок (т.к.) виснет прога, но прерывания не происходит.

Чётко, ага. Только 0xFFFF0FFF < 0xFFFF7000 Судя по всему, должно быть 0xFFFF0000 - 0xFFFF0FFF.
Справедливости ради нужно сказать, что 0xFFFF7004 все же попадает под invalid access (0xFFFF6000 - 0xFFFFEFFF).


В даташите есть еще такие цифры:

Так что вполне возможно, что прыжок происходит аккуратно в середину Boot ROM.

Попробуйте добиться DAbort/PAbort на адресе 0x80002000.


Да, а зачем все это нужно, если не секрет?

Я в DATASHEET LH79524-5 вижу таблицу (стр. 58) в которой следующие цифры:

0x80000000 - 0x80000FFF Boot ROM
0x80001000 - 0xFFFBFFFF Invalid Access*

А на странице 56 я вижу:

0x80000000 - 0x80001FFF Boot ROM

Чему верить?


Зачем мне это всё нужно секрета не представляет. Просто архиважно сохранять данные находящиеся в ОЗУ, при всяких непредвиденных ситуациях. Вот для того, что бы мне проверить как, эти данные сохраняются, я и делаю краш-тесты.

Ну да, я на это обратил внимание. Ничему не верить, проверять вручную.

А получилось что-нибудь с 0x80002000?


Понятно. Только по-моему, краш-тест логичнее делать железом.
Искусственное создание DAbort/PAbort/Undef - это, скорее, штатная работа.

С адресом 0x80002000 тоже самое что и с 0x80001000

Не понял утверждения. Я прогу отлаживаю в реальном железе. Логически в нормально работающем железе и правильно написанной программе, не должны возникать исключительные ситуации описанные выше. Можно только предположить когда такое возникнет, например, рядом лежащий сотовик, наведёт помеху на шину или молния рядом долбанёт или ещё хр… знает что, что весьма трудно реализовать на практике с гарантированными обязательными задуманными последствиями. Поэтому эти ситуации приходится модулировать вручную.

Undef Вы уже получили, как я понимаю. Обработчики Data и Prefetch Abort строятся ровно по тому же принципу, вызывать их в железе, по-моему, большой необходимости нет.

Под "железными" краш-тестами я имел в виду работу на пониженном/повышенном питании, температуре и т.п. А молнию рядом вполне можно пустить при желании

В принципе я с вами согласен. Просто не люблю, когда непонятности остаются. Я явно вызываю ситуации, при которых должны сработать прерывания, а они не срабатывают. И эта недокументированная ситуация напрягает. А что ещё проектировщики забыли в схему вложить?

Да было дело... Как-то устраивал краш-тест, долбанул шокером в контроллер. Произошел так называемый эффект "защёлкивания микросхемы", это когда открываются паразитные динисторы, образованные между подложкой и вышестоящими элементами. При этом микросхема начинает потреблять амперы, и соответственно греться как утюг . Никакая собака при этом не помогает. Только полное обесточивание микросхемы.

Я, к сожалению, с Sharp дела не имел, но, судя по всему, его проектировали те же люди, что и продукцию Cirrus Logic. А у них сюрпризов хватало.