cancel
Showing results for 
Search instead for 
Did you mean: 

Nucleo-U545RE-Q in STM32CubeIDE (included CubeMX part) bad IOC file

HannesO
Associate

New to STM32. Ordered myself a Nucleo-U545RE-Q Board for software generation used in an embedded project later. Generated a project and started working on it. First it worked just fine. But since mid of last week (start of August), most likely after an update which was installed, it wont crate a working IOC for new projects with the board anymore. New projects for other controllers or other Nucleo-boards work just fine.

More specifically as seen in following screenshot, all pins which should be pre- configured with a function for the Nucleo board produce a conflict. The USART1 function is fully grayed out and not configurable.

Nucleo-U545RE-Q_Proj_crea4.PNG

 

During project creation the options for the USER features are ticked as seen in following picture:

 

Nucleo-U545RE-Q_Proj_crea3.PNG

 

the right pins seem to get configured in a wrong way.

My current STM32CubeIDE Version: 1.16.0 
                                                 Build: 21983_20240628_1741 (UTC)

current STM32CubeMX version inside the IDE:  6.12.0.202406281431

 

 

Am i doing something wrong or is this a bug introduced via the last update?

 

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

When you use that nucleo board, the peripherals are handled with the BSP, rather than with the typical MX/HAL functions. The "disabled" pins reflect this. Generate the project, you'll see the proper initialization calls are still being made.

TDK_0-1722863516844.png

If you want a "normal" CubeMX project, create a project from the chip instead of the board and configure these peripherals manually.

Presumably a change in how they've decided to do things, but doesn't appear the be a bug.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

4 REPLIES 4
TDK
Guru

When you use that nucleo board, the peripherals are handled with the BSP, rather than with the typical MX/HAL functions. The "disabled" pins reflect this. Generate the project, you'll see the proper initialization calls are still being made.

TDK_0-1722863516844.png

If you want a "normal" CubeMX project, create a project from the chip instead of the board and configure these peripherals manually.

Presumably a change in how they've decided to do things, but doesn't appear the be a bug.

If you feel a post has answered your question, please click "Accept as Solution".

Hello @HannesO 

You can click on "Unselect All" or on the "Pinout"  then Clear Pinouts" button to reset the pin configurations and resolve conflicts, so that you can start configuring the pins from scratch. 

Thank you.

Best regards,

ELABI.1

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

@TDK 
Thank you for the clarification.
I have already created a project using the chip directly and worked with it, it works just fine.

@ELABI.1 
I also tried creating a new Project using the Nucleo Board and clicking "unselect all".
the User_Button and the LED still get configured in the IOC even if nothing is selected anymore. The UART for the Virtual COM port on the other hand is not configured now. This time they dont create any conflicts anymore.

This seems a little confusing to me, because the example generation is not chosen as the project is generated.
Why is there options for choosing what should be created or not but some get created anyway and some dont?
My confusion might come from me not fully understanding how the drivers work yet.

Hello,

I Had same issue. IPs are not activated, pinout is red.

Ticket entered: #188163