When your thread's stack size is high then chances are there for running out of stack which can cause erratic, difficult to debug behavior. Using 1024 is overkill.
Also cyclic dependencies in your code can also cause deadlocks.
Unfortunately, the device did not advertise also for me with your code.
Thank you for your advice.
To narrow down this phenomenon, we tested single thread with attached source codes.
If "wiced_bt_spp_can_send_more_data" returns FALSE, it is called repeatedly.
CYW20819 aborts SPP transfer on the way then hangs up. (It looks like No response from CYW20819.)
If "wiced_bt_spp_can_send_more_data" returns FALSE, it is called repeatedly until a limitation defined as "MAX_OCCUPATION_TIME".
Then, the thread is released by "wiced_rtos_delay_milliseconds".
If MAX_OCCUPATION_TIME is 50 msec, CYW20819 completes SPP transfer.
If MAX_OCCUPATION_TIME is 100 msec, CYW20819 aborts SPP transfer on the way then hangs up.
From those results, we guess the hung up phenomenon depends on the thread occupation time. How do you think?
We conducted an additional test to narrow down this issue. The source code is attached.
If we add "wiced_hal_wdog_disable()", CYW20819 does NOT hung up and completes the SPP transfer.
Line 334 wiced_hal_wdog_disable();
1) We suspect that CYW20819 hangs up when the watch dog timer(WDT) expire timeout. Is it correct?
2) If 1) is correct, let me ask following questions.
2-1) Do you know recommended way to reset the WDT?
2-2) According to API Reference Guide, timeout value of the WDT is 2sec. But actual timeout value looks like 4 sec under our test. Is it correct?