[Обработка событий]

Контроллер событий процессора Blackfin обрабатывает все асинхронные и синхронные события для процессора. Обработка процессором событий поддерживает как настройку приоритетов, так и их вложенность. Вложенность позволяет быть активными сразу нескольким обработчикам прерываний (событий). Приоритезация гарантирует, что обслуживание события с самым большим приоритетом имеет преимущество перед обслуживанием события с меньшим приоритетом. При этом прерывание с меньшим приоритетом может быть вытеснено прерыванием более высоким приоритетом (более приоритетное прерывание окажется вложенным в менее приоритетное).

Примечание: здесь приведен перевод части документации [1], посвященной обслуживанию прерываний. Незнакомые термины и сокращения см. в разделе "Словарик" статьи [2], а также во врезках статьи [2] и этой статьи.

Контроллер предоставляет поддержку 5 отдельных типов событий:

Emulation – переводит процессор в режим эмуляции (отладка), что позволяет посылать процессору специальные команды и управлять им через интерфейс JTAG, и получать из процессора отладочную информацию.

Reset – сбрасывает процессор.

Nonmaskable Interrupt (NMI) – программный сторожевой таймер или входной сигнал NMI генерирует для процессора это событие. Событие NMI часто используется как сигнал выключения системы, что позволяет правильно и последовательно выполнить процедуру отключения.

Exceptions (исключения) – события, синхронные с потоком выполнения программы. При этом исключение происходит перед тем, как будет разрешено выполнение инструкции, которая вызвала исключение. Исключения могут вызвать такие события, как нарушение выравнивания данных или неопределенная инструкция.

Interrupts (прерывания) – события, асинхронные по отношению к выполнению программы. Они вызываются сигналами их входных портов, таймеров и других периферийных устройств.

Каждое событие имеет связанный с ним регистр для хранения адреса возврата и связанной инструкции возврата из события. Когда сработало событие, состояние процессора сохраняется в стек супервизора.

Контроллер событий процессора состоит из 2 стадий: System Interrupt Controller (SIC) и Core Event Controller (CEC). SIC работает совместно с CEC для обеспечения приоритезации и управления всеми событиями системы. Концептуально архитектура устроена так, что прерывания от периферийного устройства попадают в SIC, и далее напрямую перенаправляются в прерывания общего назначения CEC.

System Interrupt Controller (SIC). Системный контроллер прерываний (System Interrupt Controller) предоставляет привязку и маршрутизацию событий от множества источников прерываний от периферийных устройств на приоритезированные входы прерываний общего назначения CEC ("общего назначения" отражает тот факт, что они могут обрабатывать прерывания от любого аппаратного периферийного устройства - в зависимости от того, как это настроит программист). Хотя процессор предоставляет привязку по умолчанию (которая сама настраивается после сброса), пользователь может поменять привязку (и тем самым приоритет обработки) сигналов прерываний от периферии путем записи подходящих значений в регистры назначения прерываний (Interrupt Assignment Registers, IAR).

Core Event Controller (CEC). Контроллер событий ядра (Core Event Controller) поддерживает 9 прерываний общего назначения (general-purpose interrupts, IVG15–7) в дополнение к выделенному (не настраиваемому) прерыванию и событиям исключения. Из прерываний общего назначения есть 2 прерывания с самым низким приоритетом (IVG15, IVG14), которые рекомендуется резервировать для обработчиков программных прерываний, оставляя входы 7 более приоритетных прерываний (IVG13-IVG7) для поддержки периферийных устройств.

// Очищает уровень IVG периферийного устройства 11 (это SPORT1 RX):

*pSIC_IAR1 &= PX_IVG_CLR(11);

void ClearPeripherialPriorityAndMap (void)
{
   for(int i =0;i<8;++i)
   {
      // Очистка уровней IVG периферийных устройств:
      *pSIC_IAR0 &= PX_IVG_CLR(i);
      *pSIC_IAR1 &= PX_IVG_CLR(i+8);
      *pSIC_IAR2 &= PX_IVG_CLR(i+16);
      *pSIC_IAR3 &= PX_IVG_CLR(i+24);
      *pSIC_IAR4 &= PX_IVG_CLR(i+32);
      *pSIC_IAR5 &= PX_IVG_CLR(i+40);
      *pSIC_IAR6 &= PX_IVG_CLR(i+48);
   }
}

Кроме программирования привязки, отдельные источники прерывания могут быть маскированы (запрещены) в SIC.

[Обработка прерываний системой]

На рис. 4-4 показано, как генерируется прерывание (Interrupt A) для периферийного устройства (подразумевается, что для него разрешено прерывание).

Рис. 4-4. Блок-диаграмма обработки прерывания.

Примечание: в скобках показаны имена MMR (регистров, отображенных на пространство памяти процессора).

Вот описание обработки прерывания (Interrupt A) по шагам:

1. В регистрах SIC_ISR запоминается запрос, и делается проверка - выставлено ли еще не обслуженное прерывание (т. е. обработчик прерывания пока еще не очистил прерывание).

2. Проверяются регистры SIC_IWR чтобы определить, что ядро нужно вывести из состояния ожидания (idle state) и/или разбудить его, выведя из режима сна, базируясь на этом запросе прерывания.

3. Регистры SIC_IMASK разрешают прерывания от периферийных устройств на уровне системы. Если Interrupt A разрешено, то обработка запроса переходит к шагу 4.

4. Регистры SIC_IARx определяют привязку прерываний периферии к набору прерываний общего назначения ядра (general-purpose core interrupts) IVG7 – IVG15. Привязка определяет приоритет обработки для Interrupt A (в зависимости от того к какому из IVG7 – IVG15 оно привязано).

5. Регистр ILAT контроллера CEC добавляет Interrupt A к логу прерываний, захваченных ядром, но пока еще не обработанных.

6. Регистр IMASK контроллера CEC разрешает события разных приоритетов ядра. Если событие IVGx, соответствующее Interrupt A, разрешено, то процесс переходит к шагу 7.

7. Из таблицы векторов прерываний (Event Vector Table, регистры EVTx) выбирается подходящий вектор для обработчика прерывания (interrupt service routine, ISR), в нашем примере это обработчик для Interrupt A.

8. Когда вектор события Interrupt A введен в конвейер ядра, устанавливается подходящий бит IPEND, который очищает соответствующий бит ILAT. Таким образом, IPEND отслеживает все ожидающие (отложенные) прерывания, а также те, которые в настоящий момент обслуживаются.

9. Когда выполнится ISR для Interrupt A, инструкция RTI очистит подходящий бит IPEND. Однако соответствующий бит SIC_ISR не очищается, пока ISR не очистит механизм, который сгенерировал Interrupt A, или пока ISR не очистит этот бит.

Нужно заметить, что события emulation, reset, NMI и exception, как и аппаратная ошибка (hardware error, IVHW) и запросы прерывания таймера ядра (core timer, IVTMR), вводят цепочку обработку прерываний на уровне ILAT, так что на них не влияют регистры прерывания уровня системы (SIC_IWR, SIC_ISR, SIC_IMASK, SIC_IARx).

Если несколько источников прерывания используют одно общее прерывание ядра, то ISR должен сам идентифицировать периферийное устройство, которое сгенерировало прерывание. Так что для ISR может понадобиться программно опросить периферийное устройство, чтобы определить, какое действие нужно предпринять для обработки прерывания.

[Системные прерывания от периферийных устройств]

Система процессора имеет несколько периферийных устройств, поэтому для их обслуживания может потребоваться поддержка нескольких прерываний. В таблице 4-7 перечислены:

• Источники прерывания от периферийных устройств (столбец Peripheral Interrupt Source).

• Идентификатор прерывания периферии (столбец Peripheral Interrupt ID) - числовые коды, используемые для заполнения системных регистров назначения прерываний (system interrupt assignment registers, SIC_IARx). Подробнее см. описание регистров SIC_IARx во врезке "Регистры SIC_IARx".

• Привязка прерываний общего назначения (General-purpose interrupt) ядра, присвоенное по умолчанию после сброса (столбец Reset Defaults). Здесь перечислены имена векторов EVT.

• Идентификатор прерывания ядра (core interrupt ID, столбец Core Interrupt ID), используемый в регистрах назначения системных прерываний (system interrupt assignment registers, SIC_IARx).

Таблица 4-7. Состояние источников прерывания периферийных устройств после сброса.

Структура обработки прерываний периферийных устройств гибко настраивается. По умолчанию после сброса несколько прерываний периферийных устройств совместно используют одно прерывание ядра общего назначения, как это показано в разделе "System Interrupt" руководства ([3] для BF538).

Обработчик прерывания, который должен поддерживать обработку нескольких источников прерываний от аппаратуры периферийных устройств, должен опросить регистры этой аппаратуры (привязанные к памяти регистры, memory mapped registers, MMR), чтобы определить, какое периферийное устройство сгенерировало прерывание.

Если привязка по умолчанию (см. врезку "Привязки приоритетов по умолчанию" или раздел "System Interrupt" руководства [3] для BF538), то в инициализацию прерывания входят только следующие шаги:

• В таблицу векторов ядра Event Vector Table (EVT) записывается адрес вектора обработчика прерывания.
• Инициализируется регистр IMASK.
• Демаскируется определенное прерывание периферийного устройства в регистре SIC_IMASK.

*pSIC_IAR1 |= PX_IVG(11, 8);// Устанавливает периферийное устройство #11 (SPORT1 RX) на IVG8

[Регистры Core Event Controller (CEC)]

Контроллер событий использует 3 регистра MMR ядра для координирования отложенных запросов событий (поддержка приоритетов и вложенности прерываний). В каждом из этих MMR младшие 16 бит соответствуют 16 уровням событий (т. е. приоритетам). Например, бит 0 соответствует самому приоритетному уровню событий, режиму эмуляции (Emulator mode). Вот эти регистры:

• IMASK - interrupt mask, маска прерывания.
• ILAT - interrupt latch, захват прерывания.
• IPEND - interrupts pending, отложенные прерывания.

К этим 3 регистрам можно получить доступ только в режиме супервизора (Supervisor mode).

[Event Vector Table]

Таблица векторов событий (Event Vector Table, EVT) это аппаратная таблица из 16 записей, каждая 32 бита длиной. Каждая запись EVT содержит вход в процедуру обработки каждого возможного события ядра. Записи EVT доступны как MMR, и каждая запись может быть запрограммирована при сбросе соответствующим адресом вектора для ISR. Когда происходит событие, то происходит передача управления (вызовом подпрограммы обработчика прерывания) по начальному адресу, сохраненному в EVT для этого события.

Архитектура процессора позволяет запрограммировать уникальные адреса в каждый из векторов прерывания; таким образом, нет жесткой фиксации положения обработчиков векторов прерывания в памяти на базе какого-то адреса. Этот подход минимизирует задержку, потому что не нужна команда дальнего перехода (long jump) из таблицы векторов в реальный код ISR (т. е. в EVT уже как бы закэшированы).

В таблице 4-8 перечислены события по приоритету. Каждое событие имеет соответствующий бит в регистрах состояния ILAT, IMASK и IPEND.

Таблица 4-8. Таблица векторов прерывания (EVT) ядра.

[Регистры и инструкции возврата]

Использование переназначения EVT позволяет другим событиям использовать адрес вектор сброса Reset как свой собственный адрес вектора, вместо своего назначенного по умолчанию адреса. Этот подход устраняет потребность двойной косвенной адресации, чтобы выполнить переход на внешне предоставленный адрес при сбросе.

Примерно так, как регистр RETS управляет инструкциями вызова CALL и возврата RTS, так и прерывания и исключения используют аппаратный стек регистров с одной записью. Если обрабатывается прерывание, секвенсер программы сохраняет адрес возврата в регистр RETI до перескока на вектор события. Типичная подпрограмма ISR завершается инструкцией RTI, которая командует секвенсеру перезагрузить значение программного счетчика (Program Counter, PC) значением из регистра RETI. Следующий пример показывает простую подпрограмму ISR.

isr:
   [--SP] = (R7:0, P5:0); /* протолкнуть (push) в стек регистры ядра */
   [--SP] = ASTAT;        /* протолкнуть (push) в стек статус арифметики */
   /* Здесь нужно разместить код алгоритма ISR */
   ...
   ASTAT = [SP++];        /* выбрать (pop) из стека статус арифметики */
   (R7:0, P5:0) = [SP++]; /* выбрать (pop) из стека регистры ядра */
   RTI;                   /* возврат из прерывания */
isr.end:

Нет необходимости заботиться о содержимом регистра RETI, когда запрещена вложенность прерываний. Однако если вложенность должна быть разрешена, и соответствующий обработчик прерывания должен быть прерван (вытеснен) прерыванием с более высоким приоритетом, то регистр RETI должен быть сохранен, скорее всего в стек (хотя не обязательно именно в стек, можно и в другое место памяти).

Хитрость в том, что доступ к регистру RETI имеет неявный дополнительный эффект - чтение регистра RETI разрешает вложенность прерываний. Запись в RETI снова запрещает вложенность. Эта возможность позволяет обработчику ISR разбить самого себя на прерываемые и не прерываемые секции кода. Например:

isr:
   [--SP] = (R7:0, P5:0);  /* протолкнуть в стек регистры ядра */
   [--SP] = ASTAT;         /* протолкнуть в стек статус арифметики */
   /* В этом месте должен быть размещен критический, атомарно выполняемый код: */
   ...
   [--SP] = RETI;          /* разрешить вложенность прерываний */
   /* В этом месте нужно разместить основной код алгоритма ISR,
      который может быть прерван более приоритетными ISR: */
   ...
   RETI = [SP++];          /* снова запрет вложенности прерываний */
   /* Здесь можно разместить еще одну секцию критического, 
      атомарно выполняемого кода: */
   ASTAT = [SP++];         /* выбрать из стека статус арифметики */
   (R7:0, P5:0) = [SP++];  /* выбрать из стека регистры ядра */
   RTI;                    /* возврат из прерывания */
isr.end:

Если не требуется иметь в ISR не прерываемый код, то хорошей практикой программирования будет разрешить вложенность немедленно. Это предотвратит нежелательную задержку для запуска высокоприоритетных прерываний. Пример:

isr:
   [--SP] = RETI;          /* разрешить вложенность прерываний */
   [--SP] = (R7:0, P5:0);  /* вдвинуть в стек (push) регистры ядра */
   [--SP] = ASTAT;         /* вдвинуть в стек (push) флаги арифметических операций */
   /* В этом месте нужно разместить код обработчика прерывания: */
   ...
   ASTAT = [SP++];         /* восстановить из стека (pop) флаги арифметических операций */
   (R7:0, P5:0) = [SP++];  /* восстановить из стека (pop) регистры ядра */
   RETI = [SP++];          /* запрет вложенности прерываний */
   RTI;                    /* возврат из прерывания */
isr.end:

Подробное описание техники см. в разделе "Вложенность прерываний". События эмуляции, NMI и исключения используют технику наподобие "нормальных" прерываний (т. е. без вложенности). Однако они имеют свой собственный регистр возврата и соответствующую ему инструкцию возврата. Таблица 4-10 дает обзор этих инструкций и регистров.

Таблица 4-10. Регистры и инструкции возврата.

Выполнение инструкций RTX, RTN или RTE в событии с меньшим приоритетом. Инструкции RTX, RTN и RTE разработаны для возврата из исключения (eXception), NMI и события эмуляции (Emulator) соответственно. Не используйте их для возврата из события с приоритетом ниже. Для возврата из прерывания используйте инструкцию RTI. Ошибочное использование инструкций возврата может привести к непредсказуемым результатам.

В случае RTX будет аппаратно очищен бит IPEND[3]. В случае RTI в регистре IPEND будет аппаратно очищен единичный бит, соответствующий прерыванию с самым высоким приоритетом.

[Emulation Interrupt (прерывание отладки)]

Событие эмуляции переводит процессор в режим эмуляции (Emulation mode), где инструкции читаются из интерфейса JTAG. Это самое высокое по приоритету прерывание для ядра. Детальное описание процесса эмуляции см. в разделе Blackfin Processor Debug руководства по аппаратуре Вашего процессора ([3] для BF538).

[Reset Interrupt (прерывание сброса)]

Прерывание сброса (RST) может быть инициировано через вывод ~RESET или при событии истечения таймаута сторожевого таймера (watchdog timer). Это место отличается от прерываний тем, что его содержимое только для чтения. Запись по этому адресу меняет регистр, но не меняет вектора процессора при сбросе. Процессор всегда при сбросе переходит на вектор сброса.

Программные сбросы и сторожевой таймер. Программный сброс может быть инициирован тремя путями:

• Сторожевым таймером, если это сконфигурировано.
• Установкой поля бит системного сброса (System Reset field) в регистре программного сброса (см. рис. 3-2).
• Выполнением инструкции RAISE 1.

Сторожевой таймер сбрасывает одновременно ядро и периферийные устройства. Результатом системного сброса (System Reset) будет сброс периферии без сброса ядра и без инициирования последовательности загрузки.

Сброс системы должен быть выполнен при выполнении из памяти L1 (либо кэш, либо SRAM). Когда память инструкций L1 сконфигурирована как кэш, убедитесь, что последовательность системного сброса была прочитана в кэш.

После того, как был инициирован сброс либо от сторожевого таймера, либо от System reset, процессор гарантирует, что все периферийные устройства распознаны, и завершает их сброс.

Для сброса, который был сгенерирован сторожевым таймером, процессор перейдет в выполнение последовательности загрузки, как если бы процессор прошел полное включение с переходом в активный режим. Режим загрузки конфигурируется состоянием выводов управления BMODE и бита NOBOOT (не делать загрузку при программном сбросе).

Если бит NOBOOT в регистре SYSCR очищен, то последовательность загрузки определяется управляющими битами BMODE. Имейте в виду, что содержимое регистра SYSCR меняется от одной модели процессора к другой, поэтому конкретную реализацию см. в описании аппаратуры процессора ([3] для BF538).

/* Выдача мягкого сброса системы */
   P0.L = LO(SWRST);
   P0.H = HI(SWRST);
   R0.L = 0x0007;
   W[P0] = R0;
   SSYNC;/* Ожидание момента завершения системного сброса (понадобится 5 тактов SCLK). */
/* Подразумевается самый худший случай, когда соотношение CCLK:SCLK 
   составляет (15:1), используется 5*15 = 75 в качестве начального значения
   для счетчика цикла */
   P1 = 75;
   LSETUP(start, end) LCO = P1;
start:
end:
   NOP;/* Очистка системы мягким сбросом */
   R0.L = 0x0000;
   W[P0] = R0;
   SSYNC;
   RAISE 1;

У ядра есть выход, который показывает двойную ошибку. Это не восстанавливаемое состояние. Система может быть запрограммирована для отправки запроса на сброс, если детектировано событие двойной ошибки. Это детектирование разрешено битом DOUBLE_FAULT в регистре SWRST. Впоследствии запрос на сброс вызывает сброс системы для ядра и периферийных устройств.

Вектор сброса определяется системой процессора. Он указывает на начало кода встроенное в кристалл boot ROM, или на начало внешней асинхронной памяти - в зависимости от состояния битов выбора режима загрузки BMODE.

[NMI (немаскируемое прерывание)]

Запись NMI зарезервирована для немаскируемого прерывания, которое может быть сгенерировано сторожевым таймером или входным сигналом NMI для процессора. Пример события, на которое требуется немедленное внимание процессора, и для чего подходит NMI, это предупреждение об отключении питания.

Внимание: если произойдет исключение в обработчике события, который уже обслуживает исключение, NMI, сброс, или событие эмуляции, то это вызовет срабатывание условия двойной ошибки, и адрес инструкции, вызвавшей исключение, будет записан в RETX.

Вывод NMI чувствителен к лог. уровню, и должен всегда быть притянут к своему неактивному состоянию, если не используется. Для некоторых моделей вход NMI активен для лог. 1, и на некоторых для лог. 0, за подробностями обратитесь к даташиту на Ваш процессор (для BF538 активный уровень для NMI это ...).

[Exceptions (исключения)]

Исключения обсуждаются в разделе "Аппаратные ошибки и обработка исключений".

[Hardware Error Interrupt (прерывание аппаратной ошибки)]

Аппаратные ошибки также обсуждаются в разделе "Аппаратные ошибки и обработка исключений".

[Core Timer Interrupt]

Прерывание таймера ядра (Core Timer Interrupt, IVTMR) срабатывает, когда значение таймера ядра достигает 0. Дополнительную информацию по таймеру ядра см. в описании аппаратуры процессора ([3] для BF538).

[General-purpose Core Interrupts (IVG7-IVG15)]

Системный контроллер прерываний (System Interrupt Controller, SIC) может перенаправлять прерывания на события ядра (или группы приоритетов) IVG7-IVG15, которые также называются как прерывания общего назначения. Прерывания общего назначения используются для любого события в системе, которое требует внимания со стороны вычислительного ядра. Например, контроллер DMA может использовать прерывание для сигнализации об окончании передачи данных, или устройство последовательного обмена может использовать прерывание для сигнализации об ошибках передачи.

Программа может также вызывать срабатывание прерываний общего назначения путем использования инструкции RAISE. Эта инструкция может принудительно генерировать события для прерываний IVG15-IVG7, IVTMR, IVHW, NMI и RST, но не для генерации исключений и генерации входа в режим эмуляции (EVX и EMU соответственно).

Хорошей практикой является резервировать 2 группы прерываний с самым низким приоритетом (IVG15 и IVG14) для обработки программных прерываний.

Для системных прерываний, специфичных для конкретной модели процессора, см. описание аппаратуры по этому процессору ([3] для BF538).

[Как глобально разрешить/запретить прерывания]

Прерывания общего назначения можно глобально запретить (т. е. запретить сразу все прерывания) инструкцией CLI Dreg, и заново разрешить инструкцией STI Dreg (здесь Dreg это регистр ядра процессора). Обе эти инструкции доступны только в режиме супервизора. События Reset, NMI, emulation и exception не могут быть глобально запрещены. Глобальный запрет прерываний очищает биты IMASK[15:5] после сохранения текущего состояния IMASK.

   CLI R5; // сохранение IMASK в R5, и маскирование всех прерываний

/* Тут можно поместить критические инструкции: */
   ...
   STI R5; // восстановление содержимого IMASK из R5

Если будет попытка выполнить инструкцию CLI или STI в пользовательском режиме ядра (User mode, не Supervisor), то произойдет исключение ошибки: недопустимое использование защищенного ресурса (Illegal Use of Protected Resource exception). Инструкции CLI и STI не могут быть выполнены параллельно с другими инструкциями.

Инструкция CLI часто используется непосредственно перед инструкцией IDLE. Инструкция STI часто размещается после инструкции IDLE, потому что она будет выполнена первой после выхода ядра из состояния приостановки (при пробуждении ядра процессора).

Когда несколько инструкций нужно выполнить атомарно, или когда требуется точно выдержать время выполнения куска кода прерывания, то используют глобальный запрет прерываний (инструкцией CLI) перед начальным куском критичного кода. Но нужно при этом не забыть снова разрешить прерывания в конце критичного кода (инструкцией STI).

[Обслуживание прерываний]

Контроллер событий ядра (Core Event Controller, CEC) имеет один элемент организации очереди на событие - бит в регистре ILAT. Соответствующий бит регистра ILAT устанавливается, когда детектирован фронт сигнала прерывания (что занимает по времени 2 такта ядра), и очищается, когда устанавливается соответствующий бит регистра IPEND. Бит IPEND показывает, что вектор события введен в конвейер ядра. В этот момент времени CEC распознает и ставит в очередь фронт следующего события на соответствующем входе прерывания. Минимальная задержка от момента фронта прерывания общего назначения до выставления на выходе бита в IPEND занимает 3 такта ядра. Однако задержка может быть намного больше, в зависимости от уровня активности ядра и состояния.

Чтобы определить, когда обработать прерывание, контроллер операцией логического AND (т. е. лог. "И") все три элемента в ILAT, IMASK, и текущий уровень приоритета кода, выполняемого процессором.

Обработка прерывания с самым высоким приоритетом вовлекает следующие действия:

1. Вектор прерывания в Event Vector Table (EVT) становится следующим адресом для выборки.

В момент прерывания отбрасывается (обрывается) большинство инструкций, находящихся в настоящий момент в конвейере. При обработке исключения все инструкции после той инструкции, которая вызвала исключение, будут отброшены. На исключении по ошибке будут отброшены инструкция, вызвавшая исключение и все инструкции за ней.

2. Адрес возврата сохраняется в подходящий регистр возврата.

Регистр возврата для прерываний это RETI, для исключений RETX, для NMI это RETN, и для эмуляции/отладки это RETE. Адресом возврата будет адрес следующей инструкции за последней выполненной инструкцией в нормальном потоке выполнения программы.

3. Режим процессора устанавливается в уровень взятого события.

Если событие это NMI, исключение или прерывание, то режим процессора будет Supervisor. Если событие было исключением эмуляции, то режим процессора будет Emulation.

4. Перед тем, как начнется выполнение первой инструкции обработчика, соответствующий бит в регистре ILAT очищается и соответствующий бит в регистре IPEND устанавливается.

Бит IPEND[4] также устанавливается для запрета всех прерываний, чтобы запретить все прерывания, пока сохраняется адрес возврата в RETI.

[Обслуживание системных прерываний]

Прерывания, которыми сигнализируют о событиях периферийные устройства, могут быть как сгруппированы на один уровень приоритета (на одну группу прерываний IVGx приходятся прерывания от нескольких устройств), так и обслуживаться отдельно в выделенной группе (к группе IVGx привязано только одно прерывание). Это зависит от настройки - прерывания могут группироваться в контроллере системных прерываний (System Interrupt Controller, SIC). В отличие от прерываний ядра, системные прерывания чувствительны к уровню. Периферийные устройства не снимают запрос на прерывание, пока это не будет сделано вручную в коде программы.

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

Хорошей практикой программирования является как можно быстрее подтвердить для периферийного устройства запрос на обслуживание прерывания. Подтверждение позволит периферийному устройству отреагировать на следующие события максимально быстро. ISR должен гарантировать, что запросы были сняты до того, как выполнится инструкция RTI. Иначе ISR будет немедленно вызван заново после выполнения инструкции RTI.

Часто запросы прерываний очищаются операциями write-one-to-clear (W1C), т. е. "записать единицу для очистки". Такая команда записи обычно не приостанавливает ядро, а автоматически захватывается и синхронизируется с доменом системной тактовой частоты (SCLK) до того, как попасть на шину PAB. В зависимости от соотношения частот CCLK и SCLK этот процесс может занять несколько циклов CCLK, прежде чем операция W1C достигнет периферийного устройства. Если операция W1C выполнится в конце ISR, то рекомендуется либо инструкцию SSYNC, либо сделать дополнительный доступ к шине PAB перед инструкцией RTI, чтобы гарантировать, что периферийное устройство снимет запрос до выполнения RTI. Поскольку секвенсер программы и контроллер CEC работают на частоте CCLK, то снятие запроса все еще должно быть синхронизировано с доменом CCLK. Эта синхронизация может занять другой такт SCLK, который не защищен инструкцией SSYNC. Обычно заключительное восстановление регистра и выборка из стека защищает от этой проблемы, и она никогда не случается, однако в общем случае программа все равно должна быть протестирована на предмет корректной работы в случае выбора большого соотношения между частотами CCLK и SCLK. Дополнительное чтение PAB до инструкции RTI самый лучший способ гарантировать действительную очистку события в SIC до выхода из ISR.

   IF CC JUMP away_from_here;
   CSYNC;
   R0 = [P0];
away_from_here:

[Очистка запросов на прерывание]

Когда процессор обрабатывает событие ядра, то он автоматически очищает запрошенный бит в регистре ILAT, и в коде ISR не требуется никаких дополнительных действий. Важно понимать, что контроллер SIC не предоставляет какой-либо механизм обратного подтверждения прерывания от контроллера CEC для периферийного устройства. Хотя биты ILAT точно так же автоматически очищаются, когда обслуживается прерывание, все равно сигнализация от периферии не очищает этот чувствительный к уровню запрос, пока это явно не будет сделано в коде программного обеспечения. Если запрос не будет очищен программно, то периферийное устройство удерживает запрос на прерывание, и соответствующий бит ILAT будет немедленно установлен заново. Это приведет к тому, что будет снова вызван тот же вектор прерывания сразу после того, как будет выполнена инструкция RTI.

Таким образом, каждая подпрограмма, которая обслуживает прерывания от периферийного устройства (т. е. код ISR) обязательно должна очистить сигнализирующий запрос на прерывание от соответствующего периферийного устройства. Отдельные периферийные устройства предоставляют заданный механизм для очистки запросов прерывания. К примеру, прерывания приема очищаются, когда принятые данные вычитываются из соответствующих буферов. Запросы на передачу обычно очищаются, когда программа (или DMA) записывает новые данные в буферы передачи. Эти неявные механизмы подтверждения позволяют избежать необходимости трат дополнительных программных циклов в потоковых интерфейсах. Другие периферийные устройства, такие как таймеры, порты GPIO, и запросы на обработку ошибки требуют явных инструкций подтверждения, которые обычно выполняются эффективными операциями W1C (write-1-to-clear).

Листинг 4-4 показывает хороший пример того, как запрос прерывания от GPIO должен быть обработан процессором ADSP-BF537 Blackfin.

Листинг 4-4. Обработка запроса на прерывание от GPIO.

#include < defBF537.h >
.section program;
_portg_a_isr:
   /* сохранение используемых регистров */
   [--sp] = (r7:7, p5:5);
   /* очистка запроса на прерывания от вывода GPIO PG2, */
   /* не имеет значения какой канал используется, A или B */
   p5.l = lo(PORTGIO_CLEAR);
   p5.h = hi(PORTGIO_CLEAR);
   r7 = PG2;
   w[p5] = r7;
   /* здесь поместите код пользователя */
   ...
   /* синхронизация системы, восстановление регистров и выход */
   ssync;
   (r7:7, p5:5) = [sp++];
   rti;
_portg_a_isr.end:

В этом примере показана инструкция типа W1C, которая может потребовать несколько циклов SCLK для завершения, в зависимости от загруженности системы и истории выполнения команд. Программный секвенсер не ждет, пока инструкция завершится, и немедленно продолжает выполнение программы. Инструкция SSYNC гарантирует, что команда W1C действительно завершится и очистит запрос в периферийном устройстве GPIO до того, как выполнится инструкция RTI. Однако инструкция SSYNC не гарантирует, что освобождение запроса прерывания также было распознано контроллером CEC, что может потребовать некоторого большего количества циклов CCLK - в зависимости от соотношения CCLK к SCLK. В обработчиках, состоящих всего из нескольких инструкций рекомендуется использовать 2 инструкции SSYNC между командой очистки и инструкцией RTI. Однако одной инструкции SSYNC обычно достаточно, если команда очистки выполнена ближе к началу кода ISR, или если за инструкцией SSYNC следует другой набор инструкций до того, как произойдет возврат из ISR. Обычно для этой цели используется множественная команда восстановления из стека (pop-multiple), как это показано в листинге 4-4. Альтернативно можно применить чтение из любого системного MMR до выполнения RTI - это будет гарантией, что запись завершена и условие прерывания очищено.

Чувствительная к уровню природа прерываний от периферии позволяет привязать несколько прерываний на один канал IVG и, таким образом, сделать для них одинаковый приоритет. Все это программируется через регистры SIC_IARx. Если сделана привязка нескольких прерываний на одну группу/канал IVG, то общий ISR для этих прерываний обычно должен опрашивать регистр SIC_ISR, чтобы определить какой источник сигнализировал о прерывании. Если вдруг произошло так, что несколько прерываний одновременно запросили прерывание, то тогда в зоне ответственности ISR выбрать способ (и приоритет) их обработки - либо за один вызов ISR, либо за несколько вызовов (обычно 2 вызова), обрабатывая один запрос прерывания на один на вызов. Если был обработан только один запрос, и он был очищен до выполнения инструкции RTI, то тот же ISR будет немедленно вызван снова, чтобы обработать второй запрос от другого периферийного устройства, который все еще находится в ожидании обработки. Первый способ обработки (за один проход ISR) потребует меньше циклов для обслуживания обоих запросов, а второй запрос позволяет повысить приоритетность обработки запросов для выбранного прерывания - в случае использования обработки прерываний без вложенности.

[Программные прерывания]

Программное обеспечение не может напрямую установить биты регистра ILAT, так как запись в ILAT приведет к выполнению операции write-1-to-clear (W1C). Вместо этого используйте инструкцию RAISE для программной установки отдельных битов ILAT. Это безопасно установит нужные биты ILAT без влияния на остальную часть регистра.

RAISE 1; /* вызовет срабатывание запроса прерывания сброса */

Инструкций RAISE не должна использоваться для запуска события эмуляции или исключения, это должно обрабатываться специальными инструкциями EMUEXCPT и EXCPT.

Часто инструкция RAISE выполняется в обработчике прерывания для снижения приоритета прерывания. Это позволяет менее срочным для выполнения кускам кода ISR быть прерванными даже более низкими по приоритету прерываниями.

isr7: /* Обработчик прерывания для IVG7 */
   ...
   /* здесь выполняются инструкции с высоким приоритетом: */
   ...
   /* рукопожатие с сигнализирующим периферийным устройством: */
   RAISE 14;
   RTI;
isr7.end:
isr14: /* Обработчик программного прерывания для IVG14 */
   ...
   /* дальнейшая обработка события, инициированная в IVG7 */
   RTI;
isr14.end:

Этот пример может читать данные из любого приемного интерфейса, выложить их в очередь, и позволить ISR с меньшим приоритетом выполниться сразу после возврата из isr7. Поскольку IVG15 используется для нормального выполнения программы в системах без многозадачности, IVG14 часто используется для выделения под программные прерывания.

Пример кода обработки исключения использует тот же самый принцип обработки исключения на нормальном уровне приоритета (см. раздел "Аппаратные ошибки и обработка исключений", листинг 4-7).

[Вложенность прерываний]

Прерывания могут обрабатываться либо с разрешением вложенности друг в друга, либо с запретом вложенности. Это уже обсуждалось в разделе "Регистры и инструкции возврата".

Не вложенные прерывания. Если не требуется вложенность прерываний, то все прерывания будут запрещены, пока выполняется какой-то ISR. Однако, обратите внимание: emulation, NMI и исключения все еще будут восприниматься системой.

Когда системе не нужно поддерживать вложенность прерываний, то не нужно сохранять в стек адрес возврата, который и так сохраняется в RETI. Только порция данных, хранящая состояние машины, должна быть сохранена в стеке супервизора (обычно эти действия осуществляются в начале кода ISR). Для возврата из не позволяющего вложенность ISR должна быть выполнена только инструкция RTI, потому что адрес возврата уже хранится в регистре RETI.

На рисунке 4-8 показан пример обработки прерывания, где прерывания глобально запрещены для всего ISR.

Рис. 4-8. Обработка не вложенного прерывания.

CYCLE 1: прерывание захвачено. Все возможные источники прерывания определены.
CYCLE 2: прерывание приоритезировано.
CYCLE 3: все инструкции выше A2 убиты. A2 будет убита, если это инструкция RTI или CLI. Начнется выборка адреса старта ISR.
CYCLE 4: I0 (инструкция в начале ISR) входит в конвейер.
CYCLE M: Когда инструкция RTI достигнет стадии DF1, инструкция A3 будет выбрана в подготовке возврата из прерывания.
CYCLE M+4: RTI достигла стадии WB, заново разрешаются прерывания.

Вложенные прерывания. Если нужно обеспечить поддержку вложенности прерываний в каком-то ISR, то в нем адрес возврата в точку прерывания должен быть дополнительно явно сохранен в стеке, и впоследствии восстановлен из стека при выходе. Вложенность разрешается инструкцией проталкивания (push) в стек супервизора адреса возврата, находящегося в настоящий момент в RETI ([--SP] = RETI), что обычно делается как можно раньше, в начале ISR (у которого приоритет меньше, и который позволяет вложенность в себя). Это действие очистит бит глобального запрета прерываний IPEND[4], и разрешит прерывания. Далее, как обычно, все регистры, используемые в ISR, также проталкиваются в стек супервизора. Состояние процессора сохраняется в стек супервизора, не в стек режима пользователя. Следовательно, инструкции проталкивания в стек RETI ([--SP] = RETI) и выборки из стека RETI (RETI = [SP++]) будут работать со стеком супервизора.

Рисунок 4-9 показывает, что проталкиванием RETI в стек прерывания могут быть разрешены во время выполнения ISR, в результате прерывания будут запрещены только в очень малый отрезок времени.

Рис. 4-9. Обработка вложенного прерывания.

CYCLE 1: прерывание захвачено. Все возможные источники прерывания определены.
CYCLE 2: прерывание приоритезировано.
CYCLE 3: все инструкции выше A2 убиты. A2 будет убита, если это инструкция RTI или CLI. Начнется выборка адреса старта ISR.
CYCLE 4: I0 (инструкция в начале ISR) входит в конвейер. Предполагается, что это инструкция проталкивания (push) в стек RETI (с целью разрешить вложенность прерываний).
CYCLE 10: когда push достигнет стадии DF2, прерывания снова разрешаются.
CYCLE M+1: когда инструкция выборки из стека (pop) RETI достигнет стадии DF2, прерывания запрещены.
CYCLE M+5: когда RTI достигнет стадии WB, прерывания заново разрешены.

Листинг 4-5. Пример предварительного кода для ISR, позволяющего вложенность.

/* Код пролога для ISR, позволяющего вложенность прерываний. Здесь в стек
   супервизора проталкивается значение адреса возврата в RETI, что гарантирует
   разрешение прерываний (у которых более высокий приоритет, что у текущего).
   До этого момента все прерывания приостановлены. */
ISR:
   [--SP] = RETI; /* это действие разрешает прерывания и сохраняет адрес возврата в стек */
   [--SP] = ASTAT;
   [--SP] = FP;
   [-- SP] = (R7:0, P5:0);

/* Здесь должно быть размещено тело обработчика прерывания. Обратите внимание, что 
   ресурсы процессора (аккумуляторы, DAG-и, счетчики циклов и границы) не сохранены.
   Т. е. предполагается, что ISR не использует ресурсы процессора. */
   ...

Листинг 4-6. Пример завершающего кода для ISR, позволяющего вложенность.

/* Код эпилога для ISR, позволяющего вложенность. Здесь восстанавливаются
   регистры ASTAT, данных и указателя. Выборка (pop) RETI из стека супервизора
   гарантирует, что прерывания приостановлены между загрузкой адреса возврата
   и выполнением RTI. */
   (R7:0, P5:0) = [SP++] ;
   FP = [SP++] ;
   ASTAT = [SP++] ;
   RETI = [SP++];

/* Выполнение RTI, которая делает переход на адрес возврата, снова разрешает
   прерывания, и переключается в режим пользователя (User mode), если это было
   последнее из ряда вложенных друг в друга ISR. */
   RTI;

Инструкция RTI приводит к возврату из прерывания. Адрес возврата извлекается из стека в регистр RETI, это действие приводит к приостановке прерываний от момента, когда RETI восстановился до момента, когда инструкция RTI завершила выполнение. Приостановка прерываний предотвращает ситуацию, что следующее прерывание повредит регистр RETI.

Далее инструкция RTI очистит бит с самым высоким приоритетом, который установлен в настоящий момент в IPEND. Затем процессор перескакивает по адресу, на который указывает значение регистра RETI, и заново разрешает прерывания очисткой IPEND[4].

Запоминание вложенных запросов прерываний. Контроллер прерываний системы (System Interrupt Controller, SIC) детектирует и перенаправляет чувствительные к уровню запросы на прерывание от периферийных устройств. Контроллер событий ядра (Core Event Controller, CEC) предоставляет чувствительное к срезу детектирование для прерываний общего назначения (группы прерываний IVG7-IVG15, жестко привязанные к приоритетам). Следовательно, SIC генерирует синхронный импульс прерывания для CEC, и затем ждет подтверждения прерывания от CEC. Когда прерывание было подтверждено ядром (через выставление подходящего выхода IPEND), SIC генерирует другой синхронный импульс прерывания для CEC, если прерывание периферии все еще выставлено. С таким методом обработки не теряются запросы на обработку прерывания, когда они возникли во время обработки другого прерывания.

Несколько источников прерываний может быть привязано к одному прерыванию общего назначения ядра (группе прерываний IVGx). По этой причине несколько импульсов запросов прерываний могут поступить от SIC одновременно, перед обработкой прерывания или во время обработки для события прерывания, которое уже было детектировано для этого входа прерывания. Для совместно обрабатываемых прерываний на одной группе IVGx есть описанный ранее механизм подтверждения прерывания IPEND, который заново разрешает все совместно обрабатываемые прерывания. Если любое из общих в обработке источников прерываний все еще выставляют свой запрос, то контроллером SIC будет снова сгенерирован как минимум 1 импульс. Регистры состояния прерывания (Interrupt Status registers, ISR) показывают текущее состояние совместно обрабатываемых источников прерывания.

Само-вложенность прерываний ядра. Прерывания, которые вложены "сами в себя" могут быть прерваны событиями с тем же уровнем приоритета. Когда установлен бит SNEN в регистре SYSCFG, то поддерживается самовложенность прерываний ядра. Самовложенность поддерживается для любого уровня прерывания, сгенерированного как инструкцией RAISE, так и для прерываний уровня ядра.

В качестве примера предположим, что бит SNEN установлен, и процессор обрабатывает прерывание, сгенерированное инструкцией RAISE 14. Как только регистр RETI был сохранен в стек внутри ISR, вторая инструкция RAISE 14 позволит процессору обслужить второе прерывание.

Когда разрешена самовложенность, процессор устанавливает последний бит регистра RETI, когда проталкивает его в стек. Когда RETI впоследствии выбирается из стека, то этот последний бит проверяется. Если он установлен, то процессор не делает очистку регистра IPEND. Таким образом, соответствующий бит в IPEND не очищается по выполнении инструкции RTI, и в этом процессе прерывания не теряются. Обратите внимание, что на плечи пользователя ложится ответственность по корректному проталкиванию/выборке (push/pop) регистра RETI в стек/из стека.

Самовложенность не поддерживается для прерываний периферии системного уровня, таких как SPORT или SPI.

Выделение пространства под системный стек. Модель программного стека для обработки исключений подразумевает, что стек супервизора никогда не должен генерировать исключение, когда обработчик исключения сохраняет свое состояние. Однако, если стек супервизора вырастет за запись CPLB или блок SRAM, то фактически может сгенерироваться исключение.

Чтобы гарантировать, что стек супервизора никогда не сгенерирует исключение - не произойдет переполнения последней записи CPLB или блока SRAM при выполнении обработки исключения - рассчитайте максимальное пространство, которое займут все ISR и обработчик исключения, когда они станут активны, и выделите под стек достаточно места в SRAM.

[Задержки в обработке прерываний]

В некоторых процессорных архитектурах, если инструкции выполняются из внешней памяти, и прерывание произойдет в тот момент, когда выборка инструкции текущей операции не завершилась, то прерывание остается отложенным до того момента, пока текущая операция по обработке инструкции не завершится. Предположим, что процессор работает на частоте 300 МГц, и время выполнения кода из внешней памяти занимает по доступу 100 нс. В зависимости от того, когда произойдет прерывание по отношению к операции выборки инструкции, ISR может быть задержано до примерно 30 тактов. Когда учитываются операции работы с кэшем, ISR может быть задержано на еще большее время - сотни циклов ядра.

Чтобы обеспечить для высокоприоритетных прерываний как можно меньшую задержку в запуске ISR, процессор позволяет выполнить любую операцию с высокой латентностью на уровне системы, пока ISR выполняется из памяти L1. См. рисунок 4-10.

Рис. 4-10. Минимизация латентности в обработке ISR.

Если загрузка инструкции не попала в кэш инструкций L1, и генерируется высоколатентная операция заполнения строки кэша, то когда возникнет прерывание, оно будет задержано до того момента, пока не завершится заполнение. Вместо этого процессор выполнит ISR в его новом контексте, и операция заполнения кэша завершится в фоне.

Обратите внимание, что ISR должна находиться в кэше L1 или памяти SRAM, и не должна генерировать промахи кэша, доступ к памяти L2 или доступ к периферии, поскольку процессор уже занят выполнением операции заполнения строки оригинального кэша. Если в ISR будет выполнена операция по загрузке или сохранению одного из этих типов доступа, то ISR будет задержана пока не завершится оригинальный внешний доступ, до инициирования новой операции загрузки или сохранения.

Если ISR завершит свое выполнение до завершения операции загрузки, то процессор приостановится, ожидая завершения заполнения.

То же самое поведение наблюдается для остановок при вовлечении чтений медленной памяти или периферийных устройств.

Запись в медленную память обычно не показывает такого поведения, поскольку считается, что запись укладывается в 1 цикл, так как данные немедленно передаются в буфер записи для последующей обработки.

Подробнее информацию по структуре памяти и кэша см. раздел 6 "Memory" документации [1].

[Аппаратные ошибки и обработка исключений]

Hardware Error Interrupt. Прерывание аппаратной ошибки (Hardware Error Interrupt) показывает наличие ошибки в аппаратуре или неправильное функционирование системы. Аппаратные ошибки происходят, когда внешняя логика ядра, такая как контроллер шины памяти, не может завершить передачу данных (чтение или запись), и выставляет входной сигнал ошибки для ядра. Такие аппаратные ошибки вызывают Hardware Error Interrupt (прерывание IVHW в таблице векторов событий EVT, с задействованием регистров ILAT, IMASK и IPEND). Обработчик Hardware Error Interrupt может затем прочитать данные о причине ошибки из 5-разрядного поля HWERRCAUSE, имеющегося в регистре состояния секвенсера (Sequencer Status register, SEQSTAT), и в зависимости от вида ошибки предпринять соответствующие действия.

Hardware Error Interrupt генерируется в следующих случаях:

• Ошибки четности шины (Bus parity errors).
• Внутренние ошибки ядра, такие как переполнение в мониторе быстродействия (Performance Monitor overflow).
• Ошибки периферийных устройств.
• Ошибки таймаута шины.

В таблице 4-11 перечислены поддерживаемые аппаратные события ошибки с их соответствующим кодами поля HWERRCAUSE. Код самой последней ошибки появится в поле HWERRCAUSE. Если сразу произошло одновременно несколько ошибок, то только последняя из них может быть распознана и обслужена. Ядро не поддерживает приоритезацию, конвейеризацию или постановку в очередь нескольких кодов ошибок. Hardware Error Interrupt остается активным до тех пор, пока пока остается активным любое из условий ошибки.

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

Аппаратная ошибка может быть сгенерирована либо доступом ядра, либо DMA.

В двухядерных платформах (что не относится к ADSP-BF538) аппаратная ошибка будет зарегистрирована только в том ядре, которое вызвало ошибку. Если в двухядерной платформе ошибку сгенерировал DMA, то ошибка распространится на оба ядра.

Таблица 4-11. Аппаратные условия, которые приводят к прерываниям аппаратной ошибки.

Исключения (Exceptions). Исключения синхронны по отношению к потоку выполнения инструкций. Другими словами, отдельная инструкция может вызвать исключение, когда попытается выполниться. Никакие инструкции после "незаконной" инструкции не будут выполнены до того, как запустится обработчик исключения.

Многие исключения связаны с памятью. Например, исключение будет выдано в случае не выровненного доступа к памяти, или когда произошел промах мимо буфера защиты кэширования (cacheability protection lookaside buffer, CPLB), или когда происходит нарушение защиты доступа. Исключения также выдаются, когда выполняется недопустимая инструкция или недопустимая комбинация регистров для инструкции.

Исключение может быть зафиксировано либо до, либо уже после выполнения инструкции, в зависимости от того, было ли это исключение типа службы или ошибочное исключение типа (service type or an error type exception).

Инструкция, вызвавшая событие исключения службы типа (service type event) будет выполнена, и адрес, записанный в регистре RETX, будет указывать на инструкцию после той, которая вызвала исключение. Пример исключения службы типа - один шаг в отладчике.

Инструкция, вызвавшая события ошибки типа (error type event) не может быть выполнена, так что адрес, записанный в регистр RETX, будет адресом незаконной инструкции. Пример error type event - промах CPLB.

Обычно регистр RETX содержит корректный адрес для возврата. Чтобы пропустить незаконную инструкцию, позаботьтесь о случае, когда следующий адрес не простой следующий линейный адрес. Это может произойти, когда исключение вызывала инструкция в конце цикла. В этом случае правильным следующим адресом будет начало цикла.

Поле EXCAUSE[5:0] в регистре состояния секвенсера (Sequencer Status register, SEQSTAT) записывается всякий раз, когда было взято исключение, и оно указывает обработчику исключения, какой произошел тип исключения. Обратитесь к таблице 4-13 для получения списка событий, которые могли вызвать исключения.

Важно: если исключение произошло в обработчике события, который уже обрабатывает исключение, NMI, сброс, или событие эмуляции, то это вызовет срабатывание условия двойной ошибки (double fault condition), и адрес инструкции, вызвавшей исключение, будет записан в RETX (для процессора BF535 имеется другое поведение, см. таблицу 4-13 и примечание 2 к ней).

Таблица 4-13. События, которые вызывают исключения.

Примечания:

(1): Буква в этом столбце обозначает тип исключения. Для служб (S) адресом возврата будет адрес инструкции, которая следует за исключением. Для ошибок (E) адресом возврата будет адрес инструкции, которая вызвала исключение.

(2): Во время исключения выборки инструкции при невыровенном доступе для процессоров ADSP-BF535 есть отличие: адрес возврата, предоставленный в RETX, является адресом назначения, который не выровнен, а не адресом незаконной инструкции. Например, если сделана попытка косвенного ветвления на не выровненный адрес, находящийся в P0, то адрес возврата в RETX равен P0, а не адресу инструкции ветвления.

Если инструкция привела к нескольким исключениям, то первым в SEQSTAT будет зарегистрировано исключение с самым высоким приоритетом. Приоритеты исключений перечислены в таблице 4-14. Если исключение с самым высоким приоритетом обработано, то будет зарегистрировано и может быть обработано следующее по приоритету исключение, и так далее. Например предположим, что следующая инструкция генерирует исключение промаха CPLB инструкции (0x2C), и исключение промаха данных CPLB (0x26). При выполнении этой инструкции сначала будет сгенерировано событие исключения инструкции CPLB. После обработки этого исключения пользователем ядре выполнит инструкцию снова, и в этот раз будет сгенерировано исключение данных CPLB.

[P0] = R0;   /* генерирует инструкцию CPLB miss и данные CPLB пропадут */

Таблица 4-14. Исключения по убыванию приоритета (чем больше номер приоритета, тем ниже приоритет).

Примечание: объяснение значения исключений см. также в таблице 4-13.

Исключения, возникающие при выполнении обработчика исключения. Когда выполняется обработчик исключения (exception handler), избегайте инструкций, которые генерируют другое исключение. Если произошло исключение при выполнении кода в обработчике исключения, обработчике NMI, по вектору сброса, или в режиме эмуляции, то:

• Инструкция, вызвавшая исключение, не выполняется. Предотвращаются все обратные записи инструкции.
• Не будет взято сгенерированное исключение.
• Поле EXCAUSE в SEQSTAT обновляется кодом неисправимого события (unrecoverable event code).
• Адрес незаконной инструкции сохраняется в RETX. Имейте в виду, что если, к примеру, процессор выполнял бы обработчик NMI, то регистр RETN не был бы обновлен; адрес вызвавшей исключение инструкции всегда сохраняется в RETX.

Чтобы определить, произошло ли исключение во время выполнения обработчика исключения, проверьте в конце обработчика исключения поле SEQSTAT на предмет наличия в нем кода "невосстановимого события" (unrecoverable event, EXCAUSE = 0x25). Если произошло невосстанавливаемое событие, то регистр RETX содержит адрес самой последней инструкции, которая вызвала исключение. Этот механизм не предназначен для восстановления из такой ситуации, только для её детектирования.

Исключения и конвейер. Прерывания и исключения рассматривают инструкции в конвейере по-разному.

• Когда происходит прерывание, то обрываются все инструкции в конвейере.
• Когда происходит исключение, то обрываются все инструкции в конвейере, которые находятся после инструкции, вызвавшей исключение. Для исключений ошибок также обрывается и инструкция, вызвавшая исключение.

Из-за того, что исключения, NMI и события эмуляции имеют выделенный регистр возврата, защита адреса возврата не обязательна. Следовательно, инструкции PUSH и POP для исключений, NMI, событий эмуляции не влияют на систему прерывания.

Однако имейте в виду, что инструкции возврата для исключений (RTX, RTN и RTE) делают очистку самого младшего бита (Least Significant Bit, LSB), который в настоящий момент установлен в IPEND.

Отложенная обработка исключения (Deferring Exception Processing). Обработчики исключения обычно являются длинными подпрограммами, потому что они должны отличать исключения друг от друга и для каждого типа исключения предпринимать соответствующее действие. В результате из-за длины подпрограмм может быть так, что система будет находится в подвешенном состоянии (пока не обработается исключение) слишком долго, не давая выполнятся другим прерываниям.

Чтобы избежать ситуации приостановки прерываний, пишите обработчик исключения как обычно, чтобы он мог идентифицировать все случаи исключения, однако отложите обработку на прерывание с низким приоритетом. Чтобы запустить обработчик прерывания с низким приоритетом, используйте инструкцию принудительного запуска прерывания / сброса (Force Interrupt / Reset instruction, RAISE).

Когда обработка исключения откладывается на прерывание с низким уровнем приоритета IVGx, система должна гарантировать, что в IVGx был произведен вход до того, как произошел возврат в код уровня приложения, который привел к исключению. Если произошло отложенное прерывание с приоритетом выше, чем IVGx, то допустимо войти в прерывание с более высоким приоритетом до входа в IVGx.

Пример кода обработчика исключения. В следующем примере кода применяется обработчик исключения с отложенной обработкой.

Листинг 4-7. Подпрограмма обработчика исключения с отложенной обработкой.

/* Определение исключения производится оценкой поля EXCAUSE в регистре SEQSTAT
   (сначала в стек супервизора сохраняется содержимое регистров R0, P0, P1
   и ASTAT */
   [--SP] = R0;
   [--SP] = P0;
   [--SP] = P1;
   [--SP] = ASTAT;
   R0 = SEQSTAT;
   /* Маскирование содержимого SEQSTAT, в R0 останется только поле EXCAUSE. */
   R0 <<= 26;
   R0 >>= 26;
   /* Используется таблица переходов EVTABLE, jump к событию, на которое 
      указывает R0 */
   P0 = R0;
   P1 = _EVTABLE;
   P0 = P1 + ( P0 << 1 );
   R0 = W [ P0 ] (Z);
   P1 = R0;
   JUMP (PC + P1);
   /* Дальше идет точка входа для события. В этом месте обработка типа исключения
   откладывается на самое низкоуровневое прерывание IVG15. Обычно в этом месте
   происходит передача параметра. */
_EVENT1:
   RAISE 15;
   JUMP.S _EXIT;
   /* Точка входа для IVG14 */
_EVENT2:
   RAISE 14;
   JUMP.S _EXIT;
   /* Тут могут быть обработки для других событий */
/* По окончании обработчика восстанавливаются R0, P0, P1 и ASTAT,
   и происходит возврат. */
_EXIT:
   ASTAT = [SP++];
   P1 = [SP++];
   P0 = [SP++];
   R0 = [SP++];
   RTX;
   
_EVTABLE:
   .byte2 addr_event1;
   .byte2 addr_event2;
   ...
   .byte2 addr_eventN;
   /* Таблица переходов EVTABLE содержит 16-битные смещения адреса для каждого
   события. С использованием смещений позиция этого кода получается независимой
   от места в памяти, и размер таблицы уменьшается.
+--------------+
| addr_event1  | _EVTABLE
+--------------+
| addr_event2  | _EVTABLE + 2
+--------------+
| . . .        |
+--------------+
| addr_eventN  | _EVTABLE + 2N
+--------------+
*/

Пример кода для подпрограммы, декодирующей исключения. Следующий код показывает шаблон подпрограммы низкоуровневого прерывания (ISR), выполняющей отложенную обработку (сюда происходит переход из обработчика исключения, описанного выше).

Листинг 4-8. ISR, обрабатывающий исключения (привязан к группе прерываний IVG15).

   [--SP] = RETI;    /* Проталкивание (push) адреса возврата в стек. */

/* В этом месте разместите тело обработчика исключения: */
   ...
   RETI = [SP++];    /* Выборка (pop) адреса возврата из стека. */
   RTI;              /* Возврат из прерывания. */

[Ссылки]

1. Blackfin® Processor Programming Reference site:analog.com.
2. Blackfin ADSP-BF538.
3. ADSP-BF538/ADSP-BF538F Blackfin Processor Hardware Reference site:analog.com.
4. Как происходит загрузка ADSP-BF533 Blackfin.
5. VisualDSP: функции установки обработчиков прерываний Blackfin.