Why ETH Driver of MCAL4.3.1 has an input parameter at interrupt handler?

[lijing59]

I use DEVKIT-MPC5748G development board to study AUTOSAR MCAL.

When I use MCAL 4.3.1 to develop Ethernet driver, I find the receivement interrupt handler of Ethernet  has an input parameter,which make me confused.

Because I don't know where this parameter comes from and what determines the value of this parameter.

Unfortunately,when I use PC to send an Ethernet frame to the board,this parameter of receivement interrupt handler always be 24.That is wrong, because the value of parameter can only be evaluated from 1 to 3。

When interrupt handler receive that wrong value, the function can't handle so that the interrupt flag bit cannot be cleared.

I suspect there is something wrong with the register configuration, but I don't know how to locate the problem. I hope someone can answer my question.

Eth_RxIrqHdlr_0 is Ethernet receivement interrupt handler, u8QueueIdx is the input parameter.

[namnguyenviet]

Hi,

The implementation of queue index as parameter in interrupt handler is a part of the addition of ETH Queue/FIFO concept, which is available from ASR 4.3. Particularly, with MCAL ETH ASR 4.0 driver, you can only use one FIFO (i.e., one Ring/Class, as per MPC574xG specification) for each ETH controller, while with MCAL ETH ASR 4.3, you can specify which FIFO or Queue you want to use for transmission.

So far there would be no wrong with the register configuration. Just a new kind of implementation which is based on an addition of ASR specification, it could be a little confuse with the one who has been familiar with ASR 4.0

[lijing59]

Thanks for your explanation。

Now I understand why there are input parameters。 But when I received Ethernet frames in interrupt mode，the input parameter was an incorrect value。Should I check the register configuration or change the interrupt function as you mentioned above？

[namnguyenviet]

I think the reason for unexpected input parameter is due to the fact that you haven't pass any input value to Eth_RxIrqHdlr_0(queueIdx), the input value will be taken from r3 without any modification (you can check if r3 value is 24 when debugging). So to be sure that the input parameter is correct, you can use my recommendation of interrupt functions.

[lijing59]

When I change the interrupt function as you recommendation, the Ethernet frame can be receive successfully. I'm going to check the values of r3 to see if there are any errors。 Thank you for your patient reply。

[namnguyenviet]

I'd like to clarify: actually r3 will store the first argument when function is called. Perhaps when Eth_RxIrqHdlr_0() is called without passing the input value, r3 is not modified and still keep the old value from previous modification, hence interrupt handler is called with an incorrect input value.

Glad to hear that your application is worked :smileyhappy:

[namnguyenviet]

Hi,

Here is the current approach for ETH interrupt handling:

1. Declare ISR function corresponding with ETH interrupt sources for RX Frame Done. These ISR functions are named as these interrupt features. For instance:

ETH_ISR_RX as ENET0 MAC0 receive done - ISR source 211

ETH_ISR_RX1 as ENET0 reveive frame_1 done - ISR source 215

ETH_ISR_RX2 as ENET0 reveive frame_2 done - ISR source 217

2. Define Eth_Rx_interrupt_handler as below:

FUNC(void, ETHIF_CODE) Eth_RX_interrupt_handler(uint8 queueIdx)
{
    Eth_RxIrqHdlr_0(queueIdx);
}

3. Implement each ISR as below:

INTERRUPT_FUNC ISR(ETH_ISR_RX)
{
    /* Run test interrupt routine */
    Eth_RX_interrupt_handler(0U);
}

INTERRUPT_FUNC ISR(ETH_ISR_RX1)
{
    /* Run test interrupt routine */
    Eth_RX_interrupt_handler(1U);
}

INTERRUPT_FUNC ISR(ETH_ISR_RX2)
{
    /* Run test interrupt routine */
    Eth_RX_interrupt_handler(2U);
}

These above steps will help you to determine the queue index to pass to the ISR functions.

[lijing59]

Thanks for your answer.

I know how to handle this interrupt handler to keep it running。However, what make me confused is why did the MCAL development team of NXP change the interrup handler. Because I found that this interrupt handler in version of 4.0 has no input parameter. I still suspect there is something wrong with the register configuration. So I don't think changing the interrupt function is the fundamental solution。