USBX Mutex does not work - CubeMX code generator BUG

[matt-crc]

Hello, I'm trying to implement a USBX host... and the code generates a lot of runtime errors.  I assume everything is setup properly from CubeMX, but the code always fails. 

 

1- I see that the mutex was created from the debug session: (ux_system_mutex)

2- the system fails when trying to initialize the UX system.

3- The error came from _ux_utility_mutex_on() and generates an error code 0x04

VOID _ux_utility_mutex_on(UX_MUTEX *mutex)
{

UINT status;

 /* Call ThreadX to get system mutex. */
 status = tx_mutex_get(mutex, TX_WAIT_FOREVER);

 /* Check for status. */
 if (status != UX_SUCCESS)
 {

 /* Error trap. */
 _ux_system_error_handler(UX_SYSTEM_LEVEL_THREAD, UX_SYSTEM_CONTEXT_UTILITY, status);
 }

 /* Return to caller. */
 return;
}

so, it is trying to get the mutex (ux_system_mutex) and then wait forever....

4- If I look at the AzRTOS manual: 0x04

5- The base code was auto generated by CubeMX.  So basically it is trying to initialize memory using a mutex before starting the threads....

6- to make matters worse, the error code (status) is not passed to the calling function properly, so it took a lot of time to find this problem, and the ux_error_handlers does absolutely nothing (ie no while(1))

 

[FBL]

Hi  @matt-crc 

Would you attach ioc file to reproduce?

[matt-crc]

Hi @FBL 

This is my first project with STM32, so I'm not too familiar on how ST works... so I have 3 questions:

1- How long does it usually take for ST to analyze and fix the problems reported (weeks, months, etc)? and how often do you release updates?

2- Do you know of a way to disable the auto-code generator from updating a particular file? (for example if I fix this problem in app_azure_rtos.c, I don't want CubeMx to update this file anymore.)

3- It would be really nice if CubeMX always added a user area at the very beginning of the file and a user area at the end of the file to all generated files, then users can disable the updating of a file. This would fix item #2 above.  Can this be done for all your files? (example shown below)

/*User code begin - start of file */
/*User code end - start of file */
----
CubeMX code will be updated in this area
----
/* User code begin - end of file */
/* User code end - end of file */

 then our code would look like this:

/*User code begin - start of file */
#ifdef (USE_CUBEMX_CODE)
/*User code end - start of file */
----
CubeMX code will be updated in this area
----
/* User code begin - end of file */
#endif
----
User code will remain untouched here - for bug fixes and enhancements
----
/* User code end - end of file */

[FBL]

Hi @matt-crc 

An internal ticket is submitted to dedicated team to fix initialization order in app_azure_rtos.c (204777)
Another ticket is submitted to Tools team to add user section at the end of app_azure_rtos.c file to make it more customizable (204781).

[matt-crc]

Hi @FBL 

see attached

Matthew

 

[FBL]

Hi @matt-crc @a.gajdacs 

Regarding the mutex operation is being called before threadX scheduler has started.

I got the confirmation, you need to avoid initializing USBX stack before starting the ThreadX. This is a known limitation in USBX.

[matt-crc]

Hi @FBL 

you're too funny... I guess you should inform your programmers because the base code was from your examples.  Since it was 6 months ago, I don't remember which USBX H7 it was from, but I'm pretty sure they all do it.

Matt