i.MXRT1176 ENET_QOS strange ISR triggering behaviour

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MXRT1176 ENET_QOS strange ISR triggering behaviour

2,077 Views
Andre_M
Contributor I

I'm working with ENET_QOS on a custom board, following the 'evkmimxrt1170_lwip_ping_enet_qos_freertos_cm7' example.

The strange behaviour is this: sometimes, when I simply remove the ethernet cable, the processor keeps triggering the ENET_QOS_IRQHandler non-stop (with DMA_INTERRUPT_STATUS == 0) until the watchdog reboots the uC.

Since DMA_INTERRUPT_STATUS register value is 0, the function ENET_QOS_CommonIRQHandler (assigned as the ISR handler on s_enetqosIsr) just goes straight through, without going into any of the 'if' statements.

This is the state of the registers when the ISR triggers:

DMA_INTERRUPT_STATUS 0x0

MAC_INTERRUPT_ENABLE 0x0
MAC_INTERRUPT_STATUS 0x21
MTL_INTERRUPT_STATUS 0x0
DMA_CH0_INTERRUPT_ENABLE 0x8041
DMA_CH0_STATUS 0x404

I tried clearing the DMA_CH0_STATUS register inside the ISR, but it remained 0 afterwards and ISRs kept triggering:

// Clear STATUS for channel 0
base->DMA_CH[0].DMA_CHX_STAT |= base->DMA_CH[0].DMA_CHX_STAT;

Then I tried clearing the bits on MAC_INTERRUPT_STATUS. It seems that clearing bit 5 (LPIIS) solves the ISR spam:

volatile uint32_t discard;
// read MAC_LPI_CONTROL_STATUS to clear MAC_INTERRUPT_STATUS bit 5 (0x20)
discard = base->MAC_LPI_CONTROL_STATUS;
(void)discard;

But it doesn't make sense, as this interrupt is not even enabled in MAC_INTERRUPT_ENABLE. What could explain this behaviour?

0 Kudos
Reply
3 Replies

1,557 Views
jeffG1
Contributor I

Hello.
I have a similar issue using a rt1176AVM8A.  I have no interruption enabled :

MAC_INTERRUPT_ENABLE 00000000 : No interrupt mac interrupt enabled
DMA_CH0_INTERRUPT_ENABLE : 0x8000 : NIE

 

But I'm anyway spammed by interruption and the only way to get rid on it, is to clear the  LPI Interrupt Status: 

MAC_INTERRUPT_STATUS 00000021 : LPI Interrupt Status + RGMII Interrupt Status
MAC_LPI_CONTROL_STATUS 0000020C : RLPIST + RLPIEX + RLPIEN
DMA_INTERRUPT_STATUS 00000000
DMA_CH0_STATUS 00000445 :ET + RI + TBU + TI

 

In my case, I don't need to remove the cable, it happens right after the end of the autonegociation procedure. 

 

Like the others, disabling Energy Efficient Ethernet seems to fix my problem, but can you ensure me that an another disabled interruption won't trig the ENET_QOS_IRQHandler  ? 

 

Regards

0 Kudos
Reply

1,926 Views
mttjcksn
Contributor II

I have the exact same issue using this board: https://www.tq-group.com/en/products/tq-embedded/arm-architecture/mba117xl/
running a basic application reusing much of the qos multi-ring example.

I am not using Energy Efficient Ethernet.

I can also resolve the issue by clearing the LPI Interrupt Status bit.



0 Kudos
Reply

2,006 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @Andre_M ,

 

Would you please tell me in which case removing the ethernet cable would 100% reproduce this issue? I will try to reproduce it here.

 

Best Regards,

Kan

0 Kudos
Reply