BT stack sometimes forgets to unlock mutex

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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.

0 Likes
2 Replies
Anonymous
Not applicable

Hi.

Is this problem in realease mode same like debug?

Freertos in debug mode have big periodic latency about 2ms, because it doing memory tests.

In realease mode this test are disabled.

0 Likes
Anonymous
Not applicable

Thanks for the input, but aren't you talking about LwIP now? I know about LwIP's dramatic slowdown when it checks its buffers every now and then, and yes, I have "DEBUG" defined when compiling so *if* FreeRTOS have some memory checking going on, it will be enabled. But wouldn't that also depend on the memory allocator used?

Anyway, I really think a proper multi-thread implementation (the BT stack in this case) should *not* depend on such timings, it shouldn't depend on *any* timing to work. That's more or less the definition of the phrase "atomic operation".

0 Likes