我们知道，利用单片机定时器捕获功能测量脉冲信号宽度及占空比是种很常见的做法。这里以STM32的定时器为例来介绍基于其捕获功能实现对脉宽的测量的思路及过程。一般来讲，使用STM32定时器的捕获功能来实现脉宽测量，我们可以选用一个通道、也可以使用两个通道。使用1个通道时，只需使用定时器基本的输入捕获功能结合中断或DMA即可实现；若使用两个通道时可以将捕获功能与定时器的从模式来相结合完成。这里就两种方案的实现示例都做个简单介绍。不妨先介绍基于单个通道的输入捕获功能来实现对1路信号脉冲宽度及占空比的测量，并在测量过程中统计用于测量的定时器自身的溢出事件，以保障即使被测信号脉宽长于测量定时器自身的溢出周期时也能有效测量。这里选用STM32F411

我们使用STM32芯片开发产品时，有时需要自带升级功能。因此，开发时除了需要准备基本的应用代码外，还得准备一套升级代码。通常称前者为IAP代码或BOOT代码，后者称之为APP代码。一般来讲，这两套代码基于两个工程完成并生成相应的执行文件，首次烧录时往往希望两套代码合并在一起进行烧录，这样方便、省事。这里就该需求，利用ST提供的工具软件STLINKUtility来示范下合并过程。因为只是模拟两个不同地址区的文件合并，所以这里的两个工程代码几乎一样，也很简单，只是存放的地址空间不同。我使用的开发板是STM32L476RGNucleo板。代码功能都是接受按键，每收到1次按键动作，就打印出目前所在工作区。当收到3次按键后则从当前工作区跳往另一工作区。【文中图片可点击放大查看】两个工程的内存及中断矢量安排如下两幅图：除了上面的配置差异外，两个工程的代码几乎一样，只是输出提示有别。这里使用的是IAR

基于STM32芯片的工程代码里有个很重要的文件，即启动文件。该文件主要由汇编语言写成，文件名冠以.s结尾，它是芯片程序运行首先要执行的一个文件。其功能及作用简单点说就是做执行用户程序前的基本准备，比方执行复位程序初始化栈、堆，做时钟系统的默认配置、中断矢量表的定义与分配等。网络上有些文章对该文件做了不错的整体性介绍，这里仅就该文件中的几个小问题一起交流分享下。【注：下面用到的工程是基于STM32F429的，使用IDE为ARM

整体上讲，很多STM32芯片内置了功能强大的用于加速图形处理的硬件加速器，借助它们一方面可以大大减轻CPU负荷，以节省CPU处理带宽去应对其它任务，另一方面，在节省内存同时还能保障动画或视频播放更为流畅。这些硬件图形加速器分别是STM32

我们知道,STM32的生态系统可以说庞大而完备，技术文档也非常全面而丰富。常用的STM32技术文档包括各个系列参考手册、芯片数据手册、flash编程手册、应用笔记、各种用户手册等。其中应用笔记往往针对某一话题做了专门而详细的技术性、知识性解说，对STM32开发人员的应用开发非常有帮助。整体而言，这类应用笔记的数量也比较多，而且经常会做版本升级，有时突然要找某份资料可能要费一番功夫。我这里将其中跟STM32开发有关的大部分应用笔记大致地分门别类整理在这里，便于了解和速查，需要时前往www.st.com/stm32搜索编号即可直接阅读或下载阅读。【注：我没有把那些有关项目移植的应用笔记整理进来】一、工具篇AN4989

STM32芯片的ADC模块往往都支持模拟看门狗功能，即可以对单个或多个通道开启模拟转换值的监测。当模拟通道ADC值超出设定的阈值时可以产生模拟看门狗事件并可触发看门狗中断。【注：下面截图或数据都是基于STM32L4系列芯片的，其它STM32系列与其类似。】结合上图，当选定的ADC通道的转换结果比设置的阈值上限还高或比设定的阈值下限还低时都可以通过硬件触发模拟看门狗事件或中断。

STM32系列芯片都内置DMA外设，其中很多系列的DMA配备了FIFO。这里以STM32F429芯片及开发板为例，演示一下带FIFO的DMA传输实现过程。

有人使用STM32芯片做产品开发，需用到多个通道的ADC转换。大致需求是这样的：有2个ADC通道需要每10ms启动一次转换，另外5个通道希望50ms启动一次转换。试问如何实现上述功能比较好。

STM32的通用定时器和高级定时器除了支持单向的向上或向下计数模式外，还支持中心对齐计数模式，即一个计数周期内分别由向上计数和向下计数两个过程组成。在基于计数器的中心对齐计数模式做定时器的比较输出功能时，又进一步衍生出三种中心对齐计数模式，分别是中心对齐计数模式1/2/3。具体通过寄存器TIMx_CR1里面的CMS[1:0]选择。

v1组件也合适。另外，如果有人想更多详细了解CMSIS的话，可以到下面站点查看：https://developer.arm.com/tools-and-software/embedded/cmsis

芯片设计人员在此提供了两种转换序列模式，本意旨在让我们能在实际应用中可以根据实际需求灵活选择，然而，往往由于开发人员的惯性思维和无视手册导致在这个地方遇上点麻烦或困惑。在此分享之，祝君好运！

ST公司为广大STM32用户推出了免费的编译调试开发环境STM32CubeIDE,越来越多的人都在关注和使用它。在基于STM32CubeIDE的开发过程中，有个比较常见的问题就是如何在调试过程中对变量进行查看。这里简单地演示下实现过程。我在工程里定义了两个全局变量，分别是下图中两个变量。【注:文中图片手机模式下可以点击放大查看】代码编译完成后，开始进行调试。我们可以打开Debug

我们在MCU的开发调试过程中，有时希望将一些信息输出以便观察。通常我们可以将标准C库中Printf相关实现函数进行重定向，通过UART串口输出，或者利用ITM机制通过SWO输出。这里将简单演示IAR环境下基于SemiHost机制实现printf功能。

在前面测试的基础上，程序代码依然使用D1的AXI_SRAM，而将堆栈数据区改为D2的SRAM1试试看。一切调整完毕，再行验证。结果是程序没法正常运行，出现硬错。

有人采用STM32H743ZI芯片的SPI外设跟ADC器件通信，发现一旦SPI的SCK时钟超过25MHz时，比如50Mhz，就会发生读取数据失败，并提示Busy忙信息或ERR错误信息。反正只要串行时钟不超过25Mhz，收发都很正常。但是STM32H743芯片手册上明白地说了SPI时钟最高可达150MHz，这会是什么原因呢？根据他所提到的异常现象初步判断，不论他的硬件方面还是软件配置方面都应该没有很大的问题，不然根本没法通信。像这种情况有可能是下面几种原因之一或组合原因【当然不仅限于这些】：第一种情况就是通信速率明显提高时，由于通信速率加快，而接收处理的相关代码本身所用时间相对固定，这样可能导致不能及时读走数据而发生溢出，尤其是基于查询方式或中断方式接收处理时。这时我们可以考虑对接收代码做进一步的精简优化，压缩接收处理时间，或者改用DMA方式进行数据的收发。第二种情况就是当通信速率明显提高时，跟外设复用的GPIO输出速率档位的配置没有跟上来。以本案例来说，当我们将SPI的时钟上到50MHz甚至更高时，若相应的GPIO的输出速率配置还维持在相对低速水平，与实际输出需求不相匹配时往往就会出现异常。【**手机模式下，文中图片均可点击放大查看**】关于这个配置，如果使用STM32CubeMx配置的话就非常简单，通过菜单选择即可完成。如下图所示：第三种情况就是当通信速率明显提高时，即使相应的GPIO输出能力配置也匹配了，但有些情况下还是有可能出通信异常的问题。我们知道，当GPIO输出速率越来越高的时候，GPIO模块带来的噪声也越大，作为通信口时其信号质量也会随着通信速率的提升而变差，当然，此时芯片所需的功耗也随之增大。对于很多STM32系列芯片，当GPIO输出速率达到一定程度时，建议开启片内GPIO补偿单元。【下面截图是两个STM32系列关于GPIO补偿单元的介绍文字】该GPIO补偿单元的作用就是通过控制IO口的输出斜率，降低GPIO的噪声对整个电源的影响并尽力改善信号质量，所以当我们基于STM32芯片实现较高速率的通信时，比方50Mhz甚至上百兆的SPI或USB通信时，如果芯片有GPIO补偿单元的话，建议将其开启。顺便提醒下，使用GPIO补偿单元的话，往往对电源电压有相应要求，具体依手册而定。下面是分别基于STM32F4和STM32F7系列的HAL库相关开启GPIO补偿单元的函数。至于本案例异常的真正原因是什么呢？后来经确认属于上面提到的第二种情况，GPIO输出速率挡位选择与实际输出需求不匹配，稍加调整配置就好。==========================往期话题阅读链接【点击即可阅读】：1、一次事件会触发两次中断？2、STM32高精度定时器PWM输出话题3、图形化设计工具TouchGFX的学习站点4、STM32定时器BURST传输介绍及示例5、基于STM32H7芯片的矩阵运算应用示例

也许有人会说，我中断服务程序里就只需做中断请求位清零这一件事怎么办呢？那你就随便在清零操作代码后面随便一两行无关紧要的代码也行，确保不发生1次事件进两次中断即可。

某STM32用户反映，他目前使用STM32F407VE的芯片开发产品，在使用CubeMx做初始化配置时发现没法给UART5配置基于该外设事件的DMA请求。他觉得很奇怪,坚信UART5是可以申请DMA传输的，而且他还基于早期CubeMx

可知，印制线与参考接地板之间的寄生电容大小取决于印制线与参考接地板之间的距离(即公式1中的H)和印制线与参考接地板之间形成电场的等效面积(即公式1中的S)。

最近有个STM32用户反映，他们目前在调试STM32G431CBU6这款芯片。使用ST官方的Cube库进行编程，发现时钟没法配置到技术手册上告知的170MHz。当然这个170MHz的频率要经过PLL倍频产生。不管选用内部时钟源还是外部晶振，只要配置成170MHz,芯片肯定会复位。基于HSI时钟源的相关时钟配置代码大致如下：他尝试做了各种软硬件调整排查，经过反复测试验证，发现设置PLL所产生的时钟只有在不高于80MHz时，芯片才能正常运行。可STM32芯片手册白纸黑字明明写着主频可以跑到170MHz啊！由于死活找不出软件或硬件方面的原因，几近内心崩溃。甚至不直觉地开始怀疑该芯片是否真的支持170MHz的主频。所以他的问题简单直接，STM32G4到底支不支持170MHz的主频？关于STM32G4系列的主频参数，是最基本而核心的一个参数，手册是不可能写错的。何况本人之前也使用STM32G4的开发板做过一些测试，都是基于170MHz进行的。鉴于这种情况，我们首先可以检查一个参数，即CPU通过FLASH控制器取指时的那个延时等待参数，它配置得是否合适会影响MCU的正常工作。我们知道CPU的访问速率通常要比FLASH控制器的取指速率快得多，这个延时等待参数的配置需要跟CPU的主频匹配。各个STM32系列的参考手册里都有个对照表。下图是STM32G4系列的。按照上面表格来看，如果内核时钟跑到170MHz,这个Latency参数应该设置为8。经了解，他已经注意到这个参数了，并将这个参数做了正确配置。看来不是这方面的原因，再换个方向看看。主频的提高往往意味着功耗的增大或噪声及干扰方面可能加剧。于是试图从系统供电能力、电源稳定度、时钟稳定性方面查找原因，依然没有发现明显问题。建议他对STM32芯片所有电源或电源相关管脚逐个排查连接、焊接情况，当然也包括VDDA脚的连接情况。遇到类似这种没法一下子从软硬件上找出与异常症状之间明显的逻辑关系时，这样做往往是个简单而且比较有效的排错办法。经针对相关管脚的逐个排查，很快发现芯片的VDDA脚虚焊了，重新处理后芯片于170MHz运行稳健。问题终于得以解决。看到这里，相信很多人会认为该问题不复杂、也谈不上深奥，可这类问题原因往往容易被我们忽视掉，难就难在一会半会想不到可能的原因所在。在我们的实际调试过程中可能很多类似的问题，虽谈不上多么复杂或深奥，但往往由于我们内心深处从头到尾存在对某些点的忽视或者想当然，导致一时半会找不到问题原因而耽误时间。比方一个大小端的选择、一个变量数据宽度的适时调整、一个虚焊的BOOT脚等，它们都很可能将我们困住好一阵子。在此分享相关案例，

偶尔会有人问起STM32芯片的GPIO做输出时还是否可能作为外部中断触发输入，这里一起聊聊该话题。作为STM32芯片，其外部中断触发源可以是硬件模式或软件模式。所谓软件模式就是通过操作相关寄存器产生内部中断触发信号并向内核NVIC控制器申请中断。硬件模式自然是指来自GPIO引脚的电平跳变信号经边沿检测器形成中断触发信号向内核申请中断。【注：还有个别外设事件也可以作为外部中断触发源映射到外部中断控制器。】我们这里要谈的是基于硬件模式的外部中断话题。当STM32的GPIO作为输出时，可能是通用GPIO输出也可能是基于其它外设复用情况下的输出，即复用输出。下图是GPIO作为基本输入输出时的功能框图。下面是GPIO作为其它外设的复用输出脚时的功能框图。不难看出，所谓GPIO复用输出，就是将自身输出数据寄存器与输出控制电路及外部管脚断开来，并将输出控制电路及外部管脚借让给其它外设使用。通俗点说，所谓GPIO复用输出就是其它外设找GPIO借道而已。从上面两幅图来看，不论GPIO通用输出还是复用输出，外部管脚的电平都可以连接到内部输入单元，管脚上的电平也应该可以被内部边沿检测器检测到。也就是说，即使GPIO作为输出，只要管脚上的电平跳变能被边沿检测器识别，按理可以作为外部中断触发源。下面不妨用个简单的实例验证下。这里使用一块STM32F4系列的开放板，通过定时器1的通道1输出8个PWM信号，同时将该定时器输出通道所用管脚PA8配置为上升沿触发的外部中断输入。PC13接一个按键，每按键一次启动定时器输出8个脉冲。我使用STM32CubeMx图形化工具进行配置。因为要把PWM输出脚同时配置为外部中断输入这里不好操作。我先借用旁边的PA9进行配置，等生成初始化代码后我再将PA9改成PA8以及对应的中断矢量。TIM1配置在单脉冲模式，我在PC3按键中断里启动TIM1的计数器。TIM1的基本配置如下：再就是两个GPIO端口PC13/PA9的EXTI配置，分别对应按键脚和PWM输出脚。将时钟、调试口等配置完毕后生成初始化代码，然后在代码里将之前基于PA9生成的代码改为基于TIM1-CH1的输出脚PA8的。主程序功能代码很简单，就是配置TIM1-CH1的pwm输出。在用户按键中断程序里启动TIM1的计数器。在基于PWM输出脚PA8对应的外部中断程序里对中断次数进行统计。因它被配置为上沿触发，每次连续输出8个脉冲的话，统计值应该为8。下面看看代码运行结果：每按键一次输出8个脉冲，没有问题。再看看基于这个8个输出脉冲统计到中断次数，也确实为8次。【如下图所示]显然，当GPIO做为输出时还是可以感受到外部管脚电平的变化情况，并可以做为外部中断触发源申请中断。结合上面GPIO输出模式下的功能框图来看，当它被配置为输出时是具备双向特性的。当然，一般来讲，如果希望GPIO做为双向驱动口使用时，建议将其配置为OD开漏结合上拉模式。比方在做I2C应用时，将通信GPIO端口配置为开漏模式结合上拉电阻即可进行双向数据通信，无须对通信口的GPIO模式来回切换。=========================往期话题阅读链接【点击即可阅读】：1、STM32

我们在MCU的嵌入式应用开发过程中，有时需要做些较大量的数据传输和适时处理，此时使用DMA的双缓冲模式可能是个不错的选择。这样既可以保障数据的连续、流畅传输，又能保障数据的及时处理【包括数据更新】，同时又能减轻CPU的负荷。

有人使用STM32芯片开发产品，其中有个功能就是统计某外部信号脉冲个数。他采用外部中断方式，来一个信号触发一次中断，在中断程序里实现计数累加。但由于被统计的信号频率较高，而中断本身也是需要时间的，往往导致有些脉冲没被统计而发生丢数的问题。况且，CPU这样频繁地去响应中断还会衍生出其它系统性问题。

有人使用STM32F303VC开发电源方面的产品，想使用4个ADC模块进行同时采样转换，感觉不知怎么实现。这里简单介绍下实现过程，以供参考。

STM32系列的芯片里都有个特别的存储区---FLASH选项字区域，这里简单聊下该话题并顺便给出基于STM32F0芯片的代码实现及几点提醒。这块特定的FLASH存储区域，通常用来存放有关芯片内部FLASH读保护、写保护、看门狗使能方式、芯片启动、RAM校验、电源监控等配置信息。具体内容以及格式因不同的STM32系列可能有差异。一般来讲，各个选项字由选项字节组成，各选项字节由原始字节项和互补字节项组成。如下图存储方式，绿色栏为原始选项字节，黄色栏代码互补选项字节。不同系列可能有差异。【下文中截图如无特别说明，均是来自STM32F0芯片的参考手册。】FLASH选项字一般安排在某固定地址起始的一块连续的地址空间。下图就是STM32FO芯片内部FLASH选项字的地址及内容结构安排。这里包括读保护选项字节、用户选项字节、扇区写保护选项字节。对于出厂的芯片，FLASH选项字往往具有初始出厂值。下图就是STM32F0芯片出厂时FLASH选项字的初始值。但在我们的实际应用中往往需要结合实际应用情况，对FLASH选项字进行重新配置。而对FLASH选项字进行重新配置一般有两种方式：第一种，通过编程烧录工具进行选项字的配置并写入。比方使用STLinkUtiliy或STM32CubeProgrammer或其它类似编程工具来实现。这种方式相对较为简单，一般对操作人员往往有些要求。尤其在有意或无意弄错配置选项的情况下，没法快速发现并及时纠正。另外一种方式就是用户在应用代码里根据应用需求做FLASH选项字的配置编程。这种方式，对开发人员来讲会增加了一些工作量。但烧录时只管烧录FLASH执行代码即可，关于芯片配置方面的信息在代码里自行完成。即使烧录时出现选项字的误操作，用户程序代码也可以将其自动纠正过来。不论使用哪种方式修改FLASH选项字的配置,要想新的选项字信息真正起作用，还有个对FLASH选项字信息进行加载的环节，即将FLASH选项字的配置信息加载到选项字寄存器，从而作用于芯片的相关功能，也就是上面提到过的读保护、写保护、看门狗使能、电源控制、启动选择等功能信息。一般来说，将FLASH选项字信息加载到选项字寄存器需要借助系统复位或上电复位来完成。【当在调试状态下修改FLASH选项字时，它的加载需借助上电复位】在进行FLASH选项字加载之前，芯片硬件会先对选项字信息进行基本地判断与确认，即将各个原始选项字节与互补选项字节的进行匹配比对。如果比对失败将产生出错事件，并将比对失败的选项字节【原始字节和互补字节】强制修改为0xFF或其它指定值，视不同的STM32系列而定。比方，下面就是STM32L4系列做选项字加载前发生原始项与互补项信息比对不匹配时的处理原则：关于FLASH选项字信息地编程修改，这里特别提醒几点：第1点，当准备好要修改的选项字信息，在对FLASH选项字进行编程修改之前，需先对FLASH选项字区域进行擦除。发出擦除指令即可。擦除完毕之后再将新的选项字信息写入选项字区域。那么为了保障选项字正确有序的编程写人，在做FLASH选项字的编程时，一定要保持电源的稳定。【比方说，代码里稍作延时等上电稳定后再操作】如果正在做FLASH选项字编程时发生电源电压剧烈波动或重启，很可能发生FLASH选项字区域被擦除了但又没有正确写入新的选项字信息的情况。而且，前面也提到了，如果选项字因为没有被完整地正确写入，在做FLASH选项字加载前，还会由于原始项与互补项做信息比对失败而被强行修改为OxFF或其它指定值。下面两幅截图就是使用烧录工具软件【STM32CubeProgrammer】，在做flash选项字编程时通过模拟芯片被强行断电所发生的情形。本来,开始做FLASH选项字编程时,RDP保护配置都是选择的LEVEL_0。在选项字编程时芯片被中途断电重新后连接所看到结果却是芯片被读保护了,其它配置字也被擦除了。从截图中可以看到，此时RDP=0xFF,既不是0xAA也不是0xCC，那么芯片的读保护等级就相应地变成了LEVEL_1读保护状态了。有人碰到此情形时往往感到纳闷不解，明明自己没有修改RDP的配置怎么RDP的保护等级变了呢？就是因为中途断电，选项字区域刚被擦除又还没来得及完整、正常写入。当然，做FLASH选项字编程时除了要求电源稳定外，编程时序也需遵照手册介绍的来操作，以保证选项字编程的正确性。第2点，对于某些双BANK的STM32芯片，比如STM32L4，STM32F42X等系列，在做选项字编程调整时，也是先将两个BANK的用户选项页的内容进行擦除，然后依据用户准备好的选项寄存器的内容对所有选项字内容重新编程更新。这里要注意的是，我们不能只是单独地针对双BANK其中的某一个BANK进行用户选项字调整，而是需要将BANK1和BANK2的配置信息都准备好并写入相应的选项字寄存器，从而实现对两个BANK的选项字信息的编程修改。第3点，在做选项字编程过程中，如果修改读保护选项时，一定要清楚-----如果是从LEVEL_1调整为LEVEL_0将会发生整个芯片内部的FLASH内容被全部擦除的情况。另外，很多STM32系列支持LEVEL_2读保护，该保护等级具有不可逆性。如果选择该等级，除非你自己在芯片内部准备好了升级引导代码，否则你是不能再对片内代码内容做任何更新，更不可能基于该芯片再做调试了。好，关于STM32芯片的选项字的编程提醒就聊到这里。感觉上内容应该不多，但由于STM32家族拥有众多系列，同时各个系列间在选项字这部分内容又或多或少存在着差异，让内容突然庞杂了很多。这里只能抛砖引玉似地给些提醒，具体应用时请参考各个STM32系列的参考手册及编程手册。下面就以STM32F072芯片为核心的Nucleo板，给出一个实现用户选项字编程的示例。先看看STM32F072片内选项字区域的基本内容框架，如下图：一、选项字内容的规划与准备：这里我将RDP选项字节配置为0xbb,即LEVEL_1,则其互补选项字节内容就是0x44；将USER选项字节下面红色方框内的三个选项置1，另外两个保留位置1，那么USER选项字节的内容就是OxEA,它的互补字节就是0x15.选项域中的Data0字节配置为0x99,则其互补字节nData0则为0x66;选项域中的Data1字节配置为0x88,则其互补字节nData0则为0x77;按照上面规划准备好数据，如下图所示。各选项数据按原项和互补项组成半字写入。【顺便说下，这里没有对扇区写保护做配置。当然要做也是完全可以的】二、编写相应程序代码，编译后下载到芯片：相关代码不长，较为简单。按照手册描述的来编写。我将上述代码分成6部分。第1部分，做有关选项字节内容的判断，是否均为预期的选项配置内容。第2部分，对FLASH、OPTION编程做开锁操作。第3部分，对选项域进行擦除，然后退出擦除状态。第4部分，对欲修改的选项字节进行编程修改。第5部分，完成选项字的修改与编程后，上锁并退出。第6部分，触发系统复位，将新的选择域内容加载到选项控制寄存器。三、运行程序，验证结果运行用户程序实现选项域的编程修改操作。可连接到STLINK

某STM32用户反馈，他使用STM32L031芯片开发产品遇到低功耗异常的问题。基本软硬件及开发环境如下：硬件：STM32L031、外部晶振32.768

很多STM32系列的MCU内置高精度定时器，比方STM32F334、STM32G4、STM32H7等系列。利用高精度定时器实现PWM输出应该说是最基本的功能了。不过，在实际应用中，常有人觉得无法实现duty=0或duty=100%的PWM输出情形。这里以STM32F334的HRTIM为例，简单介绍下利用它实现PWM输出的实现原理。

某STM32用户开发产品，用到ADC模块，通过定时器更新事件触发AD转换，转换结果由DMA搬运到指定的内存区域。DMA工作在正常模式（即非循环模式），每当传输完毕一批数据后在传输完成中断里设置传输结束标志,应用代码对该标志进行监视。

意法半导体ST公司为广大STM32用户提供了免费的图形化设计工具TouchGFX,同时还准备了一个内容非常丰富、详实的免费学习站点，内容还在不断完善和更新中，这里特意推荐下。点击左下方的阅读原文即可进入相应链接。当然，也可以直接键入下面链接地址前往学习。【注：手机模式下图片可以放大查看】https://support.touchgfx.com/

STM32家族中的有些系列，比如STM32G0/STM32G4/STM32L4+/STM32H7等系列都内置了DMAMUX模块，它是干什么用的？跟DMA有什么关联？

绝大多数STM32系列的芯片都在固定的地方放置了长度为96位的唯一身份识别码，简称UID，只有极少数STM32系列芯片内部没有该UID，比方超值型STM32F0x0系列，STM32F100系列。具体到哪颗芯片到底有没有UID,在芯片数据手册的首页都有明确的说明，无需猜测。如下图所以：芯片所对应的参考手册里，有对该UID存放地址的详细介绍。地址因不同系列或子序列而不同。关于这个UID常有人有些疑问，有几个问题在这里稍微总结下：1、有无问题。上面说了绝大部分STM32都内置UID,具体以查看数据手册为准。2、唯一性问题。该UID的唯一性是靠96位这个整体来保证其唯一性，你若截取部分就不保证了。3、内容问题。有人对这个UID内容似乎很好奇，这点在STM32参考手册里并无详细描述，但这并不影响使用。【因为STM8有些芯片也有96位UID，那里有较为详细的介绍，涉及芯片WAFER生产加工工程中的一些各种坐标信息、wafer编号信息、产品批号信息等】4、地址问题。芯片UID的存放地址要到芯片对应的参考手册里去查对。特别要提醒的是，并非所有STM32系列的UID信息存放在某个起始地址开始的连续空间内。5、怎么用的问题。说实在的，这个就很难说了，反正STM32有这个特性在，肯定没有固定不变的用法。具体怎么用就看你自己了。对于该UID，STM32参考手册给了些大致应用方向的介绍：简单点说,该UID可以做特定序列号；做FLASH编程的安全密钥；激活安全启动流程。据我所知，曾有人拿这个UID码作为唯一发射码。中间按个做密钥配合加密技术的应用涉及到很专业的内容，

很多STM32系列的MCU内置高精度定时器，比方STM32F334、STM32G4、STM32H7等系列。利用高精度定时器实现PWM输出应该说是最基本的功能了。不过，在实际应用中，常有人觉得无法实现duty=0或duty=100%的PWM输出情形。这里以STM32F334的HRTIM为例，简单介绍下利用它实现PWM输出的实现原理。

在STM32低功耗系列STM32L1产品线中，有些料号之间仅仅多了一个字母A的差别。经常有人问起这类带A与不带A的差别。如果下图所示的一些料号：整体上讲，对于那些料号多了字母A的芯片，是后期推出的基于新工艺的芯片，将取代之前那些相应的不带A的料号。换言之，不带A的料号产品被归为不推荐使用产品，将逐步被带A的料号取代。带字母A料号的芯片在硬件管脚上完全兼容不带A的同型号产品，如果是从不带A的料号移植到带A的芯片上来，绝大部分场合是不需做任何调整的。当然，带A的产品在不带A产品基础上拓展或提升了部分特性，比如LCD驱动【STM32L1x2系列才有】、RTC、PCROP、动态功耗等方面。

有人使用STM32L476芯片开发产品，他想在内部FLASH空间特定位置写些数据，发现总是失败，并补充说之前使用STM32F1系列、STM32L1系列却没有类似问题。

偶尔有人反映，说在基于KEIL_MDK开发环境下做STM32H7芯片开发时，没法下载程序代码进行调试，有的还特意说V版本的芯片不行，而别的版本H7芯片又没问题，比方Y版本、Z版本什么的都可以。也有的人还反馈说，当把开发环境转至STM32CubeIDE时又可以了。关于该问题，我特意使用MDK环境做了验证测试，不论什么版本的STM32H7芯片，可以肯定都是能够下载调试的。当遇到类似问题时，我们可以从下面几点找找原因：一、STLINK调试器的固件版本要保持更新。这点我们可以通过STLINK

在STM32定时器应用中，我们有时希望基于某定时器事件同时对定时器的多个寄存器进行读写访问。为此，STM32芯片设计了专门应对定时器的多寄存器访问应用的DMA

某STM32用户使用STM32F407芯片开发产品。用到内部3个ADC，其中ADC1与ADC2工作在ADC双模式，ADC3独立工作。运行代码时给FLASH开锁编程后，发现ADC3不工作了（其DR数据寄存器似乎不更新了，倒是用来触发ADC的定时器TIM2依然正常），Flash编程前后ADC3配置寄存器CR1、CR2没有发生改变。如果重新配置ADC3后就能正常工作。从问题现象来看，初步感觉跟flash编程有些关系。经了解，客户的确做了flash编程，有一部分参数需要存放在FLASH内。他的ADC3是由TIM2触发的，ADC3的转换结果是通过DMA搬运。鉴于此，我这边便提醒他，如果不是基于双BANK条件，在flash编程时CPU是堵塞的，此时若发生中断不会得到响应,让他注意这点及因此可能导致的问题。客户进一步反馈确认：1：通ADC结果过DMA读取，并非中断方式获取；2：FLASH编程过程中禁止了所有中断；3：奇怪的是ADC3改为由软件触发则没有异常现象。用来触发ADC的定时器一直计数正常，并且只要重新配置ADC3（无须对触发定时器重新配置）也能恢复它的正常工作。

有STM32用户使用STM32F3系列MCU开发产品，想利用片内定时器实现移相全桥的PWM波形输出。具体要求如下，并希望输出下图所示波形：1、A与B波形的频率及占空比相同，波形错位的时间需可调，如图上半部分所示。2、A与/A是同频率、同占空比的互补波形，两个波形的高电平之间可插入死区。3、B与/B的关系同A与/A，如图中下半部分的图示。要实现上面的波形，我们可以通过灵活运用比较输出的toggle模式结合DMA来实现，不过，这对很多人来说，难度可能有点大。具体到这里，因为他选择了STM32F3系列，而STM32F3/L4/F7/H7等系列的定时器都具备非对称PWM输出模式或组合输出模式，若使用非对称PWM输出模式实现上述输出就比较方便省事。下面一起来看看。

某STM32用户开发产品，用到ADC模块，通过定时器更新事件触发AD转换，转换结果由DMA搬运到指定的内存区域。DMA工作在正常模式（即非循环模式），每当传输完毕一批数据后在传输完成中断里设置传输结束标志,应用代码对该标志进行监视。

我们在使用STM32定时器做PWM输出过程中，当借助示波器或逻辑分析仪查看波形时，有时会发现输出的第一个PWM脉冲跟后续的输出脉冲不一样。比方像下面的输出波形，第一个脉冲的高电平要宽于所有其它后续脉冲。对于这种情况，有些应用是不太在乎的，但有些应用场合可能就不能接受。那这个问题是怎么产生的？有没有办法解决？产生这个现象的原因简单点说就是在于定时器比较输出模块的工作与定时器计数单元的工作具有相对独立性。使能比较通道的输出功能的操作与使能计数器的操作有个时间差，其长短往往跟用户处理代码有关。我们知道，STM32的高级定时器或通用定时器，可以大致看成由四个模块组成，分别是主从控制模块、时基单元、输入捕捉模块、输出比较模块。下面截图是STM32F4系列高级定时器TIM1的功能框图的一部分，这里没有将定时器的主从模块截取进来，只保留了时基单元、输入捕捉单元、输出比较单元。这三个单元既可以相互配合协调工作，也可以各自独立工作。比方说，输出比较单元的工作并不要求时基单元的计数器工作，换言之，即使计数器不被开启计数，输出比较单元依然可以根据默认配置或用户的有关输出配置而发挥作用。我们不妨结合一个具体实例来看下。假设定时器TIM1的计数模式选择向上计数模式，让通道CH1按照PWM1模式的规则实现PWM输出。配置好ARR和CCR1,极性选择高有效，即OC输出与OCRef参考信号保持同相。对于定时器的初始化，我们一般会先对时基单元的相关参数做配置，比如时钟源、ARR,PSC等，然后对比较输出功能做配置和使能。当完成比较输出的配置及使能后，即使此时没有使能时基单元的计数器，比较输出单元就发挥作用了，即它会结合比较输出配置和CNT与CCR的比较结果在OC端输出相应电平。根据上述配置，若CCR大于计数器CNT的值时OC端输出高电平，否则输出低电平。若用户没有专门对CNT寄存器进行赋值，芯片复位后，它的默认值就是0,显然CCR的值要大于此时的CNT的值，自然此时OC端就输出高电平。如果此时计数器还未被开启，这个高电平就会保持到计数器被启动，并延申到后续的PWM输出动作中。即这个高电平会跟第一个PWM脉冲的输出连在一起。若刚好碰到第一个PWM脉冲首先是输出高电平，这就导致第一个脉冲的高电平宽度要宽于后面其它所有PWM脉冲的。下图第1处乃通道OC功能配置完成被使能的时间点，第2处乃计数器被启动时间点。在跟上述相同模式和极性条件下，有没有办法消除第一个脉冲的多余宽度呢？办法是有的。既然OC通道被使能后，其输出由CCR与CNT的比较结果和PWM模式决定，这时我们可以考虑在使能OC通道之前手动将CNT的值进行修改，让它等于ARR或0xffff【若是32位计数器就是0xffffffff】，此时CNT的值不可能会小于用户配置的CCR值，就这样通过改变CCR与CNT的比较结果达到改变OC端输出电平之目的。比方，如果你用STM32标准库写的话，你可以在下面红圈的那个地方加一句：【arr对应着时基单元中ARR寄存器的值】参照上面相同定时器配置【向上计数模式、PWM1模式、极性选择高有效】，下面基于Cube库使用STM32F4的TIM1的通道2进一步做个验证测试。使用CubeMx配置完成生成初始化代码，需添加的用户代码比较简单。如下图所示。其中方框里的延时函数代码是用来模拟比较输出使能与使能计数器两个操作间的间隔，以便观察效果。基于上述代码，我们通过示波器可以看到第一个脉冲明显宽于其它后续PWM脉冲。【如下图所示】在上面代码的基础上，我们在使能CH2比较输出功能的代码前添加一句修改CNT寄存器的语句，令其值等于ARR或等于计数器的满量程值。下图中椭圆圈内的代码。【若把CNT值改成等于ARR的值，效果也一样】然后再进行测试，第一个脉冲也就不再异常了。【如下图所示】最后小结下，这个现象只有在使能定时器通道的比较输出操作与使能计数器操作存在较为明显的时差时才可能发现，而且它还跟所选择的PWM模式有关，上面只是针对向上计数模式、PWM1模式做了分析和分享，当涉及其它应用模式时可具体问题具体分析，只要弄清原因了也就不难灵活应对。==========================往期阅读话题链接【点击阅读】：1、定时器输出4路不同频率波形的应用示例2、基于STM32H7片内FLASH编程失败的话题3、基于STM32H7

有人选用STM32系列的一款低功耗芯片STM32L431进行产品开发，在其应用中需要通过STM32芯片驱动一个小尺寸显示屏，由于所选芯片不带FSMC外设，所以就想使用GPIO来进行图片数据的更新。显示屏控制器数据宽度选用16位，通过GPIOA与之连接，另外，同时还用到一根口线模拟下面的读写控制线，该控制线平常为高电平。在读写控制线的下降沿进行数据的准备，即MCU将图形数据送到数据总线上，在读写控制线的上升沿显示屏的控制器将数据取走。这里我们想到了借助定时器输出一路PWM信号来模拟那根读写时序控制线，利用定时器的输出比较事件触发DMA，将数据送到GPIOA端口，然后在上升沿由屏控制器读走数据。在DMA的传输完成中断里关闭定时器的PWM输出从而停止数据传输。按照上面的思路来编程进行调试后发现个问题，那就是在DMA传输完成中断里去关闭定时器的PWM输出时，这个停止动作不能做到很及时，尤其在数据传输速率较高时，即这个PWM输出停止操作有个延时，往往会导致多输出几个不必要的PWM脉冲。比方本来计划发送500个数据,读写控制线相应地也应该只输出500个PWM脉冲信号，然后维持在高电平，但程序代码是在完成了500个DMA数据传输后才去关闭定时器的PWM输出，由于中断响应的时间加上关闭定时器输出的代码执行时间可能会导致多输出1个或2个不等的PWM脉冲后才停下来【说“可能”是因为它跟传输速率和处理代码有关】，这些多输出的脉冲虽不会触发DMA传输了，但其上升沿还是会触发显示控制器的数据读取操作，而这多读取的数据并非正常操作，进而会影响产品功能。【下图所示红色脉冲即多出的PWM信号】那有没有办法让定时器的PWM输出个数跟DMA传输的数据个数刚好一致呢？即若要传输500个数据也就刚好输出500个PWM脉冲。这里有个比较简单的办法，就是使用STM32高级定时器的重复计数器和定时器输的单脉冲输出模式来实现上述要求。所谓单脉冲输出模式，其基本原理就是定时器的计数器开始工作后，当碰到定时器更新事件时则停止计数工作，从而实现有限个数脉冲的输出。对于不带重复计数器寄存器的通用定时器，若工作在PWM输出模式，计数器启动后输出一个PWM脉冲则停止；若是带重复计数器寄存器的高级定时器，工作在pwm输出模式时，计数器启动后则输出指定个数的PWM脉冲后停止计数，具体的PWM脉冲输出个数由RCR寄存器的值与所选择的计数模式【向上计数模式、向下计数模式、双向计数模式】决定。关于定时器单脉冲模式细节请查看STM32各个系列的参考手册，下面阅读推荐的《STM32定时器单脉冲输出模式话题》也可以参考。结合到这里的应用，我们可以将方案稍做调整。使用高级定时器【这里使用TIM1】的一个输出通道来实现读写控制时序脉冲，计数器采用向上计数模式，定时器采用PWM1单脉冲输出模式，输出的脉冲个数跟DMA待传输的数据个数保持一致，仍然通过定时器比较事件触发数据的DMA传输。这样的话，定时器输出指定个数的PWM后即自行停止输出，不再需要软件代码的干预，而且最后将输出锁定在高电平，刚好满足设计要求。【注：使用定时器单脉冲输出模式，当定时器停止计数后，输出端最后锁定的电平跟所选用的PWM模式和RCR寄存器的值以及计数方式三者有关。】比方要写入10个【数据弄小点便于示波器观察】图形数据到显示控制器。则配置RCR=10-1;采用PWM1单脉冲输出模式，向上计数方式。通过示波器我们可以看到如下输出：这里比较巧妙地使用了高级定时器地单脉冲输出模式，做到了MCU写多少数据，屏控制器就读取多少个数据，不多不少。顺便提醒一下，当完成定时器的初始化后，在使能定时器更新中断或基于更新事件的DMA之前，记得对更新中断事件标志位先做个清零操作，否则有时可能会给我们带来些困扰，比方一使能定时器中断就跳入中断服务程序或者刚使能基于更新事件的DMA传输就发生DMA传输。ST固件库中的参考代码如下：__HAL_TIM_CLEAR_IT(&htimx,TIM_IT_UPDATE);该话题之前也多次提醒过，这里再提醒下。还是经常有人在应用中卡到这个地方。其原因是定时器初始化过程中使用了软件更新操作触发更新事件让用户配置的数据即时生效，同时它也使得定时器更新事件标志被置位了。OK,上面主要是分享了一个基于高级定时器单脉冲输出模式的一个应用示例及思路。如果是通用定时器，它没有RCR寄存器，是否还可以实现上述功能呢？应该也是可以的，有兴趣可以自行思考下。祝愿大家在STM32的产品开发过程中能对各个外设的功能及特性灵活运用，不断开发出自己满意的产品。最后，让我们祈祷眼前的新型肺炎疫情早点过去！愿一切尽早回归正常！===================================往期话题阅读链接【点击阅读】：1、STM32定时器单脉冲输出模式话题2、基于ARM

一般来讲，一个STM32定时器输出基于同一频率的各路信号比较方便。但经常也会有人问使用STM32一个定时器是否可以实现多路不同频率的输出。从实现这个功能角度来讲，答案是肯定的，并可以满足相应的应用需求。这里利用STM32G4的Nucleo开发板进行一个简单的实现示例,顺便交流和分享些思路，以拓宽STM32定时器的应用场景。示例中使用STM32定时器输出模式中的比较切换模式，即Toggle模式，结合定时器的比较事件及DMA传输来完成。我使用STM32G431RB片内TIM1，通过它实现4路不同频率的PWM输出，分别是20KHz，50KHz，70KHz，80KHz，让TIM1运行在10Khz的循环计数状态。TIMER的计数时钟源为170Mhz，没有对时钟进行分频。基于上述条件，TIM1的10KHz更新频率所对应的计数脉冲个数则为17000，那么，20KHz、50KHz、70KHz、80KHz所对应的计数脉冲个数分别是8500、3400、2428、2125，分别对应着TIM1四个通道CH1/CH2/CH3/CH4的PWM输出。【可参考下面表格】现在开始使用STM32CubeMx进行初始化配置。TIM1的时基配置如下:将TIM1的CH1/CH2/CH3/CH4的比较输出模式配置为匹配切换模式。这里关闭了CCR寄存器的预装功能。

MDK进行STM32调试的两个小提醒就分享到这里，以供参考。祝君好运~！====================往期话题链接【点击阅读】：1、基于STM32H7芯片的矩阵运算应用示例2、STM32

在STM32的应用开发过程中，我们有时可能涉及到DSP应用，需要使用到相关DSP函数。这里基于STM32H743芯片的Nucleo开发板，做个有关矩阵运算应用的演示，简单的演示下两个矩阵相乘的实现过程。开发环境选择的是ARM

有人反馈在产品项目中使用STM32H743II芯片，在对片内flash进行编程时遇到点问题。他将片内的第一、二扇区存放用户应用程序，第七扇区用来存储网络应用相关的一些配置信息。他写Flash的过程及有关现象是这样的：关中断->解锁flash->擦除扇区->写入数据->上锁flash->开中断，写入的数据总共40个字节。可是写完之后再去读时，发现只能读取前面32个字节的数据，在调试过程经常莫名其妙地触发硬错中断。这是怎么回事呢？根据该STM32用户的反馈，基体情况就是对片内FLASH进行写操作不成功并衍生出相应问题。我们通过查看数据手册，不难得知STM32H743II片内FLASH为2MB，分为2个BANK.片内FLASH布局如下：我们对STM32H743片内Flash布局有了大致的了解，再去看看有关flash编程的介绍，了解相关规则。从上面描述来看，在做Flash编程时要以256位即32字节为编程单位，或者说8个32位字为单位。硬件以256位做为一个Flash字，并进行读写ECC校验，以保障数据的安全可靠。那结合前面STM32H7用户的反馈，它现在每次是写40个字节的数据，既不是32字节也不是64字节，应该是在这个地方出了问题。如果他使用下面Cube库函数实现的话，它默认每次就是写8个字的数据到指定的Flash空间。HAL_FLASH_Program(uint32_t

我们经常会基于STM32芯片来自行编写用户升级程序，通过该升级程序对片内应用程序代码进行更新升级。我们通常称该过程为IAP（In

我们在做ADC的时候，有时可能要用到多个通道，但并希望它们被同时启动，只是想依据不同的条件在不同的时刻对其中某一个ADC通达进行转换。基于这种应用场景，对有些STM32新手来说似乎还有点困难，这里使用STM32F4系列的一个开发板做个简单的应用演示，以供参考。基本思路是这样的：先使用STM32CubeMx做基本的配置，并生成初始化代码。在用CubeMx配置ADC时，只选择可能用到的多个通道的其中1个进行配置。这里我用到3个通道，分别是ADC1的CH8、CH12、CH17【CH17为Vrefint专用通道】。在用户代码中再做通道的改变。这里ADC选择软件启动。这里我没有开启ADC相关中断，具体应用时可以按需配置。当生成完初始化代码后，我在其基础上借助Cube库重新组织一个函数，用来针对任意ADC通道进行初始化。该函数用到两个参数，分别是通道号和对应于该通道的采样时间。我在main()的主循环里，循环地针对CH8/CH9/CH17进行ADC转换。这里我将CH8接GND，CH12接VDD,CH17内接Vrefint.

这里使用stm32h743-Nucleo板做个基于DMA传输的SPI收发应用示例。选择SPI1，MOSI与MISO短接，通过DMA自发自收，分开启Cache和不开启Cache来配置演示，以供参考。利用STM32CubeMx进行配置，生成基于ARM

有STM32用户使用STM32H7xx芯片进行开发，用到SPI外设。通过定时器定时触发SPI的发送，但发现每次发送的数据跟本来设计的不一样。本来他是希望每次发生定时器更新事件，在更新中断里发送一个16位数据，可他发现发送的数据却是32位，通过SPI的时钟信号可以清楚的看到每次发送的32个时钟脉冲。这是怎么回事呢？经过反复确认，跟SPI有关的配置方面没有发现任何问题。这里我就基于上述问题，稍加拓展地做些验证分析。我找了块STM32H743的Nucleo板进行些验证测试。使用SPI1，让其工作在双工主模式，MOSI与MISO短接，自发自收。首先，我用DMA的方式来传输数据。使用TIM3的更新事件触发DMA，通过DMA将内存数据写到SPI1的发送数据寄存器，同时SPI1的接收也开启DMA传输，即通过SPI1的接收事件触发DMA传输，将SPI1收到的数据搬到内存数组。使用STM32CubeMx工具进行初始化配置。1、对TIM3进行基本配置，并使能更新事件的DMA请求。【这里将DMA配置为循环模式以便测试】2、对SPI1进行初始化配置。工作在双工主模式，数据宽度选择16位，开启SPI接收事件的DMA传输。做些其它有关调试、时钟的配置后，生成初始化代码。准备需要的数据变量并添加相关用户代码。编译无误后，运行看结果。很遗憾，结果不妙！SPI1根本没收到数据，也就是说数据也没发出去。怎么回事呢？难道是DMA访问不到相应的外设或内存？借助调试环境可以看到，目前用到的内存属于片内AXI

刚好也是8MHz,所以测得CAN实际波特率为实际值的1/6.当用户将晶振重新焊接良好后，就一切正常了。那么，到此有人或许会问，是不是这个外部晶振焊接OK、软件配置代码也OK就不会出现这个问题呢？

最近有人反馈，他使用STM32F4系列芯片进行开发，通过STM32CubeMx配置初始化代码，使用了UART的DMA传输。但他发现DMA根本不工作。后来他无意中发现，是因为他在用户代码里不经意地调整过UART外设和DMA外设初始化代码的前后顺序，当他重新调整二者的先后顺序后就一切正常了。他想知道这个顺序是怎么影响DMA功能的。