I confirmed this with FreeRTOS-LwIP, but it works with NETx/ThreadX do you agree?
11:04:58.357: Starting WICED v3.1.0
11:04:58.357: Platform BCM943362WCD4 initialised
11:04:58.357: Started ThreadX v5.6
11:04:58.357: Initialising NetX v5.7_sp1
11:04:58.357: Creating Packet pools
11:04:58.357: WWD SDIO interface initialised
11:04:58.789: WLAN MAC Address : 40:2C:F4:AF:32:F9
11:04:58.789: WLAN Firmware : wl0: Aug 11 2014 17:20:49 version 5.90.195 (TOB) FWID 01-3507525f
11:04:58.805: Joining : BRCMGUEST
11:04:58.805: Successfully joined : BRCMGUEST
11:04:59.397: Obtaining IPv4 address via DHCP
11:04:59.413: Setting IPv6 link-local address
11:04:59.413: IPv4 network ready IP: 10.16.101.6
11:04:59.509: create socket begin
11:04:59.525: create socket end
Thanks for your quick response!
I just test against NetX and NetX_duo now.
Yes, the hangup only happens on FreeRTOS+LwIP.
I have no idea about this issue, it's very basic thing.
We are using FreeRTOS+LwIP so we need bug fix for this hangup issue.
Yes. But at least we have some additional details now to help us debug. Thanks.
I found if I make the socket to be as static variable, it won't hangup on LwIP.
static wiced_tcp_socket_t socket;
Just FYI, maybe it's useful information for debug this issue.
Confirm this issue is fixed in sdk-3.1.1.
wiced_tcp_create_socket in WICED 2.4.1 calls malloc for you (line 151), but no longer does so in 3.1.x, so you must allocate memory in your application.
That explains why it doesn't fail when you declare the variable as static.
What's weird is you said it's fixed in 3.1.1, but I just tested it (and it failed for the same reasons above).