STM32CubeIDE 1.13.0 problem

[Phillip Wolstencroft]

I have just updated the IDE from 1.12.1 and updated my project as requested but I have encountered an issue when compiling.

I get 3 errors on previously compiling  source code. as follows

Can you help with what might be the problem?

PhilW

[MGall.11]

Thank you! Now I get it, I didn't notice that those functions are defined in syscall.c. There were no sysmem.c and syscall.c in my old workspace.

[Sylvain_U]

Hi Peter,

my linkerscript checks newly allocated sections and my link now fails because some new inclusions are happening: I had to include in my linkerscript the following for 780 additional bytes:

.libcnano_section :

{

. = ALIGN(16);

*libc_a-aeabi_memset-soft* ( *.text* )

. = ALIGN(16);

*libc_a-aeabi_memset-soft* ( *.rodata* )

. = ALIGN(16);

*libc_a-malloc* ( *.text* )

. = ALIGN(16);

*libc_a-malloc* ( *.rodata* )

. = ALIGN(16);

*libc_a-memcmp* ( *.text* )

. = ALIGN(16);

*libc_a-memcmp* ( *.rodata* )

. = ALIGN(16);

*libc_a-memset* ( *.text* )

. = ALIGN(16);

*libc_a-memset* ( *.rodata* )

. = ALIGN(16);

*libc_a-mallocr* ( *.text* )

. = ALIGN(16);

*libc_a-mallocr* ( *.rodata* )

. = ALIGN(16);

*libc_a-sbrkr* ( *.text* )

. = ALIGN(16);

*libc_a-sbrkr* ( *.rodata* )

. = ALIGN(16);

*libc_a-init* ( *.text* )

. = ALIGN(16);

*libc_a-init* ( *.rodata* )

. = ALIGN(16);

*libc_a-lock* ( *.text* )

. = ALIGN(16);

*libc_a-lock* ( *.rodata* )

. = ALIGN(16);

*libc_a-aeabi_memclr* ( *.text* )

. = ALIGN(16);

*libc_a-aeabi_memclr* ( *.rodata* )

. = ALIGN(16);

*libc_a-memcpy-stub* ( *.text* )

. = ALIGN(16);

*libc_a-memcpy-stub* ( *.rodata* )

. = ALIGN(16);

*libc_a-mlock* ( *.text* )

. = ALIGN(16);

*libc_a-mlock* ( *.rodata* )

. = ALIGN(16);

*libc_a-impure* ( *.text* )

. = ALIGN(16);

*libc_a-impure* ( *.rodata* )

. = ALIGN(16);

*libc_a-impure* ( *.data* )

. = ALIGN(16);

} >MY_ROM_SECTION

which is indeed incorrect as I allocated some data in the flash, but mostly incorrect because I had to allocate new sections.

All happens as if the --specs=nano.specs linker directive was not taken into account, or not enough?

In the linker settings of the project, this is my 'All options' field which was working fine with stm32cube IDE 1.12:

-mcpu=cortex-m33 -T"/my_project/linkerscripts/Linkerscript_STM32U585_standalone_btl.ld" --specs=nosys.specs -Wl,-Map="${BuildArtifactFileBaseName}.map" -Wl,--gc-sections -static -L"lib_path1" --specs=nano.specs -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mthumb -Wl,--start-group -lc -lm -Wl,--end-group

Please check whether directive --specs=nano.specs is correctly taken into account and if yes, why some new allocations occur.

Thank you

Best regards

Sylvain

[ANauz.1]

So....

On October 31, more than 3 month after, the last version 1.13.2 as not been updated and the problem is still present.

Seriously ST, this is not professional at all! Could you test the version you are releasing!! And provide fast correction when you are not capable to test?!!

We have other thing to do than loosing days because of your poor release!!

[Sylvain_U]

Hi,

I've been able to solve the issue:

- in the STM32CubeIDE project/properties of your build configuration linker settings, use "do not use system calls from library" and mark box "do not use standard start files"

-the library to reference in your linkerscript becomes libc_a-* instead of lib_a

I also had to create an empty void _init(void) function.

Now my project compiles and links properly, seemingly without major differences with the compiles from 1.1.12 STM32CubeIDE.

I guess, the arm-gcc compiler version was updated...

Hope this helps,

Sylvain

[_nuvw_]

Thanks Peter ! It's working for me too.

[ANauz.1]

So, I still have problems with the GCC from STM32CubeIDE version 1.13.2, and no workaround is working for me.

So fare:

• My project is compiling perfectly fine with CMake and GCC from IDE version 1.12.1
• When changing to GCC from IDE 1.13.2 (and changing only that), I have link error.
• After copying sysmem.c and syscalls.c from a new project generated with IDE 1.13.2, I still have errors:

C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-closer.o): in function `_close_r':
(.text._close_r+0xc): warning: _close is not implemented and will always fail
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-lseekr.o): in function `_lseek_r':
(.text._lseek_r+0x10): warning: _lseek is not implemented and will always fail
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-readr.o): in function `_read_r':
(.text._read_r+0x10): warning: _read is not implemented and will always fail
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-writer.o): in function `_write_r':
(.text._write_r+0x10): warning: _write is not implemented and will always fail
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: CMakeFiles/CLEANSD.dir/Core/Src/syscalls.c.obj: in function `_exit':
C:/Work/Project/Core/Src/syscalls.c:57: multiple definition of `_exit'; C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libnosys.a(_exit.o):(.text._exit+0x0): first defined here
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: CMakeFiles/CLEANSD.dir/Core/Src/syscalls.c.obj: in function `_close':
C:/Work/Project/Core/Src/syscalls.c:93: multiple definition of `_close'; C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libnosys.a(close.o):(.text._close+0x0): first defined here
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: CMakeFiles/CLEANSD.dir/Core/Src/syscalls.c.obj: in function `_lseek':
C:/Work/Project/Core/Src/syscalls.c:114: multiple definition of `_lseek'; C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libnosys.a(lseek.o):(.text._lseek+0x0): first defined here
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: CMakeFiles/CLEANSD.dir/Core/Src/sysmem.c.obj: in function `_sbrk':
C:/Work/Project/Core/Src/sysmem.c:54: multiple definition of `_sbrk'; C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libnosys.a(sbrk.o):(.text._sbrk+0x0): first defined here
C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: Libs/libPrintf/liblibPrintf.a(libPrintf.c.obj): in function `_write':
C:/Work/Project/Libs/libPrintf/libPrintf.c:48: multiple definition of `_write'; C:/ST/STM32CubeIDE_1.13.2/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.1.202309131626/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard\libnosys.a(write.o):(.text._write+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Is there any other workaround to use?

Do ST plan to release a corrected version of STM32CubeIDE version 13? First mentions of the problems are more than 3 month old! Or should I go back to version 1.12 and never update any more?

[Brian TIDAL]

Hi ANauz.1

Those issues are not a bug or a defect from the latest STM32CubeIDE. This is a generic issue of gcc libraries causing a warning at linking stage.

“warning: _close is not implemented and will always fail” is not a linker error but a warning placed inside the recent implementation of libnosys as part of gcc libraries. This libnosys provides dummy system calls (read/write/close/lseek) and kindly warns the user during linking stage that any attempt to use those system calls will fail (as this is a dummy implementation). As explained, this is ‘just’ a warning, and the linker is able to generate a proper ELF file. As long as your application does not use read/write/close/lseek (which should be the case for a bare metal application), your application will run properly.

So,

• the first option is to ignore those warnings.
• A second option is to patch the libnosys.a to get rid of those warnings (see stackoverflow discussion below).
• A third option is to provide your ‘own’ implementation of the system calls. You can simply generate a new STM32CubeIDE project with STM32CubeMX and reuse the syscalls.c and sysmem.c files in your initial project.
• and all other options suggested in this thread (use older toolchain, etc.).

Regarding the multiple definition linker error in your application, this is likely caused by a duplicated object file having the system calls symbols or a duplicated syscall source file: clean your build directory, make sure your source files do not contains several definitions of those system calls. The linker map file should help to find the root cause of the duplicate symbol definition (or use linker verbose mode).

See also

• Compilation erros after migrating to STM32CubeIDE ... - STMicroelectronics Community
• https://stackoverflow.com/questions/73742774/gcc-arm-none-eabi-11-3-is-not-implemented-and-will-always-fail
• https://community.arm.com/support-forums/f/compilers-and-libraries-forum/53519/arm-gcc-11-3-rel1-newlib-nano-linker-warning-_read-is-not-implemented-and-will-always-fail
• https://metebalci.com/blog/demystifying-arm-gnu-toolchain-specs-nano-and-nosys/ 

Rgds

BT

[catraeus]

Subverting fundamentally deep functionality like this is always dangerous, even with the weak attribute.  I found that the old syscalls.c in the previous version had a #if 0 that blocked out the implementations of the _open _close etc.  Removing those #if / #else made the two different versions identical and now the linker doesn't fail (warn).  NOW ... why had they been #if'd out in the past ... we'll see ...

[catraeus]

1.) find your old version of syscalls.c

2.) find the #if 0 and matching #endif

3.) remove them.

4.) enjoy!

[Mohammed Eshaq]

This problem has been resolved with the latest update from STM32 CubeIDE. Just update your IDE and make sure you are using the following Toolchain: 11.3 rel 1.