i.MXRT1176 ENET_QOS strange ISR triggering behaviour

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MXRT1176 ENET_QOS strange ISR triggering behaviour

2,081件の閲覧回数
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 件の賞賛
返信
3 返答(返信)

1,561件の閲覧回数
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 件の賞賛
返信

1,930件の閲覧回数
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 件の賞賛
返信

2,010件の閲覧回数
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 件の賞賛
返信