2020-07-28 01:34 PM
When creating a new project in CubeMX for Nucleo-F767ZI LD1 is not initialised and no initialisation code for it is generated. I suspect the reason for this is that on the schematics in UM1974 LD1 is not on the same page as the other user LEDs and is easy to miss.
CubeMX version: 5.1.0
Firmware version: FW_F7 V1.15.0
Expected behavior: CubeMX should initialise PB0 as GPIO output and name it "LD1 [Green]"
I also noticed that on page 1032 in UM1905 the function description for HAL_USART_Receive_IT() seems wrong. It says that this function is for receiving data in blocking mode but it is for receiving with interrupt and therefore should not block. This, however, seemed too minor to make a separate post about it.
2020-07-30 03:51 AM
Hello VGari.1,
I don't really understand the problem, but when I start a new STM32CubeMX project using Nucleo-F767ZI board and initialize all peripherals with their default Mode, PB0 is correctly assigned to LD1[Green] (please see attached screenshot of the Pinout view below ). The code also is correctly generated.
Thus I can't find the issue, waiting for your feedback if I miss something.
Best Regards,
Khouloud.
2020-08-01 06:09 PM
Perhaps the standalone CubeMX and the plugin for AC6 System Workbench behave differently. I am using the latest version of CubeMX plugin for System Workbench on Arch Linux. This is how a brand new project with Nucleo-F767ZI looks like on my machine:
2020-08-03 05:14 AM
Hello,
I can't reproduce the issue using the last version of STM32CubeMX standalone and even when opening a new Nucleo-F767ZI project through the last version of STM32CubeIDE (check https://www.st.com/en/development-tools/stm32cubeide.html for download).
I have tried on both Linux and windows machines and I get always correct initialization.
BR,
Khouloud.
2020-08-07 11:28 AM
Alright, there must be something wrong on my end. If it can't be reproduced then I guess it is not an issue.
Thank you for looking into it.
Best regards,
Vladimir Garistov