• State Answer Suggested
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 769 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.

Failed to send small packet on Pa_emacexample (6678)

Sam Lee
Prodigy 150 points

Hello,

I'm using Pa_emacexample to verify 6678 Ethernet interfaces,  EVM SGMII1 is using RJ45 connect to PC. Everything runs okay, packets can send to PC, and PC also can send packet to EVM at the same time.

I construct a packet as follows, it can seed out to PC, also wireshark can capture this packet.

UInt8 pktMatch[] = {
0x54, 0xee, 0x75, 0x41, 0xc8, 0x69, /* Src MAC */
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, /* Dest MAC */
0x08, 0x06, /* Ethertype = IPv4 */
0x45, 0x00, 0x00, 0x6c, /* IP version, services, total length */
0x00, 0x00, 0x00, 0x00, /* IP ID, flags, fragment offset */
0x05, 0x11, 0x2a, 0x25, /* IP ttl, protocol (UDP), header checksum */
0xc0, 0xa8, 0x05, 0x02, /* Source IP address */
0xc0, 0xa8, 0x05, 0x0a, /* Destination IP address */
0x12, 0x34, 0x56, 0x78, /* UDP source port, dest port */
0x00, 0x58, 0x1d, 0x18, /* UDP len, UDP checksum */
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,
0x32, 0x33, 0x32, 0x33,

0x32, 0x33, 0x32, 0x33};

However, if I replace it with a small packet as below,

UInt8 pktMatch[] = {
0x54, 0xee, 0x75, 0x41, 0xc8, 0x69, /* Src MAC */
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, /* Dest MAC */
0x08, 0x06, /* Ethertype = IPv4 */
0x45, 0x00, 0x00, 0x6c, /* IP version, services, total length */
0x00, 0x00, 0x00, 0x00, /* IP ID, flags, fragment offset */
0x05, 0x11, 0x2a, 0x25, /* IP ttl, protocol (UDP), header checksum */
0xc0, 0xa8, 0x05, 0x02, /* Source IP address */
0xc0, 0xa8, 0x05, 0x0a, /* Destination IP address */
0x12, 0x34, 0x56, 0x78, /* UDP source port, dest port */
0x00, 0x58, 0x1d, 0x18, /* UDP len, UDP checksum */

0x32, 0x33, 0x32, 0x33};

PC can't receive it again.

Could you help to check what's wrong about  the setting?

Thank you!

Regards,
Sam.

  • 0
    TI__Guru 65405 points
    Hi Sam,

    I've forwarded this to the ethernet experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • 0
    Mastermind 6650 points
    Maybe it is a problem with packet len: the smallest Ethernet frame managed by C6678 Ethernet is 64 bytes. Try with "Uint8 pktMatch[64]" and let the compiler fill with zeros (no need to change the header data).

    Note that WireShark will be a bit confused and will signal an FSC error. To remove this you have to calculate the FCS by yourself (only for message<60 bytes). Anyway the message is delivered and processed by the PC without problems.
  • 0 in reply to Alberto Chessa
    Prodigy 150 points
    Thank you, Alberto. As your said, ARP/ping packet is 42 bytes, I have to pad the send out packet to 60 bytes.
    Then, it can receive and send packet.
  • 0 in reply to Alberto Chessa
    Prodigy 150 points

    Hello Alberto,

    Actually,  I debug the TCP/IP stack code, it was found that TCP server daemon(run on 6678) sent a SYN + ACK packet to PC client, but the PC could not receive the handshake packet. The packet was 60 bytes, less than the minimum length (64 bytes) of the Ethernet,  and 6678 EMAC device did not set the short packet fill function, resulting in PC can not receive the short packet.

    Do you know any method to set 6678 EMAC small packet auto zero filled function?

    Thank you!

    Regards,
    Sam.

  • 0 in reply to Sam Lee
    Mastermind 6650 points
    Hello,

    Sorry as fas as I know There is no way to force the device to round up to 64 bytes the packets.

    I don't use NDK, so I do it by SW in my low level driver. Note that is not necessary to fill with zero, you can left random value in the exceeding bytes. You have only to round up the buffer size used in the push in the TX message queue.

    I suppose you are not using NDK too, since I think it already does that for You
  • 0 in reply to Alberto Chessa
    Prodigy 150 points
    Hello Alberto,

    Yes, I'm not using NDK. Could you please share me this piece of code for reference ? Thank you!
  • 0 in reply to Sam Lee
    Mastermind 6650 points

    Well, my code has a lot of details pertinent to my custom driver.

    I try to extract the essential (qm* types and macro are from some TI examples):

    int send_packet(const void* buffer, unsigned int num_bytes)
{
  qmHostDesc_t* hd;=hwQmQueuePop(DEVICE_QM_TX_Q);

  if (num_bytes < 64)
  {    
    //Here fix the minimum len, assuming there is some extra readable space. As you can see, it is very simple
    //Don't care what there is in the trailing bytes
    num_bytes = 64;
  }

  QM_DESC_DESCINFO_SET_PKT_LEN(hd->descInfo, num_bytes);  //use fixed size as descriptor packer len

  //Fill the rest of the descriptor
  hd->buffLen       = num_bytes;
  hd->origBufferLen = num_bytes;
  hd->buffPtr     = eth_drv_deviceLocalAddrToGlobal((UINT32)buffer);
  hd->origBuffPtr = eth_drv_deviceLocalAddrToGlobal((UINT32)buffer);

  bsp_cache_data_flush(buffer, num_bytes);  //I flush the buffer only, since the descriptors are in non-cacheable memory

  hwQmQueuePush (hd, DEVICE_QM_ETH_TX_Q, QM_DESC_SIZE_BYTES);  //Put the descriptor and let the message go
}