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.

MSP432E401Y: Connection issue with ethernet interface and latest version of MSP432 SDK v3.20.00.10

Part Number: MSP432E401Y

Hi all,

I am experiencing an issue with the latest MSP432 SDK v3.20.00.10.     This seems to be related to an issue I reported several months back (see https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/767365?tisearch=e2e-sitesearch&keymatch=MSP432E401Y ).    I am using CCS v9.0.1.00004 with all the latest updates/patches applied,   MSP432E4 SDK v3.20.00.10  and SimpleLink MSP432 WIFI Plugin v2.40.00.22.   I am using a MSP432E401Y Launchpad with the CC3120BOOSTRevA daughter card attached.   I installed the "wifi_ethernet_sockets" example from the SimpleLink MSP432 WIFI Plugin v2.40.00.22 package.

For my configuration, when the wifi_ethernet_sockets app is started up all initializes just fine; my ethernet IP is assigned the address 10.0.0.78 and my Wifi gets the address 10.0.0.174.     I have the card connected to a hardwired ethernet connection port on my router and I know that, if all is working properly, the connection will remain ethernet until the it fails for some reason (e.g., I unplug the ethernet cable) at which time the connection will automatically switch to Wifi. 

However, what I observe, is that the app connects to the python TCP server provided in the example code just fine and begins producing output.    I can see from the output of the Python server that the client connection IP is 10.0.0.78.   However after exacting 10 send/receive events, the ethernet connection suddenly disconnects and switches to Wifi (IP 10.0.0.174).    It stays on Wifi for exactly two send/receive events, then ethernet reconnects and the pattern repeats.

The issue can be fixed by backing down the MSP432 SDK to version 2.30.00.14.   If I use any version later than this one, I see the issue. 

Here is the output from the terminal window for the LaunchPad MCU:

Service Status: DHCPC : Enabled : : 000

Service Status: DHCPC : Enabled : Running : 000

Ethernet Interface connected and started

Interface(s) not added yet

Device came up in Station mode

[WLAN EVENT] STA Connected to the AP: XXXXX, BSSID: XXXXXXXX

[NETAPP EVENT] IP acquired by the device


WiFi Interface has connected to XXXXXXX

WiFi Interface IP Address is 10.0.0.174


WiFi Interface connected and started

Ethernet Connection Added:
10.0.0.78

Service Status: DHCPC : Enabled : Running : 017

world-1
world-2
world-3
world-4
world-5
world-6
world-7
world-8
world-9
world-10
world-11
world-12
world-13
world-14
world-15
world-16
world-17
world-18
world-19
world-20
world-21
world-22
world-23
world-24
world-25
world-26
world-27
world-28
world-29
world-30
world-31
world-32
world-33
world-34
world-35
world-36

Here is the output log from the Python tcp server application:

Connection address: ('10.0.0.78', 57345)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57345)
Connection address: ('10.0.0.78', 57346)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57346)
Connection address: ('10.0.0.78', 57347)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57347)
Connection address: ('10.0.0.78', 57348)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57348)
Connection address: ('10.0.0.78', 57349)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57349)
Connection address: ('10.0.0.78', 57350)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57350)
Connection address: ('10.0.0.78', 57351)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57351)
Connection address: ('10.0.0.78', 57352)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57352)
Connection address: ('10.0.0.78', 57353)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57353)
Connection address: ('10.0.0.78', 57354)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57354)
Connection address: ('10.0.0.174', 60294)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.174', 60294)
Connection address: ('10.0.0.174', 52011)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.174', 52011)
Connection address: ('10.0.0.78', 57355)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57355)
Connection address: ('10.0.0.78', 57356)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57356)
Connection address: ('10.0.0.78', 57357)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57357)
Connection address: ('10.0.0.78', 57358)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57358)
Connection address: ('10.0.0.78', 57359)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57359)
Connection address: ('10.0.0.78', 57360)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57360)
Connection address: ('10.0.0.78', 57361)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57361)
Connection address: ('10.0.0.78', 57362)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57362)
Connection address: ('10.0.0.78', 57363)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57363)
Connection address: ('10.0.0.78', 57364)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57364)
Connection address: ('10.0.0.174', 54738)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.174', 54738)
Connection address: ('10.0.0.174', 54049)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.174', 54049)
Connection address: ('10.0.0.78', 57365)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57365)
Connection address: ('10.0.0.78', 57366)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57366)
Connection address: ('10.0.0.78', 57367)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57367)
Connection address: ('10.0.0.78', 57368)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57368)
Connection address: ('10.0.0.78', 57369)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57369)
Connection address: ('10.0.0.78', 57370)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57370)
Connection address: ('10.0.0.78', 57371)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57371)
Connection address: ('10.0.0.78', 57372)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57372)
Connection address: ('10.0.0.78', 57373)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57373)
Connection address: ('10.0.0.78', 57374)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.78', 57374)
Connection address: ('10.0.0.174', 60848)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.174', 60848)
Connection address: ('10.0.0.174', 51054)
received data: b'h'
received data: b'e'
received data: b'l'
received data: b'l'
received data: b'o'
Connection closed: ('10.0.0.174', 51054)

  • Hello Timothy,

    Timothy Carbo said:
    This seems to be related to an issue I reported several months back (see https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/767365?tisearch=e2e-sitesearch&keymatch=MSP432E401Y )

    Both you and I could not reproduce the issue (after you saw it initially) reported in the above mentioned thread right? Just wanted to mention that so that we don't shift our focus with the issue on hand.

    We will try the wifi_ethernet_sockets example in the Wi-Fi plugin and get back by Friday. Hope this timing works!

    Regards,

    Sai

  • Sai,

    The only thing I can say is that the original problem reported back then appeared to be related to the Wifi connection.   There appears to no longer be an issue with the Wifi which is what resolved the original issue.  This is the first time I have actually tested the Ethernet so maybe it is a different issue than the one I reported earlier. 

    Hope that helps!

    Regards,

    Tim 

  • Hello Sai,

    Any progress on resolving this issue?   Stability using the ethernet connection is a high priority for my project and I would really like to promote to the new SDK.

    Regards,

    Tim

  • Sai,

    Have you looked into this?   Were you able to reproduce the error?

    Regards,

    Tim

  • Hello Timothy,

    Apologize for the delay on getting back to you!

    I was able to reproduce the issue. I will look into the root cause and get back within a day.

    Thanks,

    Sai

  • Sai,

    That is good.   Thank you for the update.   I look forward to a resolution to the issue.

    Regards,

    Tim

  • Hello Sai,

    Just checking in.   Just wondering if you had made any progress resolving this issue?

    Regards,

    Tim

  • Hello Tim,

    I tried to use the SLNetSock from the MSP432E4 SDK v3.20 and the Wi-Fi plugin v2.40 but noticed the same behavior with both these versions. That tells me that the issue would be with the SLNetIf Layer.

    Next step is to ensure that the SLNetSock Layer and the SLNetIf layer are all on the same version. So I will try to update the SLNetIf of the Wi-Fi Plugin to use the version from the CC32xx SDK v3.20.00.06. This is slightly involved process, so might take a day or two for me to complete it.

    Thanks,

    Sai

  • Hello Tim,

    I have noticed this issue with the MSP432E4 SDK v2.40.00.xx. So this might not be version dependent.

    I have requested my colleague who has more knowledge on this topic for further help!

    Will keep you posted on the progress.

    Thanks,

    Sai

  • Sai,

    Thanks for the update.  Would be good to close on this issue as our firmware is dependent upon the ethernet working reliably.   It has caused us some headaches recently as there is no apparent work-around for this issue.

    Thanks,

    Tim

  • Hello Timothy,

    Timothy Carbo said:
    It has caused us some headaches recently as there is no apparent work-around for this issue.

    Reading the documentation (SlNetSock Overview -> SlNetSock group) for the API SlNetSock_create, you can specify the interface to use by providing a non-zero value to the parameter ifBitmap. You will however have to write the logic that detects when an interface is down and switches. If the parameter ifBitmap is set to zero the detection and switching is managed by the SlNetSock layer.

    Thanks,

    Sai 

  • Sai,

    I apologize but your response confused me a little.  Is the problem with auto-switch or is it with the ethernet connection?   It seems to me that the ethernet connection is failing which is causing the switch to wifi then it recovers some short time later allowing a switch back.    I have observed that if I force the connection to be ethernet only it fails repeatedly.   However, if I force the connection to be wifi-only, I don't see any connection issues.   I have installations where my application is deployed that are ethernet-only so forcing wifi only would not be an option for me in those cases.

    Regards,

    Tim

  • Hello Timothy,

    Timothy Carbo said:
    I apologize but your response confused me a little.  Is the problem with auto-switch or is it with the ethernet connection? 

    You are correct! The issue is not with auto-switch as I had mentioned in my previous post.

    Timothy Carbo said:
    It seems to me that the ethernet connection is failing...

    The issue is not with Ethernet connection. When the socket is closed, it seems the TCP Client (MSP432E4) is going into a TIME-WAIT state and waiting for a Timeout to complete before it completely releases the Socket. Because of this, after 10 sockets are closed (which is the maximum number of default sockets allowed on NDK), the SlNetSock_create fails to create more sockets. If you wait long enough then these sockets will be released and then calling SlNetSock_create would open new sockets.

    This behavior seems to be the result of TCP guaranteeing no data loss.

    I haven't tried this, but if you allow the NDK to open more sockets, such that the time taken to go through all the sockets in equal or greater than the timeout (I think about a minute) for TIME-WAIT state then you might not notice this issue.

    Thanks,

    Sai 

  • Sai,

    Thanks for getting back to me.   Much appreciated.

    Regarding your statement:

    "I haven't tried this, but if you allow the NDK to open more sockets,"

    How do I configure this in the NDK?  Does it require a code change?

    Regards,

    Tim

    Regards,

    Tim

  • Hello Timothy,

    The define MAXSOCKETS in ndk_<RTOS>.c file can be updated to set the number of sockets.

    The number of sockets that can be supported depends on the memory allocated. To modify the size of the allocated memory, you can update the following two defines in the same file:

    /* NDK memory manager page size and number of pages [used by mmAlloc()] */
    #define RAW_PAGE_SIZE 3072
    #define RAW_PAGE_COUNT 6

    Thanks,

    Sai

  • Sai,

    I would like a little more guidance here.  Can you be more specific regarding the relationship between RAW_PAGE_SIZE, RAW_PAGE_COUNT and the number of TCP sockets?  In other words, how does changing one of these defines affect the others?   I tried increasing the MAXSOCKETS from 10 to 60  and  RAW_PAGE_COUNT to 10 and, while this appears to have fixed the problem, it also increased SRAM utilization substantially (by about 13k!).   Do you have any recommendations on how I should set these three defines to minimize my memory utilization and still connect without issues?

    Regards,

    Tim

  • Sai,

    Regarding your earlier statement: "the TCP Client (MSP432E4) is going into a TIME-WAIT state and waiting for a Timeout to complete before it completely releases the Socket".   Is there a way to prevent the TCP Client from going into this TIME-WAIT state or at least shorten it?   This way I wouldn't have to allocate additional SRAM to work around this problem.

    Regards,
    Tim

  • Timothy Carbo said:
     Is there a way to prevent the TCP Client from going into this TIME-WAIT state or at least shorten it? 

    Section 2.4.1 Troubleshooting Common Problems of the TI Network Developer's Kit (NDK) User's Guide contains:

    Watch for out of memory conditions. These can be detected by the return from some functions, but will also print out warning messages when the messages are enabled. These messages contain the acronym OOM for out of memory. (Out of memory conditions can be caused by many things, but the most common cause in the NDK is when TCP sockets are created and closed very quickly without using the SO_LINGER socket option. This puts many sockets in the TCP timewait state, exhausting scratchpad memory. The solution is to use the SO_LINGER socket option.)

    Is the SO_LINGER socket option used in your code?

  • Chester/Sai,

    No I was not setting the socket linger option.   So I added the following lines after the socket create then reverted my edits to the ndk_tirtos.c file back to the original values and it solved the problem (see below)!   Now, I do not need to increase the page size in this case which is a much better solution.   Thank you for your assistance!

    Regards,

    Tim

    server =
    SlNetSock_create(SLNETSOCK_AF_INET, SLNETSOCK_SOCK_STREAM,
    SLNETSOCK_PROTO_TCP,
    0, SLNETSOCK_CREATE_IF_STATUS_CONNECTED);

    SlNetSock_linger_t linger;
    linger.l_onoff = 1;
    linger.l_linger = 10;
    SlNetSock_setOpt(server, SLNETSOCK_LVL_SOCKET, SLNETSOCK_OPSOCK_LINGER, &linger, sizeof(linger));

     

     

**Attention** This is a public forum