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: Lost SSID & MAC Address

Part Number: CC3220SF
Other Parts Discussed in Thread: CC3220S,

Hello,

 

We recently did an OTA update of the code in a CC3220-based design we are working on. Prior to the update, all CC3220s were connected to our server via routers in our labs. Connections were established via DHCP.

 

After the OTA update, most units took the update, and ran just fine. However, six units did not connect back to our server. We have a User Interface that allows us to look at the WiFi parameters in the CC3220, and here is what we found:

 

The SSID returned in our user interface showed blank spaces. The SSID that had been resident was wiped. On some units, we cycled power, and the SSID was restored, indicating that the value in Serial Flash was still resident. But this was not the case on all controls.

 

Even stranger, the MAC Address returned on these units via the user interface showed a value of either “60000     0” or “60000   A00”. We found this even stranger, since our understanding is that the MAC Address is coded into the CC3220, and should not be changeable. Again, cycling power cleared this up on some, but not on all units.

 

We use these functions shown below in our code to obtain SSID and MAC Address

Has anyone seen this before, or have some thoughts on what may be happening here?

Thanks!

Paul

 

uint32_t wifi_get_IP_Address(void)

{

   int16_t i16ret;

   uint32_t ipAddress;

   uint16_t len = sizeof(SlNetCfgIpV4Args_t);

   uint16_t ConfigOpt = 0;

 

   SlNetCfgIpV4Args_t ipV4 = {0};

   i16ret = sl_NetCfgGet(SL_NETCFG_IPV4_STA_ADDR_MODE,&ConfigOpt,&len,(uint8_t *)&ipV4);

   if (i16ret != 0)

       ipAddress = 0;                           // if fail getting IP Address, return address of zero

   else

       ipAddress = ipV4.Ip;                     // else return IP Address received from SimpleLink

 

   return ipAddress;

}

 

int16_t wifi_getMACaddress(uint8_t *macAddressVal)

{

   _i16 getMacRet;

   // Get MAC Address

   uint16_t macAddressLen = SL_MAC_ADDR_LEN;

   uint16_t ConfigOpt = 0;

   getMacRet = sl_NetCfgGet(SL_NETCFG_MAC_ADDRESS_GET,&ConfigOpt,&macAddressLen,(uint8_t *)macAddressVal);

   return (int16_t)getMacRet;

}

 

 

  • Hi Paul,

    I'm assuming you mean the IP address you get is wrong - not the SSID (the name the router broadcast) correct? 

    It looks like you are calling sl_NetCfgGet correctly for IP address. You may be getting false readings because those units are not getting the IP address from those routers fast enough. Make sure you don't call wifi_get_IP_Address until after you get the IP acquired async event. Also, you do not have to call this, you can get the IP address from the async event handler directly. Look for the SL_NETAPP_EVENT_IPV4_ACQUIRED event in the SimpleLinkNetAppEventHandler. This should trigger after DHCP completes. Refer to pNetAppEvent->Data.IpAcquiredV4.Ip.

    For the MAC address I'm not sure if you are using it correctly. You are casting macAddressVal as a pointer? Refer to the snippet below for reference: 

    uint8_t macAddress[SL_MAC_ADDR_LEN];
    uint16_t macAddressLen = SL_MAC_ADDR_LEN;
    status = sl_NetCfgGet(SL_NETCFG_MAC_ADDRESS_GET, 0, &macAddressLen,
                              &macAddress[0]);

    SL_MAC_ADDR_LEN is defined in netcfg.h.

    the MAC Address is coded into the CC3220, and should not be changeable

    You could actually overwrite the default mac address. Refer to section 3.8 of the programmer's guide for more details.

    Jesu

     

     

  • Hi Paul,

    Check Local Ota demo code for CC3220SF you'll get your answers  there.

  • Hi Paul,

    Merrill and I communicated in the background and he was able to clear up some details on the SSID. I agree with your thought process here - it seems solving the MAC address issue should also solve the SSID issue since the symptoms seem to be similar in nature. I noticed you're using sp_3.7.0.1_2.0.0.0_2.2.0.6.bin which I believe is from CC32XX SDK v2.10. Keep in mind this SDK is very old and we have released many bug fixes and patches since then. I strongly recommend you update to the latest service pack which you can find in the latest cc32xx SDK. 

    Let me know how it goes.

    Jesu

  • Hi Paul,

    For the quickest response I recommend you continue working with me on E2E. This is your directly line to me and I'm personally monitoring this thread. If you have any concerns about sharing anything proprietary you can share with Merrill directly and he will communicate with me via email. 

    I saw in your update to Merrill last week Dan was able to create this issue on some units that have not had an OTA update. This information is helpful because it disconnects the issue you're seeing from the OTA process. It could be an error with the NWP or the host driver but it's too early to tell.

    As a first step, I would recommend updating the service pack found in the latest SDK to see if the issue goes away. Please let me know what your results here so we can continue this support effort as efficiently as possible.

    Jesu

  • Hi Jesu,

    My customer updated to the new Service Pack, and the issues persists with the new Service Pack.  I'm checking to see if they possibly have a method to replicate the issue.

    Thanks, Merril

  • Thanks for the update Merril. Since we also know it's not linked to OTA this will simplify the setup required to reproduce.

    I'll continue monitoring this for updates.

    Jesu