Whilst developing my server IP socket classes using lwip I came accross a problem with VDK::DestroyMutex being called within a VDK::Thread destructor.
Initially I created a VDKMutex Class to simply wrap the VDK:: calls and hide the MutexID. This class was then included in the VDK::Thread derived class and as such in automatically created and destroyed with the Thread class.
After the VDK::DestroyMutex is called in my app everythig appears to hang, the Statistical profiller shows that nrealy all the processing is now in the IdleThread. Halting the application and looking at the VDK status, all thread are show as Blocked, most on Semaphores but one also on a Message, alot of these are Blocked with timeout and all timeouts have expired.
I've managed to reproduce the issue with a much simple example from the Getting started.
I'm using the EZ-Kit BF548
Open the Getting Started Example_7 ( keypad to led example )
Create a new thread type named Boom using in C
At top of new thread file Add global variable
in Boom_RunFunction remove the while loop so the thread simple creates the dies on completion of Run
in Boom_InitFunction add
mID = VDK_CreateMutex();
in Boom_DestroyFunction add
VDK_DestroyMutex( mID );
In BootThreadType add
if( type == 0x0003 )
VDK_CreateThread( kBoom );
int type = ((keypress.row << 8) | keypress.col);
Run the application
pressing any keypad other than CLEAR will show the ROW/COL as expected on the LEDS.
Once CLEAR is pressed the application still runs (no kernel panic / or other halt error) but the only Thread Operating is the IdleThread.
Does anyone have any idea why this behaviour appear to hang any Pend call in the VDK ??
I know I'll have to refactor the code to put everything in the RunFunction but I'm interested as to whats happening here.