Stoppage of reception of ethernet messages via Gmac0 after some time

[winstonlewis]

Hello,

We are using a custom board and we are using Gmac0 controller on M core.

We are able to establish communication with the remote node using Gmac0 controller during this time the receive interrupt, GMAC0_CH0_RX_IRQHandler is hitting fine. But after a while the host stops acknowledging to the messages sent by remote node and when we check, at this time the receive interrupt, GMAC0_CH0_RX_IRQHandler is not hitting and the communication is stopping as the host stopped acknowledging to the messages sent by remote node.

Attaching the snippet of canoe trace for reference.

We tried the same activity for transmission via host and we see that the transmission is not stopping and is working fine.

Could you please support us to resolve the issue with the Gmac.

Regards,

Winston Lewis

[alejandro_e]

Hello @winstonlewis,

Thanks for reaching out to us. Regarding your problem, please provide the following information so I am able to correctly help you:

•  Which core are you using to handle the GMAC communication, A53 or M7?
• Which BSP version are you using?
• Which RTD version are you using?
• In your tests, have you seen the 'stoppage in communication' occur always around the same time?
• Does the 'stoppage in communication' occur after a certain message or type of message or is it independent of the content shared in the network?
• Do other features of the board/chip stop at the same time or in the same conditions as GMAC?
• Did you noticed this issue while actively developing around the GMAC module or did you encounter this problem while working on another module?
• Please reshare the pictures you mentioned, I cannot currently access them.

Thanks in advance for the information. 

[winstonlewis]

Hello, 

Thanks for the response, 

• Which core are you using to handle the GMAC communication, A53 or M7?
• We are using M7 core to handle GMAC.
• Which BSP version are you using?
• We are using BSP version 43 on A core.
• Which RTD version are you using?
• We are using RTD_4.4_4.0.2.
• In your tests, have you seen the 'stoppage in communication' occur always around the same time?
• Yes the communication stops at fixed time, in our case we have only configured Rx messages to the ECU when we start canoe and start the communication it stops at fixed time.
• Does the 'stoppage in communication' occur after a certain message or type of message or is it independent of the content shared in the network?
• When we start canoe, establish communication and start sending TCP frames, after a while the communication stops, after that even if we send ETH frame the Rx interrupt does not hit. But if we keep sending ETH frames via packet builder without actually starting the communication with simulated node, the Rx interrupt hits continuously.
• Do other features of the board/chip stop at the same time or in the same conditions as GMAC?
• Other features on the board would work fine when GMAC stops working, CAN messages are flowing fine. 
• Did you noticed this issue while actively developing around the GMAC module or did you encounter this problem while working on another module?
• This issue we observed while developing GMAC module.
• Please reshare the pictures you mentioned, I cannot currently access them.
• Re sharing the canoe snapshot. The image that I have shared shows simulated node retransmitting, but the ECU does not acknowledge to any messages sent by simulated node.

Regards,

Winston Lewis

[alejandro_e]

Hello @winstonlewis,

Thanks for all the information, I need some time to review all I need to give you proper feedback. For now, can you confirm if the problem occurs always around 3-4s? That is what I understood from the image you shared.

Thanks.

[winstonlewis]

Hello,

Thanks for the response,

The time where the messages stop is not the same.

In our case we have 7 PDU's being sent to the ECU

• If we transmit a PDU with a payload of 21 bytes, the ECU stops responding at 6.03 seconds(attached snapshot 1).
• If we transmit a PDU with a payload of 4960 bytes, the ECU stops responding at 0.60 seconds(attached snapshot 2).
• If we transmit all the PDU's then the ECU stops responding at 1.32 seconds(attached snapshot 3).

Regards,

Winston Lewis

[alejandro_e]

Hello @winstonlewis,

Thanks for the information, I have not understood that the problem was related to the payload size until now. Please helo me providing a memory dump of all the GMAC registers after the error has happened, this is from 0x4033_C000 to 0x4033_D368, this will help me get an exact idea of the state of the module at the time of the error.

Thanks.

[winstonlewis]

Hello,

Sorry for the delayed response,

Attaching the binary file of the register dump after the error condition.

• File GMAC contains the register dump from 0x4033_C000 to 0x4033_D368.

In the binary file, the address 0x00 corresponds to 0x4033_C000, when you open the file please change the start address to 0x4033_C000.

Regards,

Winston Lewis

[alejandro_e]

Hello @winstonlewis,

Thanks for the information. Checking the dump I found the following  register with value 5:

If you are using the RTD API, can you share the values in last argument of Gmac_Ip_ReadFrame(), it should be a pointer to a struct of type Gmac_Ip_RxInfoType:

this will help me confirm that the problem is an overflow of packets.

Thanks.

[winstonlewis]

Hello,

Thanks for the response,

Sharing the values of the structure pointer Gmac_Ip_RxInfoType Info (attaching the snippet), we do not see any error.

Also the register, 0xC7D4 is not set, it is 0x00 (We tried multiple times still the register was not set). Attaching the snippet for your reference.

Regards,

Winston Lewis

[alejandro_e]

Hello @winstonlewis,

Thanks for the information. Just to avoid any confusion, when you say that you do not see any error in the struct, this is after being able to reproduce the problem, correct?

Also, by '0xC7D4 is not set' you mean the full address 0x4033_C7D4 correct?

This is, either the memory dump you shared was taken in a different situation in which the register did have a value or either the tool or my analysis introduce an error. If you analyze the memory dump you shared before, do you come to the same conclusion as I did?

Thanks in advance.

[winstonlewis]

Hello,

Thanks for the response,

The issue was with the Rx FIFO overflow, the total buffer length we configured was crossing 20KB (1536 bytes X 16 nos.).

When we reduced the size to less than 20KB it worked.

Thanks for the support.

Regards,

Winston Lewis

[alejandro_e]

Hello @winstonlewis,

I am glad to know you were able to solve your problem.

Thanks for letting me know.

If you have more problems in the future please do not hesitate in creating a new post! 

Best regards.