STM32CubeMX with IAR, C++, FreeRTOS and multi-thread support - hanging in startup before main

[hbucknell]

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?

[hbucknell]

It appears that __dlib_thread_safety_init() is not being called. As this is where __iar_Initlocks() is called from. Still invetigating.

[hbucknell · Accepted solution]

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,

1. Linker -> Extra Options ->  --manual_dynamic_initialization
2. Refactor "__attribute__ ((constructor)) void __dlib_thread_safety_init()" to "void __dlib_thread_safety_init()"
3. Early in main(), beofre any C++ code is called,

1. Declared “extern void __dlib_thread_safety_init();”
2. Called the following at the beginning on main,
3.     __dlib_thread_safety_init();
4.     __iar_cstart_tls_init(NULL);
5.     __iar_dynamic_initialization();

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,

• __iar_system_Mtxlock
• __iar_system_Mtxunlock
• __iar_file_Mtxlock
• __iar_file_Mtxunlock

I hope this helps someone facingteh same issues we have been facing.

H.