That's what I did and started digging.

But in the end, you are correct. It was the stack size. 
TI uses three different places that control different stack sizes.
Ultimately I got it working with a stack of 32K.

(It also helps to actually put an "0x" in front of them.  Otherwise it uses the decimal value, which is substantially smaller - Opps)

Working now.  Thanks for the clues.

Another tool to help determine the stability of wolfSSL is to run the wolfCrypt test application:
https://github.com/wolfSSL/wolfssl/tree … crypt/test

That didn't work...

I tried NOT loading the roots CA's (only two of them), but it still crashes.  (they actually fail anyway, due to the clock not being set...  That's another issue, how does WolfSSL get the date n the TI embedded system??)

The CA's are only connecting to a cert that is 2048 bit.

I set the

#define RSA_LOW_MEM

  but it still crashes.

I increased the stack size from 65536 to 98304  (that 1 1/2 times 0x10000 ), but it still crashes.

It appears something is wandering off the reservation and destroying memory that doesn't belong to it.  Because the TI NDK memory is getting screwed with.

This all works fine when I client connect to IIS WITHOUT using SSL.

And our server component (not yet integrated in this test app I'm working on) supports public 4096 keys without setting the #define or increasing the stack from the 65536 we currently use.  So I think we have enough memory for these smaller Pub/Priv keys.

I am trying to get a client connection to an IIS server. It all works fine in Windows, using a typical TCP connection, linked to a WolfSSL library built with the VS solution file as is from release 4.7.0.

It refuses to work in TI RTOS ARM.  I am coding for the am335x, TI Compiler 17.3, SYSBIOS 6.46

I've been dealing with this for a week, and not getting anywhere.  I've even had to step down into the WolfSSL code trying to debug it.

After MANY REPEATED rebuilds and attempts, I have narrowed it down to enabling:

#define WOLFSSL_SHA384
#define WOLFSSL_SHA512

Simply put:  with those defined, it CRASHES in ecc.c, line 2374 in the function

err = mp_invmod_mont_ct(z, modulus, t1, mp); 

I have not dug any deeper than that into the WOLFSSL code.

Alternately, if I do NOT define those directives, it simply returns from the call to

 result = SSL_connect(m_ssl);

with a code -308  (socket in error condition) which is the result of the server disconnecting on the first Client Hello message.

I keep dragging settings from the Windows build to the TI ARM build to see when it will start working.  All it does is crash with those settings defined.

I've tried to read the doc in order to figure out what #defines need to be defined, with no avail.  There is nothing that tells me "You must enable X if you enable "Y" or it'll crash hard.

The current setting I have defined in "user_settings.h" are:

#define OPENSSL_EXTRA        /*   */

//  From the "settings.h"
    #define FP_MAX_BITS 8192        /*  Increase for 4096 bit key */
    #define USE_CERT_BUFFERS_2048
    #define HAVE_ECC
    #define HAVE_ALPN
    #define USE_WOLF_STRTOK /* use with HAVE_ALPN */
    #define HAVE_TLS_EXTENSIONS
    #define HAVE_AESGCM

//  New settings, trying to get client to connect
#define    WOLFSSL_AES_256
//#define WOLFSSL_SHA384
//#define WOLFSSL_SHA512

#define NO_PSK
#define HAVE_AESGCM
#define ECC_USER_CURVES
#define ECC_SHAMIR
#define WOLFSSL_RIPEMD
#define HAVE_EXTENDED_MASTER

This is the crash from the ARM.  The DFSR shows an access issue, and the DFAR shows address 0

[CortxA8]  0x805dd620  R8  = 0x805d6458
R1 = 0x00000000  R9  = 0x805d6614
R2 = 0x805d661e  R10 = 0x00000e3a
R3 = 0x00000000  R11 = 0x00000000
R4 = 0x00000000  R12 = 0x00000000
R5 = 0x00000000  SP(R13) = 0x805b26e0
R6 = 0x00000001  LR(R14) = 0x804bf1ac
R7 = 0x805dd644  PC(R15) = 0x805b26e0
PSR = 0x00000001
DFSR = 0x00000005  IFSR = 0x00000000
DFAR = 0x00000000  IFAR = 0x00000000
ti.sysbios.family.arm.exc.Exception: line 205: E_dataAbort: pc = 0x805b26e0, lr = 0x804bf1ac.
xdc.runtime.Error.raise: terminating execution

Can anyone clue me in to which of these settings are required to make it simply connect to a IIS server?

-Scott