Wi-Fi Combo Forum Discussions

I could not figure out why wiced_tcp_receive() fatally fails when the server is trying to send packets of about 1k or larger. Not only wiced_tcp_receive() fails with WICED_ERROR but it is unable to receive any packets, evan smaller than 1k, after the first failure.

I have tried to change the WICED_TCP_WINDOW_SIZE as hinted in another thread, and to increase the application stack but with no luck.

I am using SDK 2.1.1 and LwIP with TLS enabled, but it happens with NetX as well. This problem does not appear if I disable TLS. It looks like if the library is unable to break down reception in multiple packets with TLS enabled, because when used without TLS, wiced_tcp_receive() returns multiple times with total packet sizes that fail with TLS.

Please advise.

Thanks,

Marco G.

hi jason:

In WICED-EUM201-R.pdf, it mention we can use jlink to download image. after i added a jtag=jlink option, but i failed to download image into board. I tested in customer board, so i want to know can we use jlink to download image? thanks

BR

Im trying to bring over an application in development on an STM32F205 from 2.2.1 to 2.3.1 due to the bootloader bug with C++ contructors (dont ya love the difference between extern * and extern []?).

Everything seems to be working except that the uart used for stdio becomes deinitialized sometime during the boot; if i disable the error checking in wiced_uart_init, and initialize the uart again after wiced_init, stdio will work again. While this is a workaround, it doesnt truly address the issue and will certainly lead to problems in the future.

I have confirmed that it is operating prior to the call to host_platform_init inside of init_architecture, and up to the wiced_gpio_init in platform_reset_wlan_powersave_clock, but seems to fail after MCU_CLOCKS_NEEDED in wiced_gpio_init.

init_architecture->host_platform_init        // good here

host_platform_init->wiced_gpio_init         // still good...

wiced_gpio_init->MCU_CLOCKS_NEEDED   // fails somwhere in this call...

Has anyone else experienced this? Can anyone point me in the right direction to fix this?

I have an odd problem where when I specify the -debug flag in my make target the HTTP library causes a socket to be created with a TLS context that eventually fails since my server is unencrypted. Let me give you a bit of background....

My test device is an Inventek 4319 evaluation board.

Im using the standard WICED IDE v2.2.1 w/Inventek "patch"

My app is using the included http library, more specifically the methods in http_stream.c to send data to my "server". The data is a JSON encoded string.

The server at this stage in the game is either netcat or a custom Java based app. Both used for testing and will report data. Both not using TLS or any kind of security.

My build string in debug mode is : axeda.dataAgent-ISM4319_M3G_L44-debug download run 

My build string in normal mode is:  axeda.dataAgent-ISM4319_M3G_L44 download run

In debug mode:

There are no compilation errors. When the app runs it creates the message correctly, but when it tries to connect it prints a "Error with TLS handshake" message and goes into a hard fault state(the red LED is on solid.

In normal mode:

When I dont have the debug string in the make target the program runs but fails after the data is sampled and never says "Error with TLS handshake", instead it restarts. Obviously I have some issue there, but its hard to debug when debugging causes a different behavior.

Is there some option or flag I need to set to prevent the sequence of events from happening?

Could it be that http_init_stream always creates a secure socket and its just reported in Debug mode rather than in normal mode?