近日某论坛一STM32用户反馈，使用STM32F103内部时钟，把系统时钟配置成64MHz单片机就不跑了，配置成36MHz程序就正常妥妥的，频率稍高点就容易导致死机。他贴出的代码如下：

void RCC_Configuration(void) 

{ 

 RCC_DeInit();//将外设 RCC寄存器重设为缺省值 

RCC_HSICmd(ENABLE);//使能HSI   

while(RCC_GetFlagStatus(RCC_FLAG_HSIRDY) == RESET);//等待HSI使能成功 

//FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable); 

//FLASH_SetLatency(FLASH_Latency_2); 

RCC_HCLKConfig(RCC_SYSCLK_Div1);    

RCC_PCLK1Config(RCC_HCLK_Div2); 

RCC_PCLK2Config(RCC_HCLK_Div1); 

//设置 PLL 时钟源及倍频系数 

RCC_PLLConfig(RCC_PLLSource_HSI_Div2, RCC_PLLMul_16);

。。。。。。

结合他的问题描述及他贴出来的代码，大致可以判断出很可能是因为他屏蔽了指令预取和flash读取等待延迟的参数配置而导致的异常。即上面两条红色标注出来的代码。

后来我明确地提醒他这点后，他似乎并没及时反应过来，还折腾了几下才开启了上述配置，问题最终得以解决。

其实，关于这个问题经常有人遇到，尤其是那些基于STM32标准固件库进行开发或自行编程时的新手更容易碰到这个问题。主要原因是他们对上述两行代码的功能不了解，导致有意或无意的将库例程中相关代码屏蔽掉无视掉不做配置、或者配置不正确。

这里将这个问题再次分享出来，对上面两行代码简单做些解释。希望更多人对此有所知晓，少在这个地方走弯路。

这句

FLASH_PrefetchBufferCmd();

用来作为flash指令预取功能的使能或禁用。

现有STM32各个系列都是基于ARM cortexM内核的微处理器，采用多级流水线的哈佛结构，即一条指令的执行分割为几个阶段，如取指、译码、执行等，使得当前指令的取指操作完成后就可以开始后续指令的取指、译码等操作，程序指令就这样像流水一样执行下去，大大提高了指令的执行效率。

具体到STM32各系列单片机，这个指令预取功能的开启或关闭可以软件配置，一般配置为开启。要注意的是，芯片复位后不同的系列该功能有的默认为开启有的则默认为关闭。比方STM32F1系列的flash指令预取功能就是默认打开的，当然你也可以关闭。其中，明确要求打开的情景就是当那个AHB时钟预分频系数不等于1时。

再比如STM32F4系列，它的指令预取功能在芯片复位后是默认关闭的，你可以自行打开。但明确要求关闭的场景就是芯片的供电电压低于2.1V时。

其实，STM32F4的预取功能与STM32F1不尽一样，STM32F4、STM32F2、STM32L4、STM32F7等系列芯片使用了ST的专利技术ART存储加速器【Adaptive real-time memory accelerator】。该加速器使用指令预取队列和分支跳转缓存技术，从而提高 Flash 程序代码执行速度，使得CPU即使在其最高主频下也能完美实现0等待执行flash程序指令。

上面大致讲了指令预取功能，预取主要是为了实现指令读取和执行的高效性。具体细节请参考相关技术手册。我们知道CPU的运行速度可调，可以很快，通常使用高速总线访问FLASH接口控制器，FLASH控制器收到来自CPU的取指指令后然后去读取相应地址的指令或数据。Flash控制器自身的读取速度相比CPU的高速请求来说可能会出现滞后，往往需要CPU做相应的延时等待。为了让CPU准确及时读取 Flash 数据，我们须根据 CPU 时钟频率、FLASH控制器自身特性以及器件供电情况在Flash存取控制寄存器(FLASH_ACR)中正确地编程等待周期数(LATENCY)，类似上面提到的第二句代码：

FLASH_SetLatency(FLASH_Latency_n);

这里的等待周期数视不同的STM32系列也各有差异，不妨以STM32F4为例：

下面是个关于STM32F4系列部分产品线的LATENCY设置的表格。从表格中可以看出LATENCY参数的设置与CPU的时钟、电源电压都有关系。另外，当电源电压在2.1V以下上要关闭预取功能。

在设置上面的等待周期参数时，选择合适的就好。不难理解，设置太大了影响CPU性能的充分发挥，太小了容易导致异常。

具体回到开头的案例，它出现死机问题，极可能是因为没有合理配置等待周期参数导致异常，因为它屏蔽了参考例程中那两句配置代码，即使用其默认功能，对于STM32F1，指令预取功能默认为开启。而STM32F1系列芯片的latency默认值即为0，无等待。这样的话，当他把时钟调高到一定程度时出现死机就不难理解了。

另外，当他反馈时钟调高产生异常时，我还给他提醒了注意检查VDDA的电源情况。我碰到有人遇到因VDDA没接好使得PLL不正常的情况。我们知道，对于STM32芯片，调高其工作时钟，往往借助于锁相环。而PLL的供电来自VDDA，如果PLL没有被正常供电，也是个非常隐蔽的麻烦。曾经有个客户为此折腾好久，才愿沉下心来检查其“坏品”的电源，结果发现有个VDDA脚虚焊。一直以芯片低频没问题，频率高了就异常为由怀疑芯片品质问题而耽误时间。

最后给点建议，做STM32开发的话，尤其是新手，如果参照ST的官方例程的话，有些配置在没看懂的情况下不要轻易屏蔽或修改。我碰到多个类似本案随意屏蔽例程中的初始化配置代码或断言代码出现异常，自己又找不到方向的。另外，尽可能使用ST官方的stm32cubeMx图形配置工具做基本的配置，通过它来生成初始化配置文件，这样方便省事很多。当然，即使使用STM32CUBEMX配置也不是万能的。比方：曾经有人使用STM32F0开发产品，用CUBEMX配置初始化文件，刚开始配置时时钟选择得比较低， STM32CubeMx自然根据他选择的时钟做了相关参数配置。后来他自己在用户代码里手动调高了时钟，而不知相应调整跟FLASH读取等待有关的参数，也是发生跟本案同样的情况。所以呢，如果能对原理有更多更深的把握那是再好不过了。

本文转自：https://mp.weixin.qq.com/s/E29t7t5YuLFZtHYWcwguJQ

感谢【ST MCU 信息交流】的经验分享。

1 问题现象

有客户使用STM32F405并参照ST官方USB标准库下的HID+CDC的示例代码做产品，发现在WIN7上使用得好好的，可放到WIN10上，CDC第一次能够识别，再次拔插后就不能再识别，且此后无论插拔多少次都无法再识别，除非再次上电，又会重复上述现象，只有板子上电后第一次才能正确被识别，后续均不行。

2 问题分析

客户使用 ST官方示例代码

STM32_USB-Host-Device_Lib_V2.2.0\Project\USB_Device_Examples\Composite_Examples\CDC_HID_Composite

（下载页面：

http://www.stmicroelectronics.com.cn/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-library-expansion/stsw-stm32046.html）

当我尝试使用此示例代码重现客户所遇到的问题时，发现此代码在WIN7运行OK，但与客户不同的是，我测试到的情况是在WIN10下CDC一次都无法识别，HID却一直可以识别。

下面来分析下问题，既然WIN7下HID和CDC都能正常识别，放在WIN10上才不正常，那么初步可以判断，此问题可能与WIN10操作系统的USB主机驱动实现有关。

通过USB分析仪分析客户代码在WIN10下USB枚举异常的数据通讯：

Figure 1 第一次USB枚举过程

上图是客户代码第一次正常枚举的通讯数据，从图中可以看出，WIN10 USB主机在正常获取HID报告描述符后，紧接着会获取虚拟串口状态和设置波特率，这样就正常枚举结束了。我们再来看看采集到的异常USB枚举过程：

Figure 2 异常枚举过程

上图是WIN10下异常枚举过程。从图中可以看出，WIN10系统上USB主机在获取到设备描述符和配置描述符后直接将设备挂起了。很明显，WIN10系统的USB主机驱动实现对设备描述符或者配置描述符的内容并不认可，才会导致无法识别HID+CDC复合设备。

我们不妨检查下客户代码中的设备描述符：

Figure 3 获取的设备描述符

复合设备的class,subclass,protocol

必须为0xef,0x02,0x01,这里

VID=0x0483,PID=0x3256(Cube库下为0x5740,但这个不重要),接下来看配置描述符:

Figure 4 win10不能识别的配置描述符

由此可见，客户的描述符是HID interface + IAD + CDC interfaces结构。对于WIN7，这种结构可以识别，但对于WIN10，这种结构WIN10未必能够兼容，我们尝试在HID interface外部加上一层IAD结构，使其成为IAD1 + HID interface + IAD2 + CDC interfaces结构，此时客户的问题得以解决，在WIN10也可以正确识别了，修改后的描述符结构如下：

Figure 5 win10能够正确识别的配置描述符

结束本篇实战经验之前，让我们再次回顾IAD的概念：

IAD（Interface Association Descriptor），为USB设备定义了一个标准来表述捆绑在一个逻辑功能（比如这里的CDC虚拟串口）上的多个接口的聚合的方法。USB协会分配了一个设备级别的类编码（即图3中0xEF），使用IAD的设备必须使用它（如图3的设备描述符）；这样可以很容易在设备枚举时就能识别出采用了IAD的设备。IAD描述符通常放在它所要捆绑的多个接口的接口描述符之前。

3 结论

在WIN10系统中，建议复合设备每个逻辑功能的接口描述符前都搭载一个IAD描述符，不论这个逻辑功能是单个接口描述符完成（比如这里的HID功能）还是要由多个接口描述符完成（比如这里的CDC功能）。

本文转自：https://mp.weixin.qq.com/s/9ot9AVTN4zSMAyudVDeMzA

感谢【STM32单片机】分享的经验。

当使用Timer做捕获输入时，有时候需要将捕获得到的数据通过DMA方式写到定义好的数据或数组中，本文将详细介绍使用CubeMX配置PWM捕获功能，用户可以直接得到输入的PWM信号的频率以及占空比，Cube库可以很方便配置。

实验过程中，当配置超过两个以上的Timer通道DMA时会遇到一些问题，本文也对其进行了说明并给出了解决方案。

Timer2的PWM信号捕获功能

√使用Timer的IC1，IC2两个捕获输入通道，两个通道的外部管脚输入配置为相同TI1通道；

√两个通道的捕获输入极性，一个为Active，另外一个为Inactive；

√其中一个TI1FP1作为触发输入，从模式配置为复位模式；

√这样CCR1为PWM输入的频率值，CCR2为占空比值（正/负）。

使用STM32CubeMX对外设进行初始化配置：

Step1: TIM1的输出PWM波作为捕获输入的被测信号，输出管脚为PA8

Step2: TIM2的输入管脚为PA5（CH1）

Step3: 配置TIM2的输入捕获参数

Step4: 捕获数据直接通过DMA方式保存到RAM变量Update_Value1和Update_Value2。

Step5: 测试读取到的CCR1、CCR2的数据与Update_Value1、Update_Value2对应，PWM波的频率和占空比都可以捕获得到。

实验过程要点提示

在stm32f3xx_hal_tim.c

库文件中的HAL_TIM_IC_Start_DMA函数中会将状态置忙。

但在函数结尾配置完毕后没有将该状态位复位，如果客户在其用户程序中使用了这个函数，这会导致该状态位始终为忙，后续任何对该状态的判断配置都将无法执行：

因此需要在函数的最后将状态复位：

本文小结

本文重点介绍利用STM32CubeMX初始化配置工具和STM32Cube库如何通过TIMER的捕获功能完成对频率、占空比的测试，同时我们对如何解决实验过程中遇到的一些问题，做了特别提示。我们知道STM32Cube库非常庞大，虽难尽善尽美，但一定会越来越强大、越来越完善。

本文转自：https://mp.weixin.qq.com/s/e2M22gpqFmOKee36MFe9oQ

感谢ST人的分享和付出！