2026-03-12 11:37 AM - edited 2026-03-12 12:08 PM
Hi,
MCU - STM32H7 family
MCU package: FW_H7 V1.11.2
FreeRTOS
Enable Multi-threaded support -> Thread-safe locking strategy "FreeRTOS strategy #4 - Allow lock usage from interrupts"
the issue:
When I'm writing a file in Flash, I reach the main.c::void Error_Handler(void) while loop.
in the stack, I see that the last steps was in newlib_lock_glue.c:
void Error_Handler(void)
static inline void stm32_lock_acquire(LockingData_t *lock)
void __retarget_lock_acquire_recursive(_LOCK_T lock)
__fflush_r()
_swbuf_r()
_putc_r()
_fputc_r()
After investigation I see that the Error_Handler reached because the lock object reached is limit 2.
The lock LockingData_t struct defined in ST file stm32_lock.h (line 255):
#define STM32_LOCK_MAX_NESTED_LEVELS 2 /**< Max nesting level of interrupts */
typedef struct
{
uint32_t basepri[STM32_LOCK_MAX_NESTED_LEVELS];
uint8_t nesting_level;
} LockingData_t;
When I'm set the STM32_LOCK_MAX_NESTED_LEVELS to 5, problem solved and I succeed to write the file.
But i set it manually directly in the file, and its wrong as stm32_lock.h is ST file.
I have few question about it:
1. As I understand, STM32_LOCK_MAX_NESTED_LEVELS allow to nested interrupts, and hold them. Right?
2. What is the issue root cause? why the interrupts wasn't released and handled?
3. What is the meaning of increase the STM32_LOCK_MAX_NESTED_LEVELS? it can to cous any issue?
4. Why it set to 2 in the first place?
there is any option to configure it from the IOC and not manually?
what is the solution for that?
@hbucknell I see that u replied on something related to it, I will appreciate any idea :)
tnx a lot !
++the ST files: stm32_lock.h, newlib_lock_glue.c
2026-03-12 1:30 PM - edited 2026-03-12 1:54 PM
Using something that requires locks in interrupt handlers is begging for trouble. Please reconsider.
( The nesting issue will disappear, as a side effect.)
2026-03-15 1:16 AM
HI,
tnx for replay.
do u mean about the RTOS strategy - ""FreeRTOS strategy #4 - Allow lock usage from interrupts" ?
This is ST strategy, So, I can't trust the ST strategy to handle any issues like that?
2026-03-15 3:22 PM
Yes, "strategy #4 - Allow lock usage from interrupts". Just don't use locks from interrupts, therefore don't select this option.
Sometimes interrupts are used as "poor man scheduler", then one may need locks in handler context - but with a real RTOS such as FreeRTOS there's no reason for this.