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

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 оформлен как

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

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

VIC, наверное, неправильно инициализировали. Код приведите.

Стоп.

А VIC что, оказался совсем не у дел? Процессор будет падать на этот адрес по любому прерыванию.

Не уверен, что нужно всё подряд, вот части, непосредственно работающие с VIC1:





пробовал nirq=0 и =4, одинаково:

и прибиваю торчащее откуда-то прерывание от источника 3:

Тексты двух обработчиков:

В общем, не совсем понятно соотношение обработчиков по адресу 0x18, помещенных в вектор (VIC1VectAddr0..VIC1VectAddr15) и VIC1DefVectAddr.

Кто в кого помещен?

Код, если честно, мозг ломает напрочь. Но некоторые моменты могу прояснить:
- Читать и писать VectAddr нужно в одном месте, а не в двух.
- Оформлять процедуру в виде прерывания - тоже.

Т.е. если в irq_handler читается и пишется VectAddr, и оформлен он как irq (в чем я, кстати, не уверен - уж больно дикий микс asm-C), то handler1 должен быть простой процедурой.



Но по-хорошему и так делать не следует, ибо очень криво.

Только сейчас заметил :


Внимательно и вдумчиво почитайте мануал на VIC (есть на ARM'овском сайте) и архитектуру ARM.

см.внизу

Я знаю; но это была Ваша инициатива.


Да, если бы программа работала, так бы и было. Но она не работает, но не потому же, что
тут в двух местах читается VectAddr? Ведь до handler1 управление не доходит, так же как и до irq_handler.

Это я от отчаяния.

Читаю:
2.1.6 Vectored interrupts
A vectored interrupt is only generated if the following are true:
• you enable it in the interrupt enable register, VICIntEnable
• you set it to generate an IRQ interrupt in the interrupt select register, VICIntSelect
• you enable it in the relevant vector control register, VICVectCntl[0-15].

В соответствии с этим описанием никаких манипуляций с адресом 0x18 не требуется вообще.
Всего три пункта: правильная маска в VICIntEnable, правильная маска в VICIntSelect,
правильное значение VICVectCntl[0-15].


AFAIR биты VICIntSelect имеют следующие значения: 0:IRQ, 1:FIQ.
По умолчанию 0, т.е. IRQ.

("кто в кого помещен") Интересно, что здесь даже не сказано о VIC1VectAddr0..VIC1VectAddr15. То есть даже если я не помещу туда никакое ненулевое значение, прерывание всё равно произойдет, и управление передастся по адресу 0. Допустим. Но этого не происходит.

Понимаете, всё, что мне нужно - это понять, что еще нужно включить или выключить, чтобы
прерывание появилось. Оформление процедуры, сохранение регистров/контекста/пр. - это всё технические вопросы, я это выясню сам и потом. Пока мне нужно, чтобы управление попало на адрес, который я укажу - адрес ISR (вернее, хардверного обработчика).

При возникновении прерывания бит в VIC1RawIntr (да и в VIC1IRQStatus), соответствующий прерыванию от UART2 (номер 25) взводится. Да так и остается взведенным.

Вдумчиво читаю и комментирую еще одно положение:
2.2.1 Vectored interrupt flow sequence
The following procedure shows the sequence for the vectored interrupt flow:
1. An interrupt occurs.
- появляется прерывание. Да, появилось
2. The ARM processor branches to either the IRQ or FIQ interrupt vector.
- АРМ-процессор осуществляет переход либо на IRQ либо на FIQ-вектор. К сожалению, тут непонятно, о каком именно векторе идет речь. То ли о том, что определен как 0x18/0x1C, то ли о VICxVectAddr0..VICxVectAddr15.
3. If the interrupt is an IRQ, read the VICVectAddr Register and branch to the
interrupt service routine. You can do this using an LDR PC instruction. Reading the
VICVectorAddr Register updates the interrupt controllers hardware priority
register.

Если прерывание - IRQ (а что делать, если это не так?), прочитай регистр VICVectAddr и осуществи переход на ISR. Вы можете сделать это, используя инструкцию LDR PC. Считывание регистра VICVectorAddr обновляет аппаратный регистр приоритета контроллера прерываний.
о чем здесь идет речь? О процедуре, на которую управление приходит с адреса 0x18/0x1C.

4. Stack the workspace so that you can re-enable IRQ interrupts.
5. Enable the IRQ interrupts so that a higher priority can be serviced.
6. Execute the Interrupt Service Routine (ISR).

Выполнить ISR - коротко и ясно.

7. Clear the requesting interrupt in the peripheral, or write to the VICSoftIntClear
Register if the request was generated by a software interrupt.
8. Disable the interrupts and restore the workspace.
9. Write to the VICVectAddr Register. This clears the respective interrupt in the
internal interrupt priority hardware.
10. Return from the interrupt. This re-enables the interrupts.

Получается следующее. Поправьте меня, если я не прав.
* При возникновении IRQ-прерывания управление попадает по адресу 0x18, далее в процедуру обработки аппаратного прерывания, которая выясняет, было ли прерывание векторизированным или нет, выбирает соответствующий ISR, вызывает его, осуществляет манипуляции по повторному разрешению прерываний.
* Считывание и запись регистра VICVectAddr осуществляется соответственно до и после вызова ISR.
* ISR - обычная процедура

Прекрасно, я сейчас это всё сделаю. Только проблема-то останется - hardware handler не вызывается.

В этом же документе (DDI0181.pdf) описывается механизм быстрой обработки прерываний, когда VIC отмапливается на адрес 0xFFFFF000. Тогда его регистры становятся в пределах досягаемости от адреса 0x18, и можно разместить там команду LDR pc, [pc, #-0xff0]. При выполнении этой команды управление передастся на адрес, который хранится непосредственно в VIC, с учетом отмапливания это будет 0xFFFFF030, т.е. VICVectAddr. И в этом случае дополнительного считывания делать уже не нужно, уже всё прочитано и ушло на исполнение... нет?

У меня было несколько предположений. Рискну изложить их здесь, какими бы глупыми они ни были.
1. Прерывание не возникает, потому что процессор в режиме супервизора.
2. Прерывание возникает, но управление передается не на адрес 0x18.
3. Для того, чтобы изменения в VIC воспринялись, нужны дополнительные действия (аналогично outportb(0x20,0x20) в IBM PC).
4. Прерывание не возникает, потому что активно прерывание с более высоким приоритетом. Но я его не вижу.

Сообщение отредактировал toykhee_menky - Jun 30 2008, 20:04

Ну я бы под пунктом 0 добавил:
Преравание не возникает, потому что прерывания вообще не разрешены (а они разрешены на уровне процессора?)

Разрешены:

Надо расшифровывать значение cpsr?

Ну я бы, для начала, написал бы тестовую функцию обработчика прерывания типа:

void test_handler(void)
{
LED-ON();
while(1);
}

и убедился бы, что она вызывается.

А еще можо посмотреть в книге "ARM System Developer's Guide" A.Sloss на стр.363 есть пример обработчика на VIC

Все правильно.


Да, это самый нормальный способ работы с VIC'ом. В прерывании остается только запись VICVectAddr.


1, Не бывает.
2. Может быть, если в регистре 1 CP15 установлен бит V, тогда вектора будут расположены с адреса 0xffff0000. Но вряд ли это так.
3. Никаких действий не нужно.
4. Попробуйте сбросить VIC шестнадцатикратной записью VICVectAddr.

Можно посмотреть http://www.siwawi.arubi.uni-kl.de/avr_proj...ml#lpc_uart_irq. LPC тоже пользует VIC.

Мда. Проблема, однако. Неужели я один такой (или первый?!)

Всё-таки мне кажется, что тут redboot руку приложил. Я его сам не собирал, взял готовый:
G:\Tion\tools\utils\util>md5sum redboot_322D.bin
1450b4be1f8a86b85cd2bf2326d8d906 redboot_322D.bin

при старте:


Смотрел eCos и eCos-2.0, скачивал с ftp://ecos.sourceware.org/pub/ecos/releases, поскольку redboot является частью екоса.

Не вижу поддержки ep93xx в этих исходниках. Если бы была, то можно было бы найти информацию по прерываниям (например, здесь) и отмапливанию памяти.

Значит, какой-то добрый человек сделал поддержку ep93xx в редбуте минимум, а то и в екосе (официальные релизы по ссылке выше - 2003-й год.) Какое отношение автор этого порта имеет к изготовителям Тиона - мне неизвестно. На сайте ЗАО ЗЕО информации о порте екоса и редбута не вижу.
Остаётся надеяться, что кто нибудь, владеющий информацией, направит меня на путь истинный.

Тем не менее: значение регистра 1 CP15: 0xC000007B. Если считать бит V (high vectors) 13-м, то тут 0.
Посмотрел и отмапливание памяти: рег 2 CP15 содержит значение 0x00004000, дамп этого места в памяти:
дальше нули.
Интерпретирую это так: это описание 64-х секций длиной по 1Мб, виртуальная память объемом 64Мб, состоит из двух физических блоков по 32Мб, первый с физического адреса 0x00000000, и отображен сам на себя, второй с физического адреса 0x04000000, отображен на 0x02000000.
Флешь с физического адреса 0x60000000, вирт. адрес также 0x60000000.

Интересно, что в разных местах Интернета разная информация по редбуту:
одни говорят, что редбут не использует прерываний вообще, "It seems easy,because redboot will not use IRQ vector" (правда, там процессор ARM7TDMI), в другом месте сообщается. что "RedBoot uses an interrupt vector table which is located at address 0xA000A004." (IQ80310). Отсюда я делаю вывод, что использование или неиспользование прерываний в redboot - платформенно-зависимое. И надо бы мне найти исходники или документацию по порту редбута на ep93xx. Но... см выше.

Еще момент. redboot кроме загрузчика, еще и отладчик. Звучит фантастически, но может быть, там отладчик перехватывает обращения к адресам 0..0x1C?

Исходники redboot'а, если охота в них ковыряться, найдете на arm.cirrus.com.

Я одного понять не могу: зачем Вам redboot для запуска своей программы? Пишите ее сразу во флеш и запускайте.

Ну вот, осталось посмотреть, что же сидит в таблице прерываний с адреса 0х00000000

Спасибо!
Вот сейчас, наверное, уже и не так сильно нужен. Я надеялся, что будет некий RedBoot API, что- то вроде PC-шного BIOS. Не оказалось. Ну да ладно, это не фатально.
При использовании редбута можно давать диагностику в консоль практически "из коробки", а если делать флешовую программу, то придется изучать еще кучу вещей - среду разработки, синтаксис всевозможных описателей структуры памяти программы и т.п. В общем, как обычно, прежде, чем решить задачу, нужно решить две других, более сложных. Я хотел этого избежать.

Кроме того, мне показалось, что цикл сборка-загрузка-запуск-падение-отладка-исправление будет быстрее для ОЗУ-шной версии.



Сразу уж и 0x92FC (звиняйте, что не дизассемблировано):

А что за процедура вызывается по прерыванию? Как бы все похоже, что это обычная функция для ARM_MODE_USER или ARM_MODE_SVC или ARM_MODE_SYS, а уж никак не для режима прерывания? Там к тому моменты и стек другой и прочие прелести. Ну и VIC'ом тоже не попахивает.

По определению interrupt handler не может иметь параметров!

000092FC E59FD0F0 LDR sp, &000093F4
00009300 E92D003F STMFD sp!, {r0-r5}
00009304 E24E0004 SUB r0, lr, #4
00009308 E14F1000 MRS r1, SPSR
0000930C E3A02006 MOV r2, #6
00009310 E1A0300D MOV r3, sp
00009314 E10F4000 MRS r4, CPSR
00009318 E3C4401F BIC r4, r4, #31
0000931C E3844053 ORR r4, r4, #83
00009320 E129F004 MSR CPSR, r4
00009324 E1A0500D MOV r5, sp
00009328 E1A0400E MOV r4, lr
0000932C E92D0037 STMFD sp!, {r0-r2,r4,r5}
00009330 E1A0000D MOV r0, sp
00009334 E10F2000 MRS r2, CPSR
00009338 E38110C0 ORR r1, r1, #&C0
0000933C E3C11020 BIC r1, r1, #32
00009340 E129F001 MSR CPSR, r1
00009344 E9207F00 STMDB r0!, {r8-lr}
00009348 E129F002 MSR CPSR, r2
0000934C E1A0D000 MOV sp, r0
00009350 E893003F LDMIA r3, {r0-r5}
00009354 E92D00FF STMFD sp!, {r0-r7}
00009358 E59D1040 LDR r1, [sp, #64]
0000935C E201101F AND r1, r1, #31
00009360 E3510013 CMP r1, #19