Error after calling printf

[s_welz]

Hello everyone, 

I'm currently working with the STM32CubeIDE and I'm encountering an error after the new Update 1.13.1. 

After using the printf function the following function in the newlib_lock_glue.c  throws me into the Error_Handler in the main.c, after checking the lock for a NULL value.

__retarget_lock_acquire_recursive(_LOCK_T lock) 
{
 STM32_LOCK_BLOCK_IF_NULL_ARGUMENT(lock); //This line results in the Error_Handler
 stm32_lock_acquire(STM32_LOCK_PARAMETER(lock));
}

This behaviour just started after the version upgrade from 1.12.1 to 1.13.1 of the IDE.
I tried to change the MCU Toolchain settings to the older GNU Tools version (10.3.-2021.10)

now printf works just fine, but if I use the new GNU Tools version (11.3.rel1), which is

the new default setting of the IDE im encountering said Error.

How can this be avoided in the new version of the GNU Tools?

Maybe someone can help me with this issue.
Please inform me if you need further information.

Thanks in advance

[Andrei Chichak]

I'm seeing exactly the same situation with 1.13.0, updated yesterday. 

For another data point, I'm seeing this with a project that was converted from 1.12.1, but when I create a new project for the same processor using 1.13.0, it works properly.

[Andrei Chichak]

I just restored CubeIDE to 1.12.1 and my project back to 3 days ago and it compiles and runs as it did last week.

I would suggest that NOBODY TAKE THE 1.13.[01] UPDATE UNTIL THIS REGRESSION IS HANDLED.

[dave23]

I have the exact same problem. Old project updated to V1.13 stopped working when calling printf. Another old project also updated which doesn't use printf at all, this one runs fine. I added a printf call to this project and it also fails to run, freezing at printf.

I reinstalled 1.12.1 and this solved the issue.

[JTP1]

Hello

Are you using Freertos ? At least without it printf seems to work in project which is generated with 6.9.0 CubeMX and compiled with CubeIDE 1.13.0 at default settings.

Br J.T

[Andrei Chichak]

From the embedded.fm slack (we have the best members ever):

this is a bug in the 11.3.rel1 release of the ARM GNU toolchain - they neglected to include --enable-newlib-retargetable-locking when configuring newlib. (https://community.arm.com/support-forums/f/compilers-and-libraries-forum/54147/gcc-12-2-libc_nano-exporting-retargetable-locking-functions-and-data)

I'm guessing the "fix" that ST are applying in newly generated projects is to remove the newlib glue, but that's a bad idea since it reintroduces issues with reentrancy.

TLDR - moving back to 1.12.1 is the right move.

[dave23]

Do we have any feedback from the devs on this issue? ETA for a fix?

[JE]

Same here.
Moving back to 1.12.1 means reinstalling everything, right? (A lot of work). I could live with it if they fix it in a week or two....

Juergen

[Piranha]

Could be because of this:

https://community.st.com/t5/stm32cubemx-mcu/cubemx-generated-threadsafe-stm32-lock-h-potential-bug/td-p/77220

[bb1]

---

@Andrei Chichak wrote:

this is a bug in the 11.3.rel1 release of the ARM GNU toolchain - they neglected to include --enable-newlib-retargetable-locking when configuring newlib. (https://community.arm.com/support-forums/f/compilers-and-libraries-forum/54147/gcc-12-2-libc_nano-exporting-retargetable-locking-functions-and-data)

STM32CubeIDE doesn't use the ARM GNU Toolchain. ST provides their own build of it called GNU Tools for STM32. It doesn't contain the same error or we wouldn't be stuck in the __retarget_lock_acquire_recursive function defined in the project.