CC3120MOD: SL_ERROR_INVALID_PARAM returned by sl_WlanSet after writing a new servicepack

Hi Georges Brown,

What parameters are you sending in the sl_WlanSet() ?  

Are you using reference code (for the sl_WlanSet) from the user guide or the header file?

Does the same call (with same parameters values) works with your original (before the SP update)? 

Br,

Kobi

Hi Kobi,

The code is the following:

/* Set Tx power level for station mode
Number between 0-15, as dB offset from max power - 0 will set maximum power */
retVal = sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_OPT_AP_TX_POWER, 1, (_u8 *)&txPower);

txPower is of type:

   enum TxPowerEnum
   {
      TX_POWER_MAXIMUM = 0,
      TX_POWER_1,
      TX_POWER_2,
      TX_POWER_3,
      TX_POWER_4,
      TX_POWER_5,
      TX_POWER_6,
      TX_POWER_7,
      TX_POWER_8,
      TX_POWER_9,
      TX_POWER_10,
      TX_POWER_11,
      TX_POWER_12,
      TX_POWER_13,
      TX_POWER_14,
      TX_POWER_MINIMUM
   };

The call used to work before the SP update.

Thanks,

Georges

Hi,

Please switch to the latest 3.13 SP.

I've just verified that the API works with this SP.

You won't need to update anything on the SW side to use the latest SP.

Br,

Kobi

Hi Kobi

Thanks for your help. Where can I download the latest 3.13 SP ?

Best regards,

Georges Brown

You will need to install the latest SDK (3.30) of CC3220 (http://www.ti.com/tool/download/SIMPLELINK-CC32XX-SDK) and get the service pack under tools/cc32xx_tools/servicepack-cc3x20/.

The same SP is used for CC3220 and CC3120.

Br,

Kobi

Hi Kobi,

I installed the latest service pack: sp_3.14.0.0_2.0.0.0_2.2.0.7.ucf

However sl_WlanSet still returns SL_ERROR_INVALID_PARAM.

I notice the original servicepack on the CC3120MOD is : 

FW: 2.1.0.1

PHY: 2.2.0.5

NWP: 3.3.99.1

I originaly ported the simplelink API with this servicepack and calls to sl_WlanSet were successfull.

What is the FW version (2.1.0.1) ? I notice it was originaly a more recent version versus the one of the new servicepack (2.0.0.0). Can this have an impact ?

Thank you,

Georges Brown

Hi Georges,

The numbers you previously saw are wrong (they are the numbers installed to the module  that you will see before your load a valid SP). 

Again, i tested the command using the new SP (3.14...) on CC3120 and everything seems to work.

I really don't understand the issue and it is most probably related to your host platform. What host and OS are you using? Can you validate that the write data is being transferred over the SPI?

The only differences between us is that I've installed the new SP using uniflash and tested your commands on an MSP432 reference application (added the code after sl_Start in tge mqtt_client example from the plugin).

Br,

Kobi

Hi Kobi,

Thank you for your time helping me with this. regarding your awnser, I would like to clarify some points:

The numbers you previously saw are wrong (they are the numbers installed to the module  that you will see before your load a valid SP). 

How could they be wrong ? They are the versions of the servicepack that is loaded by TI during production right ?

I really don't understand the issue and it is most probably related to your host platform. What host and OS are you using? Can you validate that the write data is being transferred over the SPI?

I agree something might be wrong with the host platform. However, I have some doubts because all API calls work before updating the servicepack file.

The issue is the following:

1) Setup: TMS570LC43 (nonos) with CC3120MOD using SPI

2) The setup was tested with the original servicepack present on the CC3120MOD. All Simplelink API calls return successfully.

3) In order to update the servicepack using the host API, I use the function sl_FsWrite() to write the .ucf file to "/sys/servicepack.ucf". The file is transfered in chunks by TCP socket.

3) The file is closed successfully using sl_FSClose() and the key (".ucf.signed.bin")

4) After the device is restarted, call to sl_DeviceGet() returns the newly installed versions. Also, if the device is started as an accesspoint mode with the default http server, the new versions are displayed.

5) The issue occurs here: at this point, calls to sl_wlanSet() returns SL_ERROR_INVALID_PARAM.

Is this a corrcect way to update the servicepack on the CC3120MOD using the host API ? Is there a better way to do it ?

Best regards,

Georges Brown.

The module was loaded with an SP that is not updated. An updated SP must be installed. 

Please ignore the numbers as they are not relevant, the latest SP include the most updated firmware patches.

There is an option that the issue is related to the fail-safe support.

After writing the file, please make sure that you are calling sl_Stop() before resetting the MCU.

When you power up, check if the NWP is in PENDING_COMMIT state and then COMMIT the update if needed. Below please refer to an example code (taken from the  Cloud_OTA app).

int32_t OtaCheckAndDoCommit()
{
    int32_t isPendingCommit;
    int32_t isPendingCommit_len;
    int32_t Status;

    /* At this stage we have fully connected to the network (IPv4_Acquired) */
    /* If the MCU image is under test, the ImageCommit process will 
    commit the new image and might reset the MCU */
    Status =
        OTA_get(EXTLIB_OTA_GET_OPT_IS_PENDING_COMMIT,
                (int32_t *)&isPendingCommit_len,
                (uint8_t *)&isPendingCommit);
    if(Status < 0)
    {
        OTA_DBG_PRINT(
            "OtaCheckDoCommit: OTA_get ERROR on "
            "EXTLIB_OTA_GET_OPT_IS_PENDING_COMMIT, Status = %d\r\n",
            Status);
        SignalEvent(APP_EVENT_ERROR); /* Fatal error */
        return(0); /* action in state machine - return 0 in order to process the
        APP_EVENT_ERROR */
    }

    /* commit now because 1. the state is PENDING_COMMIT 2. there was successful
    wlan connection */
    if(isPendingCommit)
    {
        Status = OTA_set(EXTLIB_OTA_SET_OPT_IMAGE_COMMIT, 0, NULL, 0);
        if(Status < 0)
        {
            OTA_DBG_PRINT(
                "OtaCheckDoCommit: OTA_set ERROR on "
                "EXTLIB_OTA_SET_OPT_IMAGE_COMMIT, Status = %d\r\n",
                Status);
            SignalEvent(APP_EVENT_ERROR); /* Can be in wrong state,
            ToDo - no error */
            return(0); /* action in state machine -
            return 0 in order to process the APP_EVENT_ERROR */
        }
        OTA_DBG_PRINT("\r\n");
        OTA_DBG_PRINT(
            "OtaCheckDoCommit: OTA success, new image commited and "
            "currently run\n");
        OTA_DBG_PRINT("\r\n");
        /* Stop the commit WDT */
        Platform_CommitWdtStop();
    }
    return(0);
}

br,

Kobi

Hi Kobi,

Again, thank you for your response.

I will try to check if the NWP is in PENDING_COMMIT.

Meanwhile, I would just like mention again that after the servicepack file is successfuly written and closed and the default HTTP server is used, it is possible to connect to the device with a web browser:

The Build No. displays the expected versions. 

When I go in the device tab and try to change the SSID, it does not work. I get the fooling error in the browser: ERR_CONNECTION_REFUSED

If the NWP is pending commit, would such a behaviour appen ?

Than you,

Georges Brown

This doesn't seems related to the pending commit unless the watchdog caused a reset and the connection was lost.

Have you made any progress with this?

Do you still have the problem with the sl_wlanSet?

Can you provide NWP logs (https://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs)  for this use case?

Br,

Kobi