Window10 IoT Enterprise BSP1.5.0 EQOS interrupt issue

[okuda]

Hello,

On the affected board, the Phy controller has been changed to mxl86110I.
There is a problem with the EQOS driver interrupt processing for Windows 10 IoT Enterprise with BSP 1.5.0.

There is no problem with 10M/100M connections.
Even with a 1G connection, communication itself is possible without any problems.

However, when you unplug the cable, an immediate interrupt occurs, Windows locks up, and eventually the system watchdog interrupt occurs, causing a reboot.

After investigating, we found that a MAC_INTERRUPT had occurred, and the EQOS ISR processing was set to not process anything other than DMA interrupts, as shown in the source code below.
As a result, the MAC_INTERRUPT interrupt is not cleared and continues to occur.

_Use_decl_annotations_
BOOLEAN EnetIsr(NDIS_HANDLE MiniportInterruptContext, PBOOLEAN QueueDefaultInterruptDpc, PULONG TargetProcessors)
{
PMP_ADAPTER pAdapter = (PMP_ADAPTER)MiniportInterruptContext;
UNREFERENCED_PARAMETER(TargetProcessors);
DBG_ENET_DEV_ISR_METHOD_BEG();
if (pAdapter->ENETRegBase->DMA_CH[0].DMA_CHX_INT_EN.R != 0U) {
pAdapter->ENETRegBase->DMA_CH[0].DMA_CHX_INT_EN.R = 0x00; // Disable all ENET interrupts. (EnetIsr will not be called again until interrupts are enabled in EnetDpc)
pAdapter->DpcQueued = TRUE; // Remember that EnetDpc is queued
*QueueDefaultInterruptDpc = TRUE; // Schedule EnetDpc on the current CPU to complete the operation
__analysis_assume(*TargetProcessors = 0); // If QueueDefaultInterruptDpc value is set to TRUE, NDIS ignores the value of the TargetProcessors parameter. Suppress analyser warning "Returning uninitialized memory".
} else {
*QueueDefaultInterruptDpc = FALSE; // Do not schedule Dpc
*TargetProcessors = 0;
DBG_ENET_DEV_ISR_PRINT_WARNING("Spurious Interrupt.");
}
DBG_ENET_DEV_ISR_METHOD_END();
return *QueueDefaultInterruptDpc;
}

The issue can be resolved by adding a process to the else side of the above if statement that clears the bit that is causing MAC_INTERRUPT.

What we don't understand is why MAC_INTERRUPT occurs.

In the following code for EnetQos_Init, MAC_INTERRUPT_ENABLE is set to 0.

// Disable all interrupts
pAdapter->ENETRegBase->DMA_CH[0].DMA_CHX_INT_EN.R = 0U;
pAdapter->ENETRegBase->MAC_INTERRUPT_ENABLE.R = 0U;

In the SoC reference manual (i.MX 8M Plus Applications Processor Reference Manual, Rev. 2, 02/2024), I confirmed that setting this to 0 disables interrupts.

Below are some questions.

1.Is this a typo in the SoC reference manual?
2.Is this a problem with the SoC's EQOS interrupt?
3.Is the process of disabling MAC_INTERRUPT insufficient?

In BSP1.5.1, we confirmed that five MASK registers are set to disable interrupts other than DMA.
Therefore, we have reflected the differences in the EQOS driver source from BSP1.5.0 to BSP1.5.1.
(We have confirmed that if the BSP1.5.1 fix is ​​not applied, a similar phenomenon will occur when the communication load is high.)

Best regards.
Koji Okuda

[george]

Okuda-san,

Please check the difference in bit fields in the two registers below.

Then checking the explanation of the bit fields with differences will make your question clear.

Thanks,
George

[okuda]

Dear George,

Thank you for your reply.
However, I didn't quite understand the meaning of your answer.

The reasons why I couldn't understand it are as follows.

The following source was added to the else side of the if statement in EnetIsr.

DbgPrintEx(DPFLTR_IHVVIDEO_ID, DPFLTR_WARNING_LEVEL, "Spurious Interrupt\n");
RegVal = pAdapter->ENETRegBase->MAC_INTERRUPT_ENABLE.R;
DbgPrintEx(DPFLTR_IHVVIDEO_ID, DPFLTR_WARNING_LEVEL, "MAC_INTERRUPT_ENABLE 0x%08x\n", RegVal);
RegVal = pAdapter->ENETRegBase->MAC_INTERRUPT_STATUS.R;
DbgPrintEx(DPFLTR_IHVVIDEO_ID, DPFLTR_WARNING_LEVEL, "MAC_INTERRUPT_STATUS 0x%08x\n", RegVal);

The log obtained after unplugging the Ethernet cable is as follows.

Spurious Interrupt
MAC_INTERRUPT_ENABLE 0x00000000
MAC_INTERRUPT_STATUS 0x00040021

The attached image shows the two MAC_INTERRUPT registers pasted from the reference manual.

The bit that is set to 1 from the log information is the bit in the red frame in the attached image.

This shows that the bits in the two registers match.

Please provide more details about your answer, including examples

Best regards.
Koji Okuda

 

[JosephAtNXP]

Hi,

Thank you for your interest in NXP Semiconductor products,

Seems like this issue described here.

A workaround would be (as the post says) clearing LPIIS bit.

Then, try to move to disable LPI interrupt.

Regards

[okuda]

Hi NXP engineers,

Are there any NXP engineers who can answer this question?

Depending on the answer from NXP engineers, we may need to make the Phy controller on our development board equivalent to the Phy controller implemented on the IMX8mp NXP reference board.

Best regards.
Koji Okuda

[okuda]

Dear Joseph,

The attached log file was obtained using windbg which was remotely connected to the actual device.

The locking phenomenon was confirmed by unplugging and plugging back in the Ethernet cable using the EQOS driver, which had a process added to clear the problematic interrupt.

The number of times the cable has been plugged in and out is not exact, but it is about 130 to 150 times.

EnetDpc->MpHandleTxInterrupt->RemoveTailList->FatalListEntryError->RtlFailFast is logged.

As a result, the problem could not be solved simply by clearing the interrupt.

We think it is necessary to find out why the disabled interrupt occurs and whether there is a way to completely disable interrupts.

Best regards.
Koji Okuda

[okuda]

Dear Joseph,

Thank you for your quick response.
We realized that other people besides us were experiencing the same thing.
We have confirmed that if you perform a clear process within EnetISR, EnetISR will no longer be called continuously.

However, We don't understand why this interrupt occurs even though LPIIE in MAC_INTERRUPT_ENABLE is set to 0.
(The log from the previous post shows that all bits of MAC_INTERRUPT_ENABLE are set to 0.)

We believe that the EQOS driver for your Windows 10 IoT Enterprise BSP1.5.0 and BSP1.5.1 is designed not to expect anything other than DMA interrupts.
Therefore, we would like to ensure that no interrupts other than DMA occur at all.

Based on the above, we would like to ask the following questions.

1.What kind of processing should be done to completely disable the interrupts that can be specified with MAC_INTERRUPT_ENABLE?
(Is it possible to simply disable it by setting each bit of MAC_INTERRUPT_ENABLE to 0?)

2.Is this issue a problem with the SoC's EQOS?
(There is no description in the errata document for IMX8MP_1P33A. Rev. 2.1 — 2 October 2024)

3.Could you please provide a sample source code for the answer you gave, "try to move to disable LPI interrupt"?
(We will incorporate the sample source code and verify the phenomenon.)

Best regards.
Koji Okuda

[JosephAtNXP]

Hi,

I've asked for the patches,

Regards,

[okuda]

Dear Joseph,

Thank you for sending Kudos.

If you can answer the following questions at this time, please do so:

1.When will the patch be available?

2.What process will that patch change?

Best regards.
Koji Okuda

[okuda]

Dear Joseph,

Thank you for sending Kudos.

If possible, please answer the following questions at this time:

１．When will the patch be available?

２．What kind of fix will that patch be?

Best regards.
Koji Okuda

[okuda]

Dear Joseph,

Thank you for your reply.

Is it correct to assume that you would provide a patch?

If I understand correctly, I would be grateful for your patch.

Best regards.
Koji Okuda