[maxcy 0]

Есть некое устройство построенное на STR711FR2, в процессе его кодинга было установлено что проц иногда теряет внешние прерывания. Используются прерывания с портов P0.2 и P0.1 оба по переднему фронту (хотя это не важно). Для доказательства этого сделали маленький проект.

 

настройка

 

int main(void)

{

XTI_Init();

XTI_LineModeConfig(XTI_Line9 | XTI_Line10, XTI_FallingEdge);

XTI_LineConfig(XTI_Line9, ENABLE);

XTI_LineConfig(XTI_Line10, ENABLE);

XTI_ModeConfig(XTI_Interrupt, ENABLE);

EIC_IRQChannelPriorityConfig(XTI_IRQChannel,1);

EIC_IRQChannelConfig(XTI_IRQChannel,ENABLE);

 

GPIO_Config(GPIO0,1,GPIO_OUT_PP);

GPIO_Config(GPIO0,(1<<1),GPIO_IN_TRI_CMOS);

GPIO_Config(GPIO0,(1<<2),GPIO_IN_TRI_CMOS);

GPIO_Config(GPIO1,(1<<5),GPIO_OUT_PP);

GPIO_Config(GPIO1,(1<<6),GPIO_OUT_PP);

GPIO_BitWrite(GPIO1,5,0); //--тест

GPIO_BitWrite(GPIO1,6,0); //--тест

 

EIC_IRQConfig(ENABLE);

 

while(1); /* infinite loop */

}

 

обработчик встроен в 71x_it.c в виде

 

void XTI_IRQHandler(void)

{

/* Change the first led of the GPIO0 port pins state */

u16 INT_X=0;

INT_X=XTI_InterruptLineValue();

if (INT_X & XTI_Line10)

{

GPIO_BitWrite(GPIO1,5,1);

GPIO_BitWrite(GPIO1,5,0);

}

if (INT_X & XTI_Line9)

{

GPIO_BitWrite(GPIO1,6,1);

GPIO_BitWrite(GPIO0,0,!GPIO_BitRead(GPIO0,0));

GPIO_BitWrite(GPIO1,6,0);

}

/* Clear the pending bits */

XTI_PendingBitClear(INT_X);

}

Юзаю uVision4

 

так вот было подмечено что когда фронты импульсов прерываний на расстоянии более 14 мкс друг от друга то всё нормально на осциллограммах мы видим оба захода (импульсы на портах), когда они входят в зону менее 14 мкс встречаются пропуски. потом когда они равняются друг к другу всё опять работает исправно.

 

Кто такое наблюдал, просьба рассказать как побороли, но не как обошли. Это просто очень важный момент в нашей системе.

[maxcy 0]

хоть скажите сталкивался кто-то с такими аномалиями?

[scifi 1]

Я работал с STR710. Помню, что там контроллер прерываний какой-то кривой. Не в том смысле, что не работает, а в том, что разбирался с ним долго. Ещё была проблема с прерываниями от флэш (end-of-write interrupt). Как будто они не сделали защёлку на этот сигнал, а просто завели импульс на вход контроллера прерываний, в результате чего прерывания "терялись", если они были маскированы на входе в контроллер прерываний. Проблему с прерыванием от флэш они подтвердили. А вот объяснения описанному сбою пока не вижу.

Предлагаю просто на всякий случай совершить небольшой танец с бубном:

void XTI_IRQHandler(void)
{
    /* Change the first led of the GPIO0 port pins state */
    u16 INT_X;
    INT_X=XTI_InterruptLineValue();
    while (INT_X != 0)
    {
        /* Clear the pending bits */
        XTI_PendingBitClear(INT_X);
        if (INT_X & XTI_Line10)
        {
            GPIO_BitWrite(GPIO1,5,1); 
            GPIO_BitWrite(GPIO1,5,0); 
        }
        if (INT_X & XTI_Line9)
        {
            GPIO_BitWrite(GPIO1,6,1); 
            GPIO_BitWrite(GPIO0,0,!GPIO_BitRead(GPIO0,0)); 
            GPIO_BitWrite(GPIO1,6,0); 
        }
        INT_X=XTI_InterruptLineValue();
    }
}

[maxcy 0]

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

Ещё попробовал концовку так

EIC_IRQConfig(DISABLE);

INT_X=XTI_InterruptLineValue();

EIC_IRQConfig(ENABLE);

тоже нет результата.

[scifi 1]

Может быть, импульсы слишком короткие? Наверняка есть требование на минимальную длительность импульса по отношению к тактовой частоте. Только не знаю, где оно написано.

[maxcy 0]

импульсы нормальные.