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

9 REPLIES 9
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.

hbucknell
Associate II

There have been a few other minor updates, but here are the files I am now using in case it helps anyone else.

Thank you very much for your answer. Much like the STM boilerplate code, the messaging is falling apart so I'm answering to you here.

unfortunately, there is some other error elsewhere:

void __iar_file_Mtxinit(__iar_Rmtx *lock)

 

It says that there are not enough Mutexes. I'll have to take this with IAR support.
But thank you very much anyways!

Kind regards,
Nikola

Hi Nikola, I believe you can change the number in the stm32_lock.h file, line 256

Hm,
the problem is that the FOPEN_MAX is not defined !?
** Maximum file locks allowed by DLib

Then this code chunk is not executed:

void __iar_file_Mtxinit(__iar_Rmtx *lock)
{
#ifdef FOPEN_MAX
uint32_t index;

STM32_LOCK_BLOCK_IF_NULL_ARGUMENT(lock);

stm32_lock_acquire(&static_file_list_lock);
for (index = 0; index < STM32_LOCK_ARRAY_SIZE(static_file_lock); index++)
{
if (STM32_LOCK_INITIALIZED(&static_file_lock[index]) == 0)
{
*lock = &static_file_lock[index];
STM32_LOCK_INITIALIZED(STM32_GET_LOCK_PTR(lock)) = 1;
stm32_lock_init(STM32_LOCK_PARAMETER(STM32_GET_LOCK_PTR(lock)));
stm32_lock_release(&static_file_list_lock);
return;
}
}

/* Not enough mutexes, this should never happen */
STM32_LOCK_BLOCK();

/* Release of static_file_lock, not possible since STM32_LOCK_BLOCK is invoked */
#else
STM32_LOCK_UNUSED(lock);

/* Not enough mutexes, this should never happen */
STM32_LOCK_BLOCK();
#endif /* FOPEN_MAX */
}


But in the map file I can find it, with __iar_file_ prefix though:
__iar_file_FOPEN_MAX 0x800'6ccd 0x4 Code Gb xfiles.o [19]

Maybe some bs. flag is not defined properly. Not sure if I need to use -Dlib flag during compile. If this is the case, it opens another can of worms for me. Since I need to use libc++,because half of my code won't work, and both is not allowed.

Would you @hbucknell mind sharing your build flags ? (linker and compile) Thank you !

 

Ah sorry, wrong value. For me that is defined in stdio.h

Please find attached the original project (for STM32L476) that I shared with IAR support.

FatTonyStark
Associate II

Thank you so much ! I will try it out ..maybe it'll help.