66AK2H14: RXDMAOVERRUNS

Bruno B

Expert 1290 points

Part Number: 66AK2H14

Tool/software:

Hi Community members,

Inside the SPRUHJ5 document we can find the "RXDMAOVERRUNS" register from the statistic module.

They are located at offset 0x188C for Lane 0 and 0x1A8C for lane 1

The document only "explains" that the value here should be 0.

What can be an explanation of getting a non 0 value ?
What to do in that case ?

With best regards,

Bruno

1 month ago

0 Betsy Varughese 1 month ago

TI__Expert 4190 points

Hi,

I will check and update you within a day.

Regards,

Betsy Varughese

0 Betsy Varughese 1 month ago in reply to Betsy Varughese

TI__Expert 4190 points

Hi Bruno,

Yes , The details are correct. The "RXDMAOVERRUNS" is a read only counter that should be normally "0". There is no direct examples available in the SDK.

RXDMAOVERRUNS > 0, some incoming data received was dropped before being stored in the memory.

RX DMA with very few descriptors trigger this condition.

Regards,

Betsy Varughese

0 Bruno B 1 month ago in reply to Betsy Varughese

Expert 1290 points

Hi Betsy

Thak you for your reply.

In the case that happens on our board, I can see that once the RXDMAOVERRUNS has been incremented from 0 to 1 (or greater) (for some reason that is ot identified so far) , it becomes impossible to receive any more data. The switch input (port1) seems to be locked. RxGOODFRAMEs counter continues incrementing with nothing forwarded to port0

Is there a way to re-initialise the switch , or to de-lock the process ?

with best regards

Bruno

0 Betsy Varughese 1 month ago in reply to Bruno B

TI__Expert 4190 points

Hi Bruno,

Referring to the previous E2E post : https://e2e.ti.com/support/processors-group/processors/f/processors-forum/367192/qmss-gets-stuck-and-does-not-return-descriptor-to-tx-completion-queue

Please let me know if that was helpful to you.

Regards,

Betsy Varughese

0 Bruno B 1 month ago in reply to Betsy Varughese

Expert 1290 points

Hi Betsy

I am not sure the described problem is the same.

Our problem is detected on port2 reception

port 2 link is not at all extensively used. (and port 1 is unused)

There is a big time delay between operational packets being received.

But since the port2 also receives asynchronous ARP¨broadcast packets, we can imagine that an operational packet be contiguous to ARP packet. Each of them is supposed to generate an interruption to processing core but this is not even the case. NO interrupt at all is generated

As if ingress packets where dropped as you suggested before.

The question remains : how to recover from that state which seems to be stuck forever?

regards,

Bruno

0 Betsy Varughese 1 month ago in reply to Bruno B

TI__Expert 4190 points

Hi Bruno,

Bruno B said:
The question remains : how to recover from that state which seems to be stuck forever?

I found a thread related to your question but its "tms570lc43x". Could you please confirm if it meets your needs.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1541797/tms570lc4357-support-required-for-handling-rxsofoverruns-and-rxdmaoverruns-on-tms570lc43x?tisearch=e2e-sitesearch&keymatch=RXDMAOVERRUNS#

Reference Document: https://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf

I wasn't able to find any other documents describing the scenario.

Regards,

Betsy Varughese

Processors

Processors forum

66AK2H14: RXDMAOVERRUNS