CC3235MODSF: SDK 7 TLS1.3 support

You can check the mbedtls_config.h for a missing configuration (in source/third_party/mbedtls/include/mbedtls/).

See README in mbedtls/ti/ for instruction about building the mbedtls lib.

We will need to see logs. You can enable "MBEDTLS_SSL_DEBUG_ALL" in the mbedtls_config.h (which require rebuilding the library) or provide a sniffer capture.

We will try to check this internally also but it may take more time.

the library doc says the context should not be shared between threads (Thread safety and multithreading: concurrency issues — Mbed TLS documentation (mbed-tls.readthedocs.io)) however, in the slnetifwifi.c file, SlNetIfWifi_CreateContext using a global context. will this be an issue? I can share the code if that helps. 

working on rebuild and enable all the debug messages. 

things do help if I put a break point in the certificate load before handshake. so looks like to me this is a more multithreading issue. 

i believe this ok - the context is not per socket but per netif which we only have one.

ok. I'll check the log and will respond probably tomorrow.

Hi Kobi,

thank you for following up on this. It turned out to be a memory issue, to make the mqtt and http to run at the same time, the mem heap has to be big enough, and also the stack size.  my test shows that, the required minimal size of the mem heap is 2a000. and call stack 10k each for mqtt and http. this used up 188kB out of 240kB RAM. this is to run just the example with adding http thread. Any suggestions to make the RAM usage smaller for our application? 

also, a follow up question, 

1) in the SDK 7 release, there is a http binary for OTA under folder http_lib_for_OTA, what's the difference between the one under http/lib? how to re-build it?

2) we are using a different version of IAR (8.42.1), the binary in SDK 7 using 9.21. Do you see any potential issues if we using the binary directly with our application? 

3) if we need rebuild the kernel, can you point to me the instructions on how to build the kernel (and other components) with IAR?

thanks,

Andy 

Thanks for the notification.

Both the Heap (especially the heap of 168KB) and the stack size are indeed to much.

Currently we don't have a good solution for this. We will need to do some profiling to check the sources of the buffer allocated and try to make some optimization.

1) The http_lib_for_OTA allocates bigger internal size for HTTP Request Buffer as needed by both github and dropbox (due to the inclusion of large tokens).

You can basically play with the size (HTTPClient_BUF_LEN) in source/ti/net/http/httpclient_internal.h (and rebuilding the http lib).

2) I can tell about the IAR - if it works and builds ok then you should assume that it is ok.

3) It is doen through makefile see the user guide withing the SDK/docs. Look for "Rebuilding the Libraries".