xSemaphoretake blocked cause

Kernel
1

friesen wrote on Thursday, May 24, 2018:

I am incorporating the Microchip Harmony WINC1500 driver into a FREERTOS + Pic32 project. I find that any time the wifi driver is operating normally that I have a task that will never obtain a mutex.

Essentially, the first time a lock is attempted like

xSemaphoreTake(*(SemaphoreHandle_t*)&sqiClientObjMutex, portMAX_DELAY);

It does not get the mutex. Once I call ‘iwconfig mode idle’ and shut down the driver, immediately the mutex is obtained. This is a very limited mutex only found in the sqi driver, so I feel like the cause is not an already taken mutex.

I am a bit puzzled how to debug this and where to start. The Task shows as suspended in RTOSViewer, and the Queuelist shows Sno 1, Pending Messages 2147495336, Length 2147495576, Item Sizes 0.

2

rtel wrote on Thursday, May 24, 2018:

I’m afraid I’m not following any of this. I’m ot famiiar with the
WINC1500 driver and don’t know how it uses semaphores. Are you able to
show some code to demonstrate the issue you are having? Also, when is
the task shown as suspended?

3

friesen wrote on Thursday, May 24, 2018:

This problem was due to a custom malloc that was reinitialized, thus in truth causing double mutex’s being handled out.