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.

 

 

[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.

[KHors.1]

Wrong. The release note for CubeIDE 1.13 clearly states the exact version of the ARM GNU Toolchain version which is being shipped with CubeIDE.

" It doesn't contain the same error or we wouldn't be stuck in the __retarget_lock_acquire_recursive function defined in the project.I".
The default implementation obviously contains empty stubs because the default is non-thread aware. These weak stubs are overridden by the RTOS-aware implementation.
The same firmware package 1.18 for STM32L4 worked fine with CubeIDE 1.12.x. Thus the regression must come from the newer ARM GNU Toolchain.
Don't know if ST re-compiles it from the sources, and just forgot to configure it correctly, or the embedded Newlib has actually developed this regression. 

[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]

This is a bug in newlib that has since been fixed. Initialization of the lock in each standard stream was unintentionally removed during refactoring. It looks like ST noticed it a few weeks after the upstream 11.3.Rel1 release came out and submitted a patch to the newlib project. Unfortunately they did not include the fix in their newlib build nor add it to their list of known issues. You can verify by checking the disassembly of the std function. It doesn't call anything besides memset.

Here's a workaround:

 

#include <stdio.h>
#include <sys/lock.h>

// Insert this somewhere before first use of standard streams. One of the the
// user code sections near the top of main is a good place.
#if __NEWLIB__ == 4 && __NEWLIB_MINOR__ == 2 && __NEWLIB_PATCHLEVEL__ == 0 && !defined(__SINGLE_THREAD__)
 // The version of newlib bundled with GNU Tools for STM32 11.3.rel1 fails to
 // initialize the locks in the standard streams.
 if (!stdin->_lock)
 __lock_init_recursive(stdin->_lock);
 if (!stdout->_lock)
 __lock_init_recursive(stdout->_lock);
 if (!stderr->_lock)
 __lock_init_recursive(stderr->_lock);
#endif

 

Also, if you're using STM32_THREAD_SAFE_STRATEGY == 4, see the link that Piranha posted. It's not the problem here, but it is a problem. If you aren't using anything that requires a lock from an ISR, which you shouldn't be, switching to #5 is the easiest way to resolve it.

[MSatt.4]

Can also just install the previous toolchain easily enough...

[Marcelo Jimenez]

Installing GNU Tools for STM32 version 10.3 worked perfectly for me. Printf stopped calling the error handler. Thanks!