cancel
Showing results for 
Search instead for 
Did you mean: 

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

hbucknell
Associate II

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?

1 ACCEPTED SOLUTION

Accepted Solutions
hbucknell
Associate II

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.

View solution in original post

2 REPLIES 2
hbucknell
Associate II

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

hbucknell
Associate II

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.