USART10 Clock Initialization Issue in STM32CubeMX Generated Code for STM32N6 (FSBL)

[wantgoodjob]

I am developing with STM32CubeMX and generating initialization code for an STM32N6 device. In my FSBL (First Stage Boot Loader), I use USART10 to connect to the ST-LINK V3’s Virtual COM Port (VCP). However, it seems that CubeMX does not correctly generate the peripheral clock initialization code for USART10.

After a series of investigations, I found that when generating USART10’s clock initialization code, only the kernel clock for USART10 is set to IC14, but the PLL source and divider for IC14 are missing. This happens with both LL and HAL libraries. For USART6, there is no such problem — its clock configuration is generated correctly.

This behavior is very strange. During debugging, I also encountered an issue where PLL2 was not initialized, but that problem disappeared later.

To work around this, I manually added IC14 configuration code for USART10 following the pattern used for USART6, setting IC14 = 96 MHz. After that, USART10 worked normally at the maximum baud rate of 12 Mbps.

Has anyone else seen this issue with USART10 clock generation on STM32N6? Is there a known fix or workaround in CubeMX?

by the way, for a complex chip like the STM32N6, using STM32CubeMX to automatically generate initialization code is almost essential. However, various initialization issues can undermine people’s trust in it and significantly hinder rapid development, forcing developers to dive into low‑level code just to figure out what went wrong. Therefore, I believe ensuring the correctness of the code generated by CubeMX is absolutely necessary.

stm32cubemx version:6.16.1     ,stm32N6 package version 1.3.0

Thanks.

[Mahmoud Ben Romdhane]

Hello @wantgoodjob 

Let me thank you for posting.

I am currently checking this behavior, and I will get back to you ASAP.

Thanks.

Mahmoud

[Mahmoud Ben Romdhane · Accepted solution]

Hello @wantgoodjob 

Let me thank you for bringing this issue to our attention.

An internal ticket was submitted to the Dedicated Team (Internal Ticket Number: Ticket 226078).

I will let you know when the issue is fixed.

Thanks.

Mahmoud

[William6]

Possibly related: I noticed USART10_RX and USART10_TX are listed on the datasheet for PD14 and PD15. However they do not appear in STMCubeMX as options for those pins. It isn't clear if the problem is on the datasheet or on CubeMX

[Mahmoud Ben Romdhane]

Hello @William6 

Further to your comment and while enabling USART10 on STM32N647X0H3Q as Asynchronous Mode, you can notice that:

PD15 --> USART10_TX 

PD14 --> USART10_RX.

Thanks.

Mahmoud