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.

RTOS/CC3220SF-LAUNCHXL: SimpleLink CC32XX SDK Azure IoT Plugin

Part Number: CC3220SF-LAUNCHXL

Tool/software: TI-RTOS

The SimpleLink CC32XX SDK Azure IoT Plugin is still not compatible with SDK 3.10. It's been months now and is becoming a real problem for us. Is anyone working on this? 

  • Resources are not working on the Azure IoT Plugin at this time.  The reasoning is that the 2.40 and 3.10 (and soon, 3.20) SDKs are "mostly compatible" and it should be straightforward to migrate 2.40-based examples (like you'll find in the Azure IoT Plugin) to work with 3.10/3.20.

    AFAIK, the I2S APIs broke compatibility in the 3.10 SDKs, and that's probably the issue you're seeing.  Is that right?

    If so, the Azure IoT Plugin examples don't require I2S, but they do include a <board>.c file that configures I2S (and many other drivers), in an effort to make it easier to start using those drivers in applications derived from those examples.  Unfortunately, the 3.10 I2S compatibility break affects that [unused] code.  You should be able to simply remove the I2S related code from the <board.c> file and the examples should build.

    FWIW, we are planning to make an Azure IoT Plugin update based on the Q3 (3.30) SDKs, but I understand that is a ways off.

  • Thanks Chris for your answer, but that's not the issue, I had fixed that already. The issue is in tlsio_sl.c line 337 where SlNetSock_startSec returns an error -468 (SL_ERROR_BSD_ESECUNKNOWNROOTCA). Now why SDK 2.30 works and not after an explanation would be great.
  • Hi Michael,

    The error you are seeing is related to the certificate store, and is telling you that the root CA cert being returned from the server you're connecting to isn't being found in the list of trusted root CA certs that the device knows about (i.e. it's not in the cert store of the device).

    The reason you see things working in the 2.30 SDK is because there was a bug in the SlNetSock_startSec() function:

        SLWIFICSR-367 sl_StartTLS doesn't return SL_ERROR_BSD_ESECUNKNOWNROOTCA

    (Note SlNetSock_startSec() calls sl_StartTLS)

    Due to this bug, the check against the certificate store was being ignored, and so these functions were returning success (0).

    The bug was fixed in the 2.40 SDK, which is why you now see that error when using that version.

    Lastly, note that this error code is really a "warning" - the underlying connection is still made. It's up to the caller to decide how to treat it.

    Steve

  • Thank you for shedding light on the issue.