2023-09-25 08:58 AM
STM32CubeMX 6.9.1 and IAR 9.32.1 on Nucelo_L476RG
When enabling multi-threaded support for our FreeRTOS project in STM32CubeMX I am seeing builds of the binary that during startup (before reaching main) there are calls to __iar_system_Mtxlock() (dlib_lock_glue.c) before __iar_system_Mtxinit() and as the locks are not initialised, the system hangs in Error_Handler().
Is there anything I need to do to do in startup for this to work correctly?
Solved! Go to Solution.
2023-11-30 08:55 AM
Hello ST,
I have fixed this with support from IAR. dlib_lock_glue.c from STM32CubeMX is at fault.
ST: please can you update the dlib locking code as generated in CubeMX?
To fix this issue requires the following steps,
Also, the mutex lock/unlock functions in dlib_lock_glue are wrong, the ones generated for the STM32CubeIDE are correct, but the IAR ones are out-of-date.
References to "static_system_list_lock" and "static_file_list_lock" in the following functions (and only the following functions) should be deleted/commented out,
I hope this helps someone facingteh same issues we have been facing.
H.
2023-09-25 09:17 AM
It appears that __dlib_thread_safety_init() is not being called. As this is where __iar_Initlocks() is called from. Still invetigating.
2023-11-30 08:55 AM
Hello ST,
I have fixed this with support from IAR. dlib_lock_glue.c from STM32CubeMX is at fault.
ST: please can you update the dlib locking code as generated in CubeMX?
To fix this issue requires the following steps,
Also, the mutex lock/unlock functions in dlib_lock_glue are wrong, the ones generated for the STM32CubeIDE are correct, but the IAR ones are out-of-date.
References to "static_system_list_lock" and "static_file_list_lock" in the following functions (and only the following functions) should be deleted/commented out,
I hope this helps someone facingteh same issues we have been facing.
H.