• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 1235 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/PROCESSOR-SDK-DRA7X: Emac driver - mixed ValidLen and buffer

Jakub Mielczarek2
Intellectual 880 points
Part Number: PROCESSOR-SDK-DRA7X

Tool/software: TI-RTOS

Hello,

I am using pdk_dra7xx_1_0_5 and binary released emac driver pdk_dra7xx_1_0_5/packages/ti/drv/emac/lib/dra75x/m4/release on IPU1_1.

My setup is gPTP and AVTP (audio) between amp and a PC running OpenAvnu AVB stack. PC is the gPTP grandmaster and talker for the AVTP stream. In the wireshark all packets sent by the PC look good.
However, sometimes it happens that the gPTP packet (verified that it's content is correct) is delivered by the emac driver (by rx_pkt_cb callback) with ValidLen (field of EMAC_PKT_DESC_T struct) set to 910, which is the length of my AVTP packet. Is this a known issue? Could it be an issue with emac driver?

Regards,

Jakub

  • 0
    TI__Mastermind 42515 points
    Hi Jakub,

    I have forwarded your question to pdk experts.

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    Intellectual 880 points

    Hi Yordan,

    Thank you.

    I narrowed down the problem to just gptp. When packet descriptor provided in rx_pkt_cb by the driver is freed (pushed back to free RX queue of my application) in the rx callback after being copied to application buffer, then I don't see any issues with packet reception. When I store the descriptor and do not free it in the rx callback, but later on from a different task, then the issue with reception occurs. It looks as if the packet length is correct, but the buffer pointed to by the descriptor is from the next frame (frame delivered out of order).

    Regards,

    Jakub

  • 0 in reply to Jakub Mielczarek2
    Intellectual 880 points

    It seems there is a bug in EMAC_rxPacket() functions in emac/src/v4/emac_drv_v4.c which is the root cause of this issue.

    This function tries to allocate a new packet descriptor from the application. If application has no free descriptors (EMAC_ALLOC_PKT returns NULL), then the recently notified (via rx callback) packet descriptor to the application is reused.

    IMHO, the driver should be prepared for such a situation that no more free descriptors are available from the application (it may happen so, when packet descriptors are not freed immediately in rx callback, but some later time after processing in e.g. another task).

    The driver should handle refilling the internal descriptor queues.

  • 0 in reply to Jakub Mielczarek2
    TI__Expert 5725 points

    Hi Jakub,

    In following up from the other related thread, the following workaround has been suggested:

    "re-tune the number of buffers its maintaining in the system (these are at the software level, not hardware RX buffer descriptors). This is to ensure that when a packet is received, and the LLD attempts to replenish the buffer pointer field of the returned Rx buffer descriptor, no failure occurs. The buffer has to come from the application ie the application owns the memory where the packet is to be copied by the DMA. This cant be handled by the LLD."

    This is a driver design limitation and is being tracked by PRSDK-2810, and the plan is to have this fixed for Processor SDK RTOS 4.1 release.

    Thanks,

    Stephen