有人利用STM32F303芯片开拓产品，用到SPI1外设。SPI事情在主模式，不定期地通过SPI接口读取外部ADC芯片的数据。他创造在MDK KEIL调试模式下并打开SPI外设寄存器窗口时就能正常事情；其它状态下SPI就不正常事情。也便是说只有通过进行下面操作并打开SPI1的寄存器窗口时才能正常事情。
客户还补充道，他的软件代码之前在STM32F103VE上利用是没问题的，移植到32F303这个电影上才涌现问题。【注：后来的结果证明，这个补充每每无意中把人往沟里带了。移植过程中前后工程代码细节上的差异客户自己实在也未必清楚。】
从客户反馈的问题征象来看，根据履历判断很可能是某些SPI干系的标志位在他的代码里没有及时做打消操作导致了非常，尤其那些被读取后内容发生变革的寄存器或寄存器标志位。以是，一边提醒该用户负责检讨SPI有关标志寄存器的变动情形，一边自己去查看STM32F3参考手册中有关SPI的寄存器读写特性以及STM32F303干系的勘误手册。
从勘误手册上没看到干系问题的内容。从SPI各个寄存器的读写属性，尤其读属性上没有很快创造读与不读而导致内容差异的寄存器或寄存器位。但基本可以肯定问题出在代码上。客户是基于之前的标准库移植过来的，便建议他干脆基于Cube库和他现有硬件重新建立个大略的SPI读写工程项目。
很快客户进一步反馈，他在我的提示下重点检讨了SPI_SR状态寄存器的内容及变革情形，并找到办理办法，至于缘故原由不是很清爽。
他反馈说，当他把所有SPI寄存器用变量显示出来，创造个中SR寄存器确实有置位的情形，即那个数据溢出标志位OVR@SPIx_SR 被置位，提示发生吸收溢出。
既然这个标志位置1了，解释SPI_DR寄存器数据由于没被及时读取又来了下一个数据而发生溢失事宜，导致后续数据无法正常吸收。如果此时开启了OVR干系中断的话，会进一步触发中断。鉴于此，客户对其代码轻微做了调度，担保每次开始读外部数据之前OVR是被清零的。
把稳，对付OVR位的清零必须遵照如下软件序列：
即先读SPI_DR寄存器，然后读SPI_SR寄存器才能达到打消OVR的目的。
看到这里，非常问题办理了，缘故原由也彷佛找到了。缘故原由便是数据溢出而导致后续数据没法正常读取。但是，数据溢出为什么偏偏只发生在SPI寄存器窗口没打开的情形或者是非调试状态下呢？看来，这还是个问题。
我们知道，发生溢失事宜是缘于SPI_DR寄存器的数据没有被及时读取而导致。在非调试状态下，用户程序没有通过CPU及时读取DR寄存器导致溢出，这不难明得。那调试状态下用户代码依然会发生没有及时读取DR寄存器的环境，怎么在SPI外设寄存器窗口打开调试状态下就不会发生溢失事宜呢？难道还有其它组件浏览过DR寄存器了？
除了CPU可以访问DR寄存器外，真还有其它组件可能访问它，比方DMA。显然，这里DMA可以打消在外，由于DMA访问DR寄存器不分调试和非调试状态。那还有个东西，便是调试组件，它也可以访问外设寄存器。下面是STM32F3所属ARM Cortex M4内核的框图，内核框图中的黄色区域我把它称之为调试组件,它跟NVIC一样属于核内部件。
我们的程序调试、下载一样平常离不开这个调试组件。
在我们的代码调试过程中，当打开相应外设的寄存器窗口时，IDE为了实时显示各个寄存器的内容，自然就得实时地通过调试组件读取外设寄存器的内容，并显示在我们面前。
详细到这里，我们在调试状态下打开SPI外设的寄存器窗口时，外设组件就会一直的去读取SPI各个寄存器内容并显示出来。显然，当SPI从外部ADC芯片读到数据后，对付SPI_DR数据寄存器的内容，即利用户代码没有去读，调试组件一定会去读，这样就避免了发生数据溢出的情形。换句话说，如果没有开启SPI寄存器的查看窗口，当SPI收到数据而没用被户程序及时读取的话，下次新来数据时就会发生溢失事宜。
这便是为什么开启SPI寄存器查看窗口时功能正常，而关闭SPI寄存器查看窗口时功能非常的真正缘故原由。
稍眇小结下：
在基于STM32的数据通信过程中，因数据溢出导致非常是比较常见的事情，也是比较随意马虎忽略的一个地方。发生溢失事宜后，每每会导致后续数据无法正常吸收，还可能触发溢出中断，如果忽略了溢出标志的清零还会导致没完没了的进中断，同时它还会影响数据传输的DMA要求的正常触发。在STM32的开拓过程中，除了CPU、DMA可以访问各种寄存器外，调试组件也可以访问各种寄存器。在程序运行过程中，有些寄存器会由于“被读了”或“没有被读”而衍生出不同结果或不同状态位。这点要把稳，这些细节每每离不开对技能手册内容的把握。转载自：茶话MCU
文章来源于一个SPI通信功能非常的案例
原文链接：https://mp.weixin.qq.com/s/e7H1PZLmNNbdFsh4PGEGeg
