Hi
I am using KDS 3.0.0 and KSDK 1.3.0 on a Windows 10 platform developing for a Kinetis K20 MK20DX256VLK10
When I select the Processor Expert Demo USB HID code the resultant code always crashes on startup when calling OSA_MutexLock()
The processor is halted in the asset(pMutex); as the pMutex pointer is NULL.
If I add some code to check for and bypass null pMutex pointers then the code runs fine and the USB Demo works as expected.
This is the code I added to the start of the Lock and Unlock functions.
osa_status_t OSA_MutexLock(mutex_t *pMutex, uint32_t timeout)
{
#if 1
// SEAN: Check for null pointer and return as otherwise CPU hangs in the assert
if ( pMutex == NULL )
{
nullMutexLockCounter++ ;
return kStatus_OSA_Idle;
}
#endif
#if (FSL_OSA_BM_TIMER_CONFIG != FSL_OSA_BM_TIMER_NONE)
uint32_t currentTime;
#endif
assert(pMutex);
osa_status_t OSA_MutexUnlock(mutex_t *pMutex)
{
#if 0
// SEAN: Check for null pointer and return as otherwise CPU hangs in the assert
if ( pMutex == NULL )
{
nullMutexUnlockCounter++ ;
return kStatus_OSA_Success;
}
#endif
assert(pMutex);
I can also see from the counters I added that the Lock and Unlock is called continously with a null pointer. This would suggest a mutex needed by the FSL USB Driver is not getting created on initialisation.
Attached is a screenshot showing the stack trace when the processor crashes in the mutex call. Also my modified fsl_os_abstraction_bm.c file.
This problem might be related to my other USB Issue (that of adding a 2nd endpoint) as described in thread 384023 USB Driver Issues on K20 with KDS/KSK demo code
My workaround works but could there be an underlying problem if the USB Driver cannot correctly create and use its mutex?
regards
Sean
Original Attachment has been moved to: fsl_os_abstraction_bm_modified.c.zip
Solved! Go to Solution.
Hello Sean,
If fact, this problem is related to allocation memory scheme.
In KSDK 1.3, when you use PEx, you are also importing the fsl_misc_utilities.c file (located at: SDK > platform > utilities > src > fsl_misc_utilities.c) where _sbrk function is declared and it is used to allocate memory. However, there is no definition for HEAP size so this function cannot allocate memory.
In USB stack, a mutex is created and it calls the _sbrk function, but, like this function does not define HEAP size, there is no memory to be used and mutex allocation fails (But USB stack does not uses a warning or validate if Mutex was created correctly and it never takes care about it, fortunately, this bug has been resolved in future releases).
So there are two different ways to solve this issue:
For first solution, you will only need to "Exclude from Build..." the fsl_misc_utilities.c function. Right click under fsl_misc_utilities.c file and select the Exclude From builiding... option located in Resource Configurations. After this, compile the project again and it should work.
The second solution is to add a HEAP size definition in linker configuration, right click under project and select "properties", then, on C/C++ Build, select the Settings option and then locate Cross ARM C++ Linker. In this section, you can see the Miscellaneous option and a field where you can add next definiton -Xlinker --defsym=__heap_size__=0x400. Add this HEAP definition and then compile the project again and it should work without excluding fsl_misc_utilities.c file.
I hope this can help you,
Best Regards,
Isaac
----------------------------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
----------------------------------------------------------------------------------------------------------------------------------------
Hello Sean,
If fact, this problem is related to allocation memory scheme.
In KSDK 1.3, when you use PEx, you are also importing the fsl_misc_utilities.c file (located at: SDK > platform > utilities > src > fsl_misc_utilities.c) where _sbrk function is declared and it is used to allocate memory. However, there is no definition for HEAP size so this function cannot allocate memory.
In USB stack, a mutex is created and it calls the _sbrk function, but, like this function does not define HEAP size, there is no memory to be used and mutex allocation fails (But USB stack does not uses a warning or validate if Mutex was created correctly and it never takes care about it, fortunately, this bug has been resolved in future releases).
So there are two different ways to solve this issue:
For first solution, you will only need to "Exclude from Build..." the fsl_misc_utilities.c function. Right click under fsl_misc_utilities.c file and select the Exclude From builiding... option located in Resource Configurations. After this, compile the project again and it should work.
The second solution is to add a HEAP size definition in linker configuration, right click under project and select "properties", then, on C/C++ Build, select the Settings option and then locate Cross ARM C++ Linker. In this section, you can see the Miscellaneous option and a field where you can add next definiton -Xlinker --defsym=__heap_size__=0x400. Add this HEAP definition and then compile the project again and it should work without excluding fsl_misc_utilities.c file.
I hope this can help you,
Best Regards,
Isaac
----------------------------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
----------------------------------------------------------------------------------------------------------------------------------------
Hi Issac
Thank you for the quick response. I tried the first option of excluding fsl_misc_utilities.c and it worked. I no longer see null mutex pointers in the lock and unlock functions.
I was hoping it might also be a resolution for my other USB Driver issue, see USB Driver Issues on K20 with KDS/KSK demo code but I still have this other problem.
I am struggling to get the USB HID Driver working for two endpoints (one is fine) using PE for a K20 processor. Any help you can provide with this would be much appreciated.
Thanks again for your help.
Sean