The problem I encountered in this thread, rfcomm cant reopen, seemed to have been fixed in 3.7. I'm not able to reproduce that exact problem, but a very similar one can be reproduced by lowering the clock speed to very low frequencies, like 12MHz.
When I do that, and open an rfcomm connection, I very often get problems locking mutexes from the BTU, READ_THREAD and HCISU threads. If I log all mutexes locked/unlocked from those threads, I can see that one of the threads pretty often forgets to unlock a mutex. It's not just a matter of several threads competing about the same mutex, one thread really forgets to unlock it, because I can see in the log that a thread locks it, then doesn't execute for a while, and during that time another thread fails to lock it, and after that the first thread locks it again (which it of course shouldn't need to do since it already had the mutex locked.)
Also, it's not just one thread forgetting to unlock it, it can be either one of those 3.
This is why I really try to avoid closed source software. It's impossible to fix problems you encounter, the only thing I can do is half-working workarounds, in this case, instead of using a xSemaphoreTake waiting FOREVER (in wiced_rtos.c wiced_rtos_lock_mutex), I use a 1 second timeout and simply pretend to have locked it if it times out. By doing that, the thread thinks it has locked it and can unlock it as usual when it's done. Of course it's a bit dangerous, but it's the best I can do without the source.
Please fix it on your end proper. If you *really* want to, I might be able to debug which function is locking the mutex and then forgets to unlock it.
