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.
