• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 84 subscribers
  • Views 1064 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

[TMSF320F28388D] Connectivity Manager(CM) Ethernet communication issue

[TMSF320F28388D] Connectivity Manager(CM) Ethernet communication issue2

Seung Seop Shin
Prodigy 80 points


Related post :

Hello,.


I have tested the CM project based 'ethernet_ex2_phy_loopback.c'


I insert my rx function code to 'Ethernet_receivePacketCallback()' in ethernet.c(in driverlib_cm directory).


When my rx function(Ethernet_receivePacketCallback) is called, a packet in data buffer(in Ethernet_Pkt_Desc *pPacket) is inserted to my rx queue. and then dequeue the packet data in main loop(in main entry function) and send response packet data for replying using 'Ethernet_sendPacket()' in ethernet.c.


The logic is working in 1:1 communication(Windows PC : EMAC). however in 1:N communication(ICMP, 3 UDP clients : EMAC), N clients are received an another response packet not the response packet requested. especially when communication of a specific client is stopped, this situation is occured.

Ex) When ICMP process sends packet 1, packet2 and packet3, UDP process1 sends packet 4 and UDP process2 sends packet 5, the ICMP process receives response packet for packet2 and then receives reponse packet for packet 1, 3. the UDP process1 receives reponse packet for packet5 and the UDP process2 receives reponse packet for packet4.


How can I send the reponse packet in the order of request in 1: N communication? Is there any funtions elss I need to know except 'Ethernet_sendPacket' in ethernet.c?

+) in 1:N communication(ICMP, UDP), Rx_FIFO_Overflow_Packets register value may be over 0 

  • 0
    TI__Expert 4200 points

    Hi,

    The expert is on holiday and will provide the answer once he gets back to work.

  • 0
    TI__Expert 5391 points

    Hi,

    Seung Seop Shin said:
    When my rx function(Ethernet_receivePacketCallback) is called, a packet in data buffer(in Ethernet_Pkt_Desc *pPacket) is inserted to my rx queue. and then dequeue the packet data in main loop(in main entry function) and send response packet data for replying using 'Ethernet_sendPacket()' in ethernet.c.

    The driver dequeues the packet in Rx ISR handling and calls the Ethernet_receivePackaetCallback. can you explain the need for dequeue the packet in main loop.

    Seung Seop Shin said:
    The logic is working in 1:1 communication(Windows PC : EMAC). however in 1:N communication(ICMP, 3 UDP clients : EMAC), N clients are received an another response packet not the response packet requested. especially when communication of a specific client is stopped, this situation is occured.

    Thanks for explaining the scenario. But I need a wireshark trace to understand that further. will it be possible to capture it in wireshark and send the trace for further analysis

    Seung Seop Shin said:
    Ex) When ICMP process sends packet 1, packet2 and packet3, UDP process1 sends packet 4 and UDP process2 sends packet 5, the ICMP process receives response packet for packet2 and then receives reponse packet for packet 1, 3. the UDP process1 receives reponse packet for packet5 and the UDP process2 receives reponse packet for packet4.

     

    The driver does not differentiate the processes. It calls receive callback for the way the packets are received. Are you running using some Real Time Operating system or it is no operating system model? Are you running any IP stack to handle this routing to different applications like ICMP/UDP/etc? As I asked above a wireshark trace will help to debug this further.

    Regards,

    Sudharsanan

  • 0 in reply to Sudharsanan
    Prodigy 80 points

    Hello,

    Thank you for your answer.

    1. The driver dequeues the packet in Rx ISR handling and calls the Ethernet_receivePackaetCallback. can you explain the need for dequeue the packet in main loop.

    => Please check to the image.

    2. But I need a wireshark trace to understand that further. will it be possible to capture it in wireshark and send the trace for further analysis

    => Below the wireshark log text.

    the Rx_FIFO_Overflow_Packets count is over 0 after 10216 sequence icmp packet(above the scenario, the registor value is 20).

    3. The driver does not differentiate the processes. It calls receive callback for the way the packets are received. Are you running using some Real Time Operating system or it is no operating system model? Are you running any IP stack to handle this routing to different applications like ICMP/UDP/etc? As I asked above a wireshark trace will help to debug this further.

    => I'm not running using RTOS but running no operating system model. I'm not using different applications in CM program. just one apllication.

  • 0 in reply to Seung Seop Shin
    TI__Expert 5391 points

    Hi,

    Thanks for additional details. Please find some followup questions. 

    Seung Seop Shin said:
    => Please check to the image.

    Can you clarify if you are doing any explicit dequeue of the packet in the main loop apart from the dequeue done at the driver. The driver does dequeue and then calls the callback routine. 

    Seung Seop Shin said:
    the Rx_FIFO_Overflow_Packets count is over 0 after 10216 sequence icmp packet(above the scenario, the registor value is 20).

    Thanks for this detail souds like the received packets are not dequeued which results in this scenario. Can you please let me know if the application is still running or hits a fault and aborted? Does the Ethernet_rxInterruptCount variable increase post this scenario.

    Seung Seop Shin said:
    I'm not running using RTOS but running no operating system model. I'm not using different applications in CM program. just one apllication.

    Since multiple kind of traffic exists. have you tried to isolate if this happens only when running UDP with ICMP traffic?

    Does this happen just after the UDP packets are started? or in between? It's bit trickier to get the point of failure of this application scenario.

    Regards,

    Sudharsanan

  • 0 in reply to Sudharsanan
    TI__Expert 5391 points

    Hi,

    Did you get a chance to look into it further? any updates?

    Regards,

    Sudharsanan