i.MX28evk spurious interrupt

[rnd]

Hello.

I'm working with the i.MX28evk board and once in a while I get a spurious interrupt (0x7F) from GPIO bank 0 (0x7F). All GPIO IRQs in Bank 0 are turned off but I am using the CAN interface on GPIO0_22/23, has anyone seen this before?

[qiang_li-mpu_se]

The attached is the Linux patch to enable the iMX28 GPIO group 0 interrupt. You can try it.

[Yuri]

   Looks like the problem relates to so called “phantom interrupts”, mentioned in NOTE

of section 5.2.1 (Nesting of Multi-Level IRQ Interrupts) of the i.MX28 Reference Manual.

Interrupt source number 0x7F (Table 5-1. i.MX28 Interrupt Sources) is just default

value of HW_ICOLL_STAT register, even when no (real) interrupts are pending.

   Users should provide interrupt service (in ISR), even if it is only return-from-interrupt

instruction.

[MarcCoussement]

Hi Andrew,

Thanks for the input ..... indeed a very strange bug in the software. This problem is solved for now by testing the null pointer.

To the other forum users, this problem will only come up if you receive a lot of collisions on a (faulty?) hub we have

Now the system is stable but i get still the "OEMInterruptHandler: undefined IRQ (63)!" error. If 2 PCs connected to the same hub are busy by copying files over the HUB.

But until now I can´t see a problem in stability with the IRQ(63) problem.

I can see that the WINCE is not using any filtering by the FEC based on the MAC address. Using a HUB, the software is processing all packets on the line, also the data for other MAC addresses.

This will give un-needed load on the CPU (receive IRQ) and still need tobe solved, at a first glance on the datasheet the chips supports MAC address filtering.

Trough this is not a problem if you use an Ethernet SWITCH

Marc, 

[fear_nada]

they have some bug in interrupt.cpp for enet driver

 in wince700\platform\common\src\soc\COMMON_FSL_V2\ENET\interrupt.cpp

lines 448

use this code

        if(PacketSize>0xd)

        {

if(pReceiveBuffer!=NULL)
{
            if(((pReceiveBuffer[0xc]<<8)+pReceiveBuffer[0xd])==PTP_TYPE)
            {

                sequenceId=((pReceiveBuffer[0x2c]<<8)+pReceiveBuffer[0x2d]);
                messageType=pReceiveBuffer[0xe];
                GetPTPRxTimer(&RxTimer,BufferDescPointer->Timestamp,sequenceId,messageType);

            }
}
else
RETAILMSG(1, (TEXT("\r\npReceiveBuffer==NULL index =%d\r\n"),index));
         
        }

npReceiveBuffer some times are coming as null and enet.dll are hang by data abort.

but this is not heal "OEMInterruptHandler:  undefined IRQ (63)!"

.

[MarcCoussement]

hi,

I have the same problem "OEMInterruptHandler:  undefined IRQ (63)!"

We can simulate this by connecting the ethernet and or having a lot of Ethernet coming in. We simulate this by connecting to a HUB so all data is coming trough. If we use a Ethernet switch, we don't see that problem.

connecting the IMX 28 to the Ethernet using a HUB simulates also other problems

+OEMSetAlarmTime (.........)

and

OALRTCAlarmIntrHandler alarm interrupt

and

Exception 'Data Abort' ..................'udevice.exe' ............(enet.dll+0x00003798) .....

Any help is appreciated

Marc 

[fear_nada]

Hello! I have same issue!

i use WEC7

i try write to freescale support but they not answer to me.

i try debug it but i don't understand why make this interrupt. Looks like this is software interrupt by kernel by writing in SOFTIRQ bit in HW_ICOLL_INTERRUPTx. But i not found any lines in BSP code where this happened.

Look on my code and look on log(see attached files).

and see my last reply to freescale support: "Then i begin this service request, in intr.c was this code: line 630. OALMSGS(OAL_ERROR,(TEXT("OEMInterruptHandler: undefined IRQ (%d)!\r\n"),((HW_ICOLL_VECTOR_RD() / 4) & 0x3F))); and this operation &x3F mask most bit, and we have 0x3F in hex = 63 in dec, of this, I thought that the value of undef irq is 63. But then i am begin adding more and more debug prints in code, and now i can see that Undefined interrupt = 0x7F. I am post my all debug prints for you in attachment files, we can can see from this debug prints that value of Interrupt Vector Address Register (HW_ICOLL_VECTOR) = 0x1FC. And we can see that (HW_ICOLL_INTERRUPT127) register = 0x0. So my question how this interrupt coming to ARM core if it not enabled in Interrupt Collector Interrupt Register 127. Please look on code, look on debug prints and and you can see everything. I do not understand how to pass an interrupt if it is not enabled in the register HW_ICOLL_INTERRUPT127

"