Прерывания без ОС на EP9315, обработчик не вызывается Опции

[toykhee_menky]

Здравствуйте.

EP9315 на плате Tion-pro v1.
Программа на Си, компилируется WinARM 4.1.1, грузится в RAM при помощи redboot.

Пытаюсь работать с портом UART2, порт, судя по всему, работает - тестовая последовательность туда уходит.

FIFO разрешено, после посылки восьми символов оттуда появляется битик прерывания в VIC1RawIntr, т.е. прерывание до VIC вроде бы доходит.

По адресу 0x18 содержится команда, оставленная там redboot-ом, судя по всему:
00000018: 18 F0 9F E5 - перевожу как ldr r15,[r15,#0x18], т.е. должен взяться адрес процедуры реакции на прерывание с адреса 0x38 (0x18+0x18+0x08).

Подменяю указатель по адресу 0x38 на адрес своей функции. Но управление она не получает (контроль - светодиодами).

Прерывания разрешены, режим супервизора: cpsr=0x00000013
ОЗУ отмаплено само на себя, с адреса 0.

обработчик прерывания IRQ оформлен как

Код

void  __attribute__ ((interrupt ("IRQ"))) handler1();

но управления тоже не получает (источник прерывания 25 для VIC1 выбрал, прерывания разрешил, адрес ISR занес).

Чего-то я еще не сделал... Чего?

[sergeeff]

Все очень здорово, но надо же еще обучить процессор при возникновении прерывания с адреса 0х00000018 уходить на обработку конкретной функции обработки прерывания. А по сути, какая разница ядро как-то разбирается с прерываниями или дополнительный контроллер? По мне, так главное, чтобы бастро, понятно и надежно работало.

Я склоняюсь к тому, что redboot что-то в своих интересах инициализировал (или вовсе не инициализировал). На мой взгляд, если коллега действительно хочет именно с этим процессором работать, ему все равно под себя загузчик так и так придется написать. Тогда он будет владеть ситуацией, а не ситуация иметь его.

[toykhee_menky]

Все очень здорово, но надо же еще обучить процессор при возникновении прерывания с адреса 0х00000018 уходить на обработку конкретной функции обработки прерывания.

Вообще-то процессор умеет это делать, так как исполняет инструкцию, находящуюся по адресу 0x18. Я уже приводил содержимое этого слова:

Код

00000010: 18 F0 9F E5 00 00 00 00  18 F0 9F E5 18 F0 9F E5  |................|
                                   ^^^^^^^^^^^

Разумеется, информация в таком виде представлена для удобства(или, скорее, возможности) прочтения ее человеком. Процессор же интерпретирует ее как команду. Опять же, невозможно адекватно отобразить, что видит процессор по адресу 0x18, но если представить это слово как команду, получается

Код

   18:    e59ff018     ldr    pc, [pc, #18]; 0x38

Перевожу с ассемблера на русский: загрузить в счетчик программы (фактически, передать управление) на адрес, значение которого хранится на 0x18 (#18) больше, чем текущее значение счетчика. 0x38 здесь образуется из трех слагаемых: 0x18 - адрес инструкции, и начальное значение PC; второй 0x18 - смещение из кода команды; 8 - значение задано неявно особенностями архитектуры ARM (набежало за время прохождения конвейера).

На основании этого не вижу необходимости править команду по адресу 0x18, так как ничего лучше и придумать нельзя. Вместо этого я определяю адрес своего обработчика путем занесения его по адресу 0x38:

Код

unsigned int old_0x38;
unsigned int *ptr_0x38=(unsigned int *)0x38;

old_0x38= *ptr_0x38;
*ptr_0x38 = (unsigned int)irq_handler;

и он заносится, проверено.

Я склоняюсь к тому, что redboot что-то в своих интересах инициализировал (или вовсе не инициализировал). На мой взгляд, если коллега действительно хочет именно с этим процессором работать, ему все равно под себя загузчик так и так придется написать. Тогда он будет владеть ситуацией, а не ситуация иметь его.

Спасибо на добром слове. Ладно, убью еще неделю...