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.
2024-11-11 06:49 AM
2024-11-11 06:59 AM
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
2024-11-11 07:06 AM
Hi Nikola, I believe you can change the number in the stm32_lock.h file, line 256
2024-11-11 07:24 AM - edited 2024-11-11 07:24 AM
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 !
2024-11-11 07:36 AM
Ah sorry, wrong value. For me that is defined in stdio.h
2024-11-11 07:50 AM
2024-11-12 12:23 AM
Thank you so much ! I will try it out ..maybe it'll help.