• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 2030 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.

TMS320F28388D: Target does not broadcast ARP request queued by lwIP without a delay

MananMishra
Prodigy 65 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hi,

I am running a UDP application on the CM core based on lwIP 2.1.2 shipped in C2000Ware 2.00.00.02. My network setup is that the target and my PC are both connected to a router and I am assigning static IP for both.

Now when I do a UDP broadcast from the target, I am able to receive it on my PC. However, when I try to unicast the UDP message to the IP address of my PC, I see that no data is being received.

I isolated the cause of the issue to the update of IP address entry in the ARP table.

The lwIP API "udp_send" ultimately calls "etharp_output", which then broadcasts an ARP request (by calling "etharp_request") to find the MAC address associated with the IP, if the UDP message is intended for unicast. 

I observed that even though the lwIP API "etharp_request" returns a successful status, there is no ARP request actually sent by the target. Hence, the ARP table entry remains in "ETHARP_STATE_PENDING" state and the data transmission does not start.

This problem does not occur if I put a breakpoint before "etharp_request", wait for a moment and then continue free run. In this case, I see an ARP request is broadcasted, PC responds with its MAC address and the UDP data transmission starts immediately.

It seems like the lwIP API is successfully queuing the ARP request but the hardware is not able to send it without a delay. 

I found this exact issue mentioned in e2e posts for other TI hardware, but without any resolution: TIVA processor and Hercules MCU

I want to understand why is the delay needed to send the ARP broadcast and if this is a documented limitation of the target? Is there anything I can improve in my application to make sure that ARP message is sent correctly?

Any help regarding this is appreciated.

  • 0
    TI__Expert 5351 points

    Hi,

    Thanks for the detailed explanation. The latest C2000ware version is 3.02.00 for your information.

    We have not explored much on the UDP side of lwip stack on F28388D devices. We have only done validation with the HTTP webserver example and the PTPD slave example that uses the lwip. 

    While it is good to note that you are exploring other use cases with UDP,

    MananMishra said:

    The lwIP API "udp_send" ultimately calls "etharp_output", which then broadcasts an ARP request (by calling "etharp_request") to find the MAC address associated with the IP, if the UDP message is intended for unicast. 

    I observed that even though the lwIP API "etharp_request" returns a successful status, there is no ARP request actually sent by the target. Hence, the ARP table entry remains in "ETHARP_STATE_PENDING" state and the data transmission does not start.

    This problem does not occur if I put a breakpoint before "etharp_request", wait for a moment and then continue free run. In this case, I see an ARP request is broadcasted, PC responds with its MAC address and the UDP data transmission starts immediately.

    Is it possible to provide the call stack in CCS Debug view when you just put a break point to understand it a little better. (may be a screenshot in CCS debug window) will help. 

    Regards,

    Sudharsanan

  • 0 in reply to Sudharsanan
    Prodigy 65 points

    The solution to this problem as well as the problem in https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/915952 turned out to be related to "sys_check_timeouts" function. I had missed calling it periodically due to which none of the timeouts were working and the retries were not happening.

    Thanks,

    Manan

  • 0 in reply to MananMishra
    Mastermind 7025 points

    Hello MananMishra, I am seeing a similar behavior with UDP Rx and Tx.

    Why do you need to call sys_check_timeouts and where are you making the call?

    BR