• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 41 subscribers
  • Views 351 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.

CC3220SF-LAUNCHXL: DHCP serverIP and sl_RecvFrom

Cherry Zhou
Mastermind 22235 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF

Hi team,

Here're 2 questions from the customer may need your help:

1) 3 CC3220SF evaluation boards, one for AP and two for STA.

AP's IP: 10.123.45.1. When both STAs are connected to the AP at the same time, the IP is mostly 10.123.45.2 and 10.123.45.3, but sometimes assigned as 10.123.45.3 and 10.123.45.4.

Ensure that no other STAs in the subnet are connected to the AP, and the uncertainty of IP assignment can cause problems due to the use of IP identification. Why do IP assignments sometimes have 3 and 4? 

2) Two CC3220SF, one for transmit and one for receive. The UDP protocol is used.

In multiple power up/down tests, it is common for the transmitting side SL_SendTo to show a successful transmission (return number of bytes to send), but the receiving side SL_Recvfrom to return -11, causing further communication to fail. Power cycle both boards, either good or not.

So the customer would like to figure out under what conditions SL_Recvfrom will return -11?

Thanks.

Best Regards,

Cherry

  • 0
    TI__Genius 14601 points

    Hi Cherry,

    1) What I am assuming is happening is that the Stations disconnect from the ap at some point and reconnect to the AP, however since...

    The addresses aren't released and when the devices connect they are given .3 and .4 . 

    Here is a link to the Network Processors guide. I recommend going over section 5.4.

    2.) Error -11 means SL_ERROR_BSD_EAGAIN error code means data has not arrived; poll again

    I would make sure that when they use the SL_SendTo they are using the correct IP address and port  as well when receiving. The problem seems to be that one board sending data but the other isnt receiving it. 

    In the same Network Processors guide. I recommend going over section 6.5.2.

    Kind Regards,

    Rogelio

  • 0 in reply to RogelioD
    TI__Mastermind 22235 points

    Hi Rogelio,

    Thanks for supporting.

    Regarding Q2: this problem occurs regularly. The first time powering up the AP and STA communications are normal, the second time the problem appears, and the third time disappears, fourth normal.

    Each time the problem occurs, two boards works as follows:  in each test, if the STA receives the number the first time recvfrom, it receives it all the time. If the first recvfrom does not receive a number, it is never received, and the return value is always -11 (no matter how many polls are conducted).

    SL_Sendto on the AP side is working properly.

    Thanks and regards,

    Cherry

  • 0
    Prodigy 20 points

    not regularly, but randomly

  • 0
    Prodigy 20 points

    not regularly, but randomly

  • 0 in reply to Cherry Zhou
    TI__Genius 14601 points

    Hello,

    First thing I would suggest is to make sure you have the latest service pack installed.

    Second, unfortunately due to the connectionless nature of UDP there is no acknowledgement that the packets were received by the station. I know it returns how many bytes it sends, but that isn't an acknowledgement that they were received.

    This problem could actually be related to query 1. If the Station IP address changes from the IP address you have in the SL_Sendto parameter then the packet will not be sent to the right place. The problem could also be a timing issue where not enough time is given to receive the packet before calling SL_RecvFrom, adding a delay could help.

    The best way forward to debug would be to take sniffer logs in order to make sure the packets are being sent out and to what IP they are being sent to. Then verify your STA has that IP.

    Best Regards,

    Rogelio