STM32N6 XSPI1 时钟配置问题与建议

发表于 2025-11-1 19:29

1. 引言

客户在使用STM32N6开发过程中，使用STM32N6570-DK例程 GPIO_IOToggle，添加XSPI1，设置其时钟源为PLL2，编译、签名、烧录到外部Flash，然后断电再上电DK板，LED1能够正常闪烁（工程的正常功能）。此时按板上B1键（应用复位按键）进行复位，发现LED1未亮起，疑似程序卡死不能执行。本文中对该问题进行了调查，分析原因并给出了建议，供大家参考。

2. 应用卡死问题

2.1. 应用的正常情况我们使用STM32Cube_FW_N6_V1.1.0\Projects\STM32N6570DK\Examples\GPIO\GPIO_IOToggle工程（如果使用的是STM32Cube_FW_N6其它版本，请在相应目录下寻找该例程），使用IAR ( V9.40及以上版本, 如需要打补丁，请到STM32Cube_FW_N6_V1.1.0\Utilities\PC_Software下查找补丁)，直接打开例程，编译，并按照readme中所述，将生成的GPIO_IOToggle_FSBL.bin做签名处理： STM32_SigningTool_CLI.exe -bin GPIO_IOToggle_FSBL.bin -nk -of 0x80000000 -t fsbl o GPIO_IOToggle_FSBL-trusted.bin -hv 2.3 -dump GPIO_IOToggle_FSBL-trusted.bin 然后使用STM32CubeProgrammer将GPIO_IOToggle_FSBL-trusted.bin烧录到外部Flash（地址0x70000000），将Boot0 & Boot1开关拨到外部Flash启动位置，断电再上电DK板，可以看到LED1灯不停闪烁，按B1按键复位后 LED1灯也能够不停闪烁，功能正常。即进行Application reset时，STM32N6 BootROM能够正常从外部Flash加载FSBL并跳转执行，该例程能够完美展示GPIO IOToggle功能，是正常情况。

2.2. 问题复现我们在上面的GPIO_IOToggle工程目录中，使用STM32CubeMX直接打开GPIO_IOToggle.ioc，添加XSPIM 并将模式设置为Direct (XSPI1 to Port1 ; XSPI2 to Port2 ; XSPI3 not used)，如下图1所示。

然后我们添加XSPI1并设置为QSPI，Port 使用 Port1，片选设置保持默认（这里黄色警告来自片选设置，因有多个选项，但其中一项NCS2 不可以选，STM32CubeMX给出常规警告，并非设置问题），整体设置如下图2所示。

此时我们不更改XSPI1 时钟设置，保持默认，即使用HCLK作为XSPI1的工作时钟，配置如下图3所示。Project Manger 选项不动，Tool chain/IDE 保持为EWARM（IAR），直接点击“GENERATE CODE”生成代码。

我们检查代码，发现main函数中仅添加了一行代码MX_XSPI1_Init，该函数对XSPI1进行了初始化，内容与我们在STM32CubeMX设置保持一致，代码如下：

我们使用IAR打开生成的工程，编译，将生成的GPIO_IOToggle_FSBL.bin做签名处理，然后使用STM32CubeProgrammer将GPIO_IOToggle_FSBL-trusted.bin 烧录到外部Flash 0x70000000地址（操作与前面2.1小节描述一致），将Boot0 & Boot1开关拨到外部Flash启动位置。上电可以看到LED1灯不停闪烁，按B1按键复位后 LED1灯也能够不停闪烁。即我们添加的XSPI1在默认配置下功能正常，并没有问题。然后我们使用STM32CubeMX更改XSPI1的时钟设置，使用PLL2 -> IC3 -> XSP1时钟链路，并保持200MHz不变，如下图4所示。修改完成后，重新生成代码、编译、签名、烧录并测试。此时我们会发现该FSBL程序在第一次上电时能够正常执行，LED1能够正常闪烁。但此时我们按Button B1 reset进行复位（非上电复位），LED1没有亮起，不能正常闪烁，LED2指示灯也没有亮起，似乎例程卡死在某个地方不能执行。至此我们复现了问题。

2.3. 问题分析
根据问题现象，我们首先想到的是将代码执行流程分段分析。STM32N6没有内部Flash，启动时首先从BootROM执行，BootROM根据启动设置进行选择，本文中启动方式选择的是从外部Flash启动，BootROM会配置XSPI1使用Port2访问外部OSPI Flash MX66UW1G45GXDI00（NOR Flash，详见STM32N6-DK板电路图），验签并从Flash 地址0x70000000处复制FSBL至RAM，然后跳转执行RAM中的FSBL。我们这里首先需要确认Reset后，BootROM是否将FSBL复制到了内存中，以此定位问题出在BootROM还是FSBL。由于DK板上XSPI1的CLK与Data线均难于测量，从硬件的角度我们无法确定是否有复制FSBL的过程。我们在调试过程中，发现问题出现时Debug Link 是断掉的，由于系统复位时不会复位CM55的DBG单元，可以间接判断系统没有进入FSBL。好在我们添加的代码很少，仅有一句XSPI1的初始化，于是尝试修改并测试了一些XSPI1 的设置来总结问题规律。结果发现问题出现在与XSPI1 时钟源的选择相关。XSPI1时钟源使用HCLK和PER时应用正常。使用PLL1-> IC3/4，PLL2-> IC3/4，PLL4-> IC3/4，PLL4-> IC3/4 均能复现问题。至此我们合理怀疑某种原因造成系统复位时XSPI1 时钟丢失，或未能正常提供。

我们查询参考手册（Rev2.0），在RCC 第14.6.10 Peripheral allocation一节中，提到PERxSEL开关切换时钟的过程。见下图5. STM32N6外设时钟切换，该过程中，原文表述“If one of the two clocks are not present, the sequence cannot be completed, and no clock is output. To recover from this situation, the user must either provide a valid clock to in1_ck input, or set back PERxSEL to 0.”，即时钟切换时原时钟源和目标时钟源需要同时存在，才能切换成功。

系统复位时，虽然RCC_CR并未复位，但大部分的RCC寄存器均会复位（见下图6），PLL时钟复位，需要重新建立。BootROM中XSPI1使用的是per_ck(HSI)，XSPI1SEL@RCC_CCIPR6 时钟选择配置寄存器复位，由于PLL时钟源不存在，我们怀疑BootROM执行过程中，时钟源从PLL(经IC3/4)切换至per_ck时失败，造成XSPI1时钟丢失，进而XSPI1并未工作，造成加载FSBL失败。

为了验证猜测，我们重新从原始的GPIO_Toggle工程出发，不使用STM32CubeMX进行设置，改为只在main函数中手工添加XSPI1时钟设置代码进行验证（添加的代码见下面黄色部分），在这里我们只设置了RCC_IC3及XSPI1_SEL。

直接编译代码，签名并烧录到板，发现问题依然可以复现。进一步测试，如果仅设置IC3也是没有问题的，问题出现在了XSPI1_SEL的操作上，至此验证了我们的猜测。 2.4. 建议根据STM32N6时钟切换规则，PERxSEL在切换时钟时，需要原时钟源和目标时钟源同时存在。如果FSBL（或应用）与BootROM使用到了同一外设，建议在FSBL（或应用）中配置该外设时，使用与BootROM相同的时钟源。

在某些特殊情况下，如果外设的时钟源不能与BootROM保持一致，FSBL（或应用）则可以在系统复位前切换该外设的时钟源，以保持与BootROM一致，进而避免问题发生。这种做法可以作为备用手段。

3. 小结
STM32N6设置为外部Flash启动时，BootROM会配置XSPI1，其时钟使用的是per_ck。当FSBL或应用（系统复位前运行的程序）使用到了XSPI1并配置XSPI1时钟源为PLL时，当发生系统复位时（非上电复位），BootROM存在访问XSPI1外设失败问题。FSBL或应用将XSPI1的时钟源设置为per_ck（保持与BootROM一致），可以解决问题，或者在系统复位前将XSPI1的时钟源设回per_ck，亦可解决该问题。对于其它外设，如果FSBL或应用与BootROM均有使用，也需要将其时钟源配置为与BootROM一致或在系统复位时做相应处理，客户开发过程中需要注意这一点。关于BootROM配置的更多信息，请参考UM3234。

[信息] STM32N6 XSPI1 时钟配置问题与建议

相关帖子

浏览过的版块