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.

CC3220S-LAUNCHXL: Possible Issue In SimpleLink 4.30.6

Part Number: CC3220S-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF

Hi There,

I've encountered an issue which I have tracked down to having to do with SimpleLink SDK 4.30.6. Specifically, there seems to be an issue with the rest call /api/1/wlan/profile_add.

To help narrow this down I am using the provisioning demo app, taken from the 4.30.6 SDK. I've tested all of this with the provisioning app, but since I can't see what it's doing it's hard to comment on the difference in the results.

Symptoms:

I started investigating this because in my app I was noticing calls to /profile_add was causing a NWP abort. To help narrow it down I tried using the provisioning demo with the 4.30.6 service pack. Right away there is a curious difference: 

The curious thing is the SSID is NOT printed. On the 4.20 revision of SimpleLink, the SSID is printed. Note to test this I am using the same code, just flashing a different service pack. That is, I'm not changing the underlying source code being flashed. 

However, the real problem is that whenever I use a SSID with a capital first letter when adding a profile, I get the following:

Using all lower case SSIDs does NOT produce this result. Furthermore, this behavior doesn't happen with 4.20.7

Any help resolving this would be greatly appreciated. 

  • Hi,

    I tried reproducing your issue with my CC3220SF running the provisioning example with the v4.20 SDK and v.3.17.0.4 NWP servicepack, and cannot reproduce your issue.

    With my local network with SSID "ATT6d97DE", I can successfully complete the provisioning flow without encountering any abort issues. Could you please collect the NWP logs from the device so that I can see what precisely is happening with the NWP when you encounter this abort? The instructions for collecting the NWP logs can be found in section 20.1 of the NWP user's guide: https://www.ti.com/lit/swru455

    Please note that the logs will be in a binary format if you have captured them correctly. This is normal, as the logs are only able to be decoded by TI. There is however a sanity check you can perform on your collected logs before you provide them to me. If the NWP logs are captured successfully from cold boot, you should see some ASCII plaintext in the raw logs, most notably the /sys/servicepack.ucf NWP SP file. Furthermore, the 3 bytes of binary data preceding that string will be 0x27 0xCA 0x2F. If you check for the string + those 3 bytes and see it in your logs then the final thing to check for is that there are null (0x0) characters present in the captured byte stream. If so, the logs should be captured correctly and decodable by my tools.

    Thanks,
    Michael

  • Hi Michael,

    I'll capture the logs and get them back to you. How should I transmit them to you?

    Also, it might be a typo, but make sure you are testing against the 4.30 version of the sdk with the 3.17.04 service pack as this is the configuration that reproduces my issue. 

    Thanks!