question about ENET_Ptp1588IRQHandler() function in SDK in RT105x

[mastupristi]

I enabled the input capture of the IEEE1588, with the associated interrupt (ENET_1588_Timer_IRQn).
The priority is higher (1) than the ENET_IRQn interrupt (6) which uses lwip calls, thus FreeRTOS.
Both interrupts though have the callback s_enetTsIsr, which is populated with ENET_TimeStampIRQHandler(). It, among other things, increments the seconds counter. It can happen that the ENET_1588_Timer_IRQn interrupt can preempt the ENET_IRQn interrupt. If this happens at the point indicated below, it happens that there is erroneously a double increment of seconds.

void ENET_TimeStampIRQHandler(ENET_Type *base, enet_handle_t *handle)
{
    assert(handle != NULL);

    /* Check if the PTP time stamp interrupt happen. */
    if (0U != ((uint32_t)kENET_TsTimerInterrupt & base->EIR))
    {
	/* <--- if highr priority irq is triggered here we have a double increment of seconds */
        /* Clear the time stamp interrupt. */
        base->EIR = (uint32_t)kENET_TsTimerInterrupt;

        /* Increase timer second counter. */
        handle->msTimerSecond++;

My focus is on ENET_Ptp1588IRQHandler(), where I find these lines:

#if defined(ENET_ENHANCEDBUFFERDESCRIPTOR_MODE) && ENET_ENHANCEDBUFFERDESCRIPTOR_MODE
    /* In some platforms, the 1588 event uses same irq with timestamp event. */
    if ((s_enetTsIrqId[instance] == s_enet1588TimerIrqId[instance]) && (s_enetTsIrqId[instance] != NotAvail_IRQn))
    {

I wonder if RT105x is one of these platforms. In other words, assuming that the occasional double seconds increment is a bug, does it come from the fact that inside the ENET_Ptp1588IRQHandler() function shouldn't be called the s_enetTsIsr callback, or from the fact that the TimeStampIRQHandler() function is not safe for reentrant?

best regards
Max

[Hui_Ma]

Hi Max,

This issue was confirmed and SDK software team is working to fix this issue will update related code at following released SDK software.

The issue is that in RT1050, the defination for the ENET_TimeStampIRQHandler should be ENET_IRQn instead of ENET_1588_Timer_IRQn.

Thank you for the attention.

Mike

[mastupristi]

Hello Mike,

The issue is that in RT1050, the defination for the ENET_TimeStampIRQHandler should be ENET_IRQn instead of ENET_1588_Timer_IRQn.

I can't figure out what you mean by "the definition for the ENET_TimeStampIRQHandler() should be ENET_IRQn instead of ENET_1588_Timer_IRQn"

I believe the offending line is this one:

    /* Set the IRQ handler when the interrupt is enabled. */
    ENET_SetTsISRHandler(base, ENET_TimeStampIRQHandler); // <--------
    ENET_SetTxISRHandler(base, ENET_TransmitIRQHandler);

But I didn't understand how it should be modified (or removed?).

best regards

Max

[Hui_Ma]

Hi Max,

Please refer my feedback at case: 00458118. Thanks.

This issue would be fixed at SDK V2.12.1 release. 

best regards,

Mike

[mastupristi]

Hi @Hui_Ma 

almost two years have passed this report. Now the SDK is at version 2.15.000.

However, that portion of the code I had indicated hasn't changed at all

https://github.com/nxp-mcuxpresso/mcux-sdk/blob/MCUX_2.10.0/drivers/enet/fsl_enet.c#L3556
https://github.com/nxp-mcuxpresso/mcux-sdk/blob/MCUX_2.15.000/drivers/enet/fsl_enet.c#L3171

That would disprove what you stated. By the way, the MCUX_2.12.1 release was never released

So you confirm that the bug is still there? If not, can you explain how it was corrected?

best regards

Max

[Hui_Ma]

Hi Max,

I had posted software team feedback info about case: 00458118.

The macro definition of ENET_Ts_IRQS is incorrect at SDK V2.12.0.

That error definition was fixed at SDK V2.12.1.

Software team already fixed this macro definition issue at SDK V2.12.1.

Thanks for the attention.

Mike

[Hui_Ma]

Hi Max,

Due to I am on business trip and will check this software issue later.

Thanks for the understanding.

best regards,

Mike

[Hui_Ma]

Hi Max,

I am sorry for the later reply.

I need to check with i.MX RT product team about this question.

I will update here when there with any feedback. Thanks.

best regards,

Mike