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.

CC3235MODSF: When cc3235 disconnects from AP and makes the next connection, it sends "ipv4_lost" event.

Part Number: CC3235MODSF

Hello, I'm using SDK 5.10.00.02 and "at_commands" example for my project.

When I turn the connected AP's power off, main MCU received "+eventwlan:disconnect".
I turned the AP's power on and the device attempts a new connection. IP is acquired but receives ipv4_lost while opening the socket.
It messed up the following procedures. This is 100% reproduced. I guess the previous "+eventwlan:disconnect" affects next connection.
When I receive the "+eventwlan:disconnect", do I need to do something to prevent the CC3235 sending "ipv4_lost" event on next connection?
Below is the log.

[2021-01-01T00:01:21][DBG][wifi.c:1378] [ATRx:28]-["at+close=0 // <- Previous communication end normally
+close:0
OK

// Unplugged the power cable of the AP.

"]
[2021-01-01T00:01:26][DBG][wifi.c:1378] [ATRx:68]-["+eventwlan:disconnect,TEST_AP,0x90:0x9f:0x33:0xbb:0x6:0xb8,109
"]

// Plugged the power cable after received "+eventwlan:disconnect".

// Device tried new connection and ip acquired but received "+eventnetapp:ipv4_lost" while opening socket.
// It messed up the following procedures.
[2021-01-01T00:01:58][DBG][wifi.c:1378] [ATRx:31]-["at+wlanget=connection,
+wlanget"]
[2021-01-01T00:01:59][DBG][wifi.c:1378] [ATRx:65]-[":sta,disconnected,,TEST_AP,0x90:0x9f:0x33:0xbb:0x6:0xb8
OK
"]
[2021-01-01T00:01:59][INFO][wifi.c:1866] >> WiFi_PrepareToSend: wifi status(5), connected(0)
[2021-01-01T00:01:59][DBG][wifi.c:1378] [ATRx:39]-["at+wlanconnect="TEST_AP",,open,,,,
"]
[2021-01-01T00:01:59][DBG][wifi.c:1378] [ATRx:4]-["OK
"]
[2021-01-01T00:02:02][DBG][wifi.c:1378] [ATRx:128]-["+eventwlan:connect,TEST_AP,0x90:0x9f:0x33:0xbb:0x6:0xb8
+eventnetapp:ipv4_acquired,192.168.0.53,192.168.0.1,164.124.101.2
"]
[2021-01-01T00:02:02][DBG][wifi.c:1378] [ATRx:26]-["at+socket=inet,stream,tcp
"]
[2021-01-01T00:02:02][DBG][wifi.c:1378] [ATRx:41]-["+eventnetapp:ipv4_lost,0
+socket:1
OK
"]
[2021-01-01T00:02:02][ERR][dm_comm.c: 129] >> DMComm_EndBy: Error (dmStatus:0,dmCommPath:2,wifiStatus:9)
[2021-01-01T00:02:02][DBG][wifi.c:1378] [ATRx:41]-["at+setsockopt=1,socket,rcvtimeo,30,0
OK
"]
[2021-01-01T00:02:02][DBG][wifi.c:1378] [ATRx:43]-["at+connect=1,inet,3000,192.168.0.57
OK


"]
[2021-01-01T00:02:04][DBG][wifi.c:1378] [ATRx:67]-["+eventnetapp:ipv4_acquired,192.168.0.53,192.168.0.1,164.124.101.2
"]
[2021-01-01T00:02:04][DBG][wifi.c:1378] [ATRx:28]-["+connect:3000,192.168.0.57
"]
[2021-01-01T00:02:05][DBG][wifi.c:1378] [ATRx:4]-["OK

Thanks,

Calvin

  • Hi Calvin,

    Running the same AT commands on my CC32xx setup, I am unable to see the same error. This is the output I get:

    There is no sudden ipv4_lost message on my setup. Have you tried using a different AP and seeing if you encounter the same issue?

    Regards,

    Michael

  • Hi Michael,

    I'll test with another AP next week. 

    In the meantime,

    1. Could you test it with SDK 5_10_00_02?

         (I test with SDK version 4_40_00_07 also and the issue reproduced once in few times.)

    2. If the issue is not reproduced with SDK 5_10_00_02 then could you add socket open and close procedure to your test?

        ipv4_acquired --> socket open --> socket close --> +eventwlan:disconnect --> at+connect ...........

    Thanks,

    Calvin

  • Hi Calvin,

    Testing on the latest 5.10.00.02 SDK with the latest SP, I still do not see the issue.

    I also added the socket open + close and did not observe any ipv4_lost messages.

    Please do check with another AP and see if you still see the same issue.

    Regards,

    Michael

  • Hi Michael,

    I tried the test with other APs and the same issue still occurred.

    1. iptime A3004 dual - This is the first AP what I test.
    2. iptime A604 - ipv4_lost occurs while sending and receiving data after connected to the server.

                              The timing of receiving ipv4_lost is a little later than #1.
    3. iptime N704 BCM - Same with #1.

    I want to test with other manufacturer's AP but currently I don't have. (I have a buffalo AP but it has some problem)

    Could you check the attached NWP log? (below is the log between main MCU and CC3235)

    0426_ipv4_lost.zip

    [2021-01-01T00:00:09][DBG][wifi.c:1424] [ATRx:37]-["+devinfo:90:E2:02:8C:07:C6,5.10.00.02"]
    [2021-01-01T00:00:09][DBG][wifi.c:1424] [ATRx:5]-["
    OK
    "]
    [2021-01-01T00:00:09][DBG][wifi.c:1424] [ATRx:33]-["at+netcfgset=ipv4_sta_addr,dhcp,
    "]
    [2021-01-01T00:00:09][DBG][wifi.c:1424] [ATRx:4]-["OK
    "]
    [2021-01-01T00:00:10][DBG][wifi.c:1424] [ATRx:28]-["at+wlanpolicyget=connection
    "]
    [2021-01-01T00:00:10][DBG][wifi.c:1424] [ATRx:21]-["+wlanpolicyget:
    OK
    "]
    [2021-01-01T00:00:11][DBG][wifi.c:1424] [ATRx:40]-["at+wlanpolicyset=scan,hidden_ssid,0
    OK
    "]
    [2021-01-01T00:00:11][DBG][wifi.c:1424] [ATRx:591]-["at+wlanscan=0,30
    +wlanscan:TEST_ISENS2,0x90:0x9f:0x33:0xbb:0x6:0xb8,-22,3,open,0,none,none
    +wlanscan:A1Care_Analyzer_HIS,0x90:0x9f:0x33:0xb9:0xb4:0x92,-52,5,wpa2,0,ccmp,psk
    +wlanscan:isens_AP,0x30:0x8b:0xb2:0x96:0xa4:0xa0,-54,11,wpa2,0,ccmp,psk
    +wlanscan:isens_GUEST_AP,0x30:0x8b:0xb2:0x96:0xa4:0xa1,-56,11,wpa2,0,ccmp,psk
    +wlanscan:A1Care_Analyzer_Test,0x90:0x9f:0x33:0xd5:0x93:0xec,-56,13,wpa_wpa2,0,ccmp,psk
    +wlanscan:isens_GUEST_AP,0xc0:0x64:0xe4:0x47:0x47:0xee,-84,64,wpa2,0,ccmp,psk
    +wlanscan:isens_AP,0xc0:0x64:0xe4:0x47:0x47:0xef,-84,64,wpa2,0,ccmp,psk
    +wlanscan:isens_AP,0x30"]
    [2021-01-01T00:00:11][DBG][wifi.c:1424] [ATRx:365]-[":0x8b:0xb2:0x96:0xa4:0x4f,-87,64,wpa2,0,ccmp,psk
    +wlanscan:isens_GUEST_AP,0x2c:0x57:0x41:0x4f:0xfd:0xae,-79,124,wpa2,0,ccmp,psk
    +wlanscan:isens_AP,0x2c:0x57:0x41:0x4f:0xfd:0xaf,-79,124,wpa2,0,ccmp,psk
    +wlanscan:isens_GUEST_AP,0x30:0x8b:0xb2:0x96:0xa5:0x6e,-88,100,wpa2,0,ccmp,psk
    +wlanscan:isens_AP,0x30:0x8b:0xb2:0x96:0xa5:0x6f,-89,100,wpa2,0,ccmp,psk
    OK


    "]
    [2021-01-01T00:01:58][DBG][wifi.c:1424] [ATRx:57]-["at+wlanget=connection,
    +wlanget:sta,disconnected,,,
    OK
    "]
    [2021-01-01T00:01:58][INFO][wifi.c:1990] >> WiFi_PrepareToSend: wifi status(8), connected(0)
    [2021-01-01T00:01:59][DBG][wifi.c:1424] [ATRx:43]-["at+wlanconnect="TEST_ISENS2",,open,,,,
    OK
    "]
    [2021-01-01T00:01:59][DBG][wifi.c:1424] [ATRx:61]-["+eventwlan:connect,TEST_ISENS2,0x90:0x9f:0x33:0xbb:0x6:0xb8
    "]
    [2021-01-01T00:01:59][DBG][wifi.c:1424] [ATRx:67]-["+eventnetapp:ipv4_acquired,192.168.0.53,192.168.0.1,164.124.101.2
    "]
    [2021-01-01T00:02:09][DBG][wifi.c:1424] [ATRx:68]-["+eventwlan:disconnect,TEST_ISENS2,0x90:0x9f:0x33:0xbb:0x6:0xb8,109
    "]
    [2021-01-01T00:02:58][ERR][dm_comm.c: 129] >> DMComm_EndBy: Timeout (dmStatus:0,dmCommPath:2,wifiStatus:8)
    [2021-01-01T00:03:58][DBG][wifi.c:1424] [ATRx:96]-["at+wlanget=connection,
    +wlanget:sta,disconnected,,TEST_ISENS2,0x90:0x9f:0x33:0xbb:0x6:0xb8
    OK
    "]
    [2021-01-01T00:03:58][INFO][wifi.c:1990] >> WiFi_PrepareToSend: wifi status(8), connected(0)
    [2021-01-01T00:03:59][DBG][wifi.c:1424] [ATRx:43]-["at+wlanconnect="TEST_ISENS2",,open,,,,
    OK
    "]
    [2021-01-01T00:03:59][DBG][wifi.c:1424] [ATRx:128]-["+eventwlan:connect,TEST_ISENS2,0x90:0x9f:0x33:0xbb:0x6:0xb8
    +eventnetapp:ipv4_acquired,192.168.0.53,192.168.0.1,164.124.101.2
    "]
    [2021-01-01T00:03:59][DBG][wifi.c:1424] [ATRx:26]-["+eventnetapp:ipv4_lost,0
    "]
    [2021-01-01T00:04:01][DBG][wifi.c:1424] [ATRx:5]-["+even"]
    [2021-01-01T00:04:01][DBG][wifi.c:1424] [ATRx:62]-["tnetapp:ipv4_acquired,192.168.0.53,192.168.0.1,164.124.101.2
    "]

    Thanks,

    Calvin

  • Hi Calvin,

    Thanks for providing the NWP logs. Looking at them, I do see the IPV4 lost event, and it seems to be due to the DHCP process failing when you are reconnecting to the access point.

    For power optimization purposes, the CC3235 will attempt to renew the DHCP address if the lease hasn't expired, but for some reason your AP is returning a NACK in the logs. This is not behavior I see with my test setup.

    We can try and see if disabling the ability to renew DHCP addresses and forcing the CC3235 to perform a full DHCP handshake with every connection changes the IPV4 lost behavior.

    To do so, you need to run the following API once at the start of your application, before you connect:

    sl_NetCfgSet(SL_NETCFG_IPV4_STA_ADDR_MODE, SL_NETCFG_ADDR_DISABLE_FAST_RENEW,0,0);

    You can find some info on what that API does in section 5.4 of the NWP user's guide:

    www.ti.com/lit/swru455

    Now, this API is unfortunately not implemented as an AT command - you will need to copy it into the code of the AT command application. I suggest you do right before ATCommands_readCmd() in mainThread() of at_commands.c. Then, it should run once, before any AT commands are processed.

    Let me know if that fixes your issue.

    Regards,

    Michael

  • Hi Michael,

    I test it as your suggestion and it works fine. No more ipv4_lost event.

    I can see "at+netcfgset=if,state,disable_fast_renew,.." in the AT command user's guide.

    Is it different from the "SL_NETCFG_ADDR_DISABLE_FAST_RENEW" ?

    Thanks,

    Calvin

  • Hi Calvin,

    In theory, the at+netcfgset option to disable fast renew should perform the same function as the API I provided you. However, I'm not sure if that command is implemented with the actual API needed. If you try using that AT+NetCfgSet command, does it resolve your issue?

    Do note that sl_NetCfgSet(SL_NETCFG_IPV4_STA_ADDR_MODE, SL_NETCFG_ADDR_DISABLE_FAST_RENEW,0,0); is persistent, so for a proper test you will need to run the same API but with the enable bit set instead, or reflash your device.

    Regards,

    Michael

  • I used the at command before connecting AP like below and it's not working for this issue.

    So I think the sl_NetCfgSet API needed for this.

    If receive ipv4_lost, I can handle it as an error, so there may not be a need to disable fast renew.

    It is rare to turn an AP power off and on, so I will consider whether to apply this method in production.

    [2021-01-01T00:00:09][DBG][wifi.c:1341] [ATRx:37]-["+devinfo:90:E2:02:8C:07:C6,5.10.00.02"]
    [2021-01-01T00:00:09][DBG][wifi.c:1341] [ATRx:5]-["
    OK
    "]
    [2021-01-01T00:00:09][DBG][wifi.c:1341] [ATRx:33]-["at+netcfgset=ipv4_sta_addr,dhcp,
    "]
    [2021-01-01T00:00:09][DBG][wifi.c:1341] [ATRx:4]-["OK
    "]
    [2021-01-01T00:00:09][DBG][wifi.c:1341] [ATRx:41]-["at+netcfgset=if,state,disable_fast_renew
    "]
    [2021-01-01T00:00:10][DBG][wifi.c:1341] [ATRx:4]-["OK
    "]
    [2021-01-01T00:00:10][DBG][wifi.c:1341] [ATRx:35]-["at+wlanpolicyset=pm,low_power,
    OK
    "]

    Thanks,

    Calvin