AWS IoT and HTTPS are mutually failed

[chegewara]

Are you sure you are using CA cert, not intermediate cert?

[chrismerck]

Hey Samson, for what it's worth, I use multiple SSL connections simultaneously (AWS IoT over TLS with certificate validation) and HTTPS using mbedtls socket (although I'm not sure whether the certificate validation is being performed, we don't care in our application). --- No problems thus far. [EDIT: In fact, we have automated tests that perform 5x simultaneous HTTPS downloads and it performs just fine.]

[samsonch]

OK, I sort of found the problem but I don't have any solution yet.

This is nothing to do with the CA or mbedtls. The Bluetooth init causes all that problems. I don't know why. If I didn't create the Bluetooth task, everything worked great. If I enabled the Bluetooth task, only one of MQTTS or HTTPS worked and the other one would get the error from the esp-tls. It sounds like a memory problem. I checked the stack high water mark, it looked OK. I tried to increase the Bluetooth stack size, it did not work.

I also tried to do a similar thing on a small sample project, but that one worked ok. Still a myth to me!

Samson

[samsonch]

I finally found the final answer. It was caused by the stack overflow. Which stack? I don't know. But when I reduced the size of each my stacks, it worked. I used stack high water mark to check some stacks, including the system stacks, I could reach out but found none. Anyway, it works now.

Samson

[JimmyPedersen]

I finally found the final answer. It was caused by the stack overflow. Which stack? I don't know. But when I reduced the size of each my stacks, it worked. I used stack high water mark to check some stacks, including the system stacks, I could reach out but found none. Anyway, it works now.

Samson

Are you sure it's not the heap that gets too small when the stack is set high causing the xalloc's to fail?
If you get stack overflow you should need to increase the stack size, not decrease it.

[samsonch]

Hello Jimmy,

You are probably right. However, I tried to check the usages of all stacks I can find. For those, all the high water marks were still a big number. There are some system/SDK created tasks that I don't know. So, you are probably right about those stacks that I didn't check. What I reduced are the stacks under my control. Then the saved space may leave some more memory for the heap or those hidden stacks. That was what I did.

Samson

[samsonch]

By the way, I did enable the Heap Memory Debugging on the problematic build, and there wasn't any memory corruption event. So I really don't know what really caused that.