search

STMicroelectronics / STM32CubeF7

STM32Cube MCU Full Package for the STM32F7 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
320 stars 191 forks source link

Files syscalls.c missing in SW4STM32 examples for NUCLEO-746ZG, Nucleo-F722ZE... #99

Closed pavel-a closed 10 months ago

pavel-a commented 11 months ago

Syscalls.c files are present in projects for other boards, see here: https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F767ZI-Nucleo/Examples/UART/UART_Printf/SW4STM32

But missing for NUCLEO-746ZG:

https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F746ZG-Nucleo/Examples/UART/UART_Printf/SW4STM32

Same for other boards: https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F722ZE-Nucleo/Examples

This leads to non-building, non-working examples.

Proposal: A. put the syscalls.c in each SW4STM32 project. B. The example import tool of CubeIDE should add syscalls.c if missing.

TOUNSTM commented 11 months ago

Hello @pavel-a,

Thank you for this report. We will get back to you as soon as we analyze it further. This may take some time. Thank you for your comprehension.

With Regards,

ASELSTM commented 10 months ago

Hi @pavel-a,

Following your request, we have tried to reproduce the issue. We have thus compiled the project you have mentioned UART_Printf using SW4STM32 and we did not detect any compilation error.

Would you please give us more details on how did you detected the issue.

With regards,

pavel-a commented 10 months ago

Hi @ASELSTM This issue is related to conversion of SW4STM32 examples to CubeIDE. Please try to import to CubeIDE v 1.12. The newlib used in CubeIDE toolchain needs to resolve some functions which are usually exported by file syscalls.c.

However I have not tested the latest CubeIDE and its new toolchain yet. Maybe the newlib there treats these unresolved imports differently (which is suggested by recent forum questions).

Just note for now the example projects that contain syscalls. c for some F7 boards but do not contain it for other boards.

ASELSTM commented 10 months ago

Hi @pavel-a,

Thank you for these details. Indeed, the issue has been detected even using the latest version of STM32CubeIDE v1.13.1. A fix will be deployed. We will keep you informed once it is available.

With regards

ASELSTM commented 10 months ago

ST Internal Reference: 159701

ASELSTM commented 10 months ago

Hi @pavel-a,

The issue has been fixed within this commit. Please allow me thus to close this thread.

With regards,

thestumbler commented 10 months ago

Note... this seems to apply to the Nucleo H723ZG board as well. I wasn't importing any project into CubeMX. Rather, I just generated a simple blank project for this board. The resulting Makefile project would not compile. Following the hints in this trouble report, I copied syscalls.c into Core/Src and all those linker errors went away. I found the example file in the STM32H7 repository under Projects/NUCLEO-H723ZG/Templates/STM32CubeIDE/Example/User/. There is also a sysmem.c in that directory as well, but this presence / absence of this file doesn't seem to generate any extra errors or warnings. Note: Also added the newly added source code to the Makefile.

ALABSTM commented 9 months ago

Fixed in commit 959dea9846d896caecc4ea2a3e66ada01e4ff7f2

thestumbler commented 9 months ago

Fixed in commit 959dea9

I am confused by this comment. That commit is about this F7 repository, and my comment above was about the H7 repository which seemed to have the same issue. Also confusing is that ASELSTM closed that issue on the H7 repo, noting that this is not related to STM32Cube repositories, but rather internal operations of STM32CUBEMX. Maybe they meant that this issue, in regards to the F7 family, CAN indeed be solved by a fix in this repository (hence the referenced commit above) -- but things are handled differently for the H7 family and it has to be done in CUBEMX instead?