单片机进入 B. 中断无限循环异常消除方法
目录
一、前言
B.中断就是二、什么
三、我的代码异常情况分析及应对
四、如何修复B.中断异常
五、如果这篇博客能帮到你，请点个赞鼓励一下吧~ξ( ✿＞◡❛)
一、前言
最近长颈鹿在利用芯海的CS32L015单片机进行项目开发，遇到了一些非常少见的错误信息，在使用硬件SPI进行数据发送时，在没有开启SPI中断的情况下，竟然会触发SPI中断，导致系统陷入B.中断死循环中无法跳出，搞鼓了半天终于发现错误原因，后续升级了软件包SDK才解决了这个问题，但我看了一下芯海SDK中SPI部分的源码，进入SPI的第一步，竟然是关中断，实在是小刀喇屁股——开眼了，实在是少见得很。
二、什么是B.中断
B.中断是一个标准默认中断，位于中断向量表末尾，有点像C语言switch语句中的default功能，用于中断意外情况的默认处理。
当系统外设产生了中断请求，但是用户却没有定义对应中断的入口函数时，架构的程序PC指针无处可去，这时就会进入中断向量表中的B.中断中，表示出现了一个未定义的中断请求。由于没有中断处理函数，这个中断标志位还清不掉，导致系统一直响应该中断，程序一直卡在B.中断中，陷入死循环。
三、我的脚本异常情况分析及解决
异常分析：
查阅用户手册得知，在CS32L015中，SPI每次发送一字节数据都会将SPI->SR->IF中断标志位置1，表示资料发送结束，可以读取SPI移位寄存器，在读取数据运行完成后，会自动将这个IF中断标志位清空。
通过但奇怪的是，读取操作并不会将环境的SPI中断Pending标志位清空，通过keil仿真能够看到，系统在进入B.异常中断前，系统中产生了两个中断信号待处理——分别是SPI0_1和TIM10。
中断响应状态(P)却为1，表示环境响应了该中断，这就属于异常现象了。就是其中TIM10中断用于配置体系时基TImeBase，该中断使能(E)为1，响应状态(P)为1；属于正常现象。但是SPI0_1中断使能(E)为0，表示没有配置该中断，但
系统异常现象表现为：
在使用硬件SPI调用一次 HAL_SPI_Master_TransmitReceive 函数发送1字节数据之后，NVIC控制器显现SPI中断执行标志位P置1，但是项目中明确没有配备过SPI中断，此时程序许可正常运行，但只要再次通过硬件SPI函数发送数据，SPI中断执行标志位P还未被复位，又触发了中断信号，架构不知如何响应这个未知中断，就出现了陷入B.中断死循环的现象。
解决方法：
由于我不打算利用SPI中断来进行主机从机的数据通信，所以不存在中断配置缺失一说，只能另求他法，在SPI发送数据和接收数据之前，关闭SPI中断，复位SPI中断标志位，
再次仿真运行，代码恢复正常，查看NVIC控制器，每次发送一字节数据之后，SPI中断Pending位还是会被置1，但是由于及时复位清空中断标志位，所以没有对程序进程造成影响。
四、如何修复B.中断异常
B. 异常中断却不少见，这里有一套解除方法，能够敏捷找到自己项目的异常原因，锁定问题进行消除。流程如下：就是长颈鹿遇到的情况可以说非常少见，但
Keil仿真模式下，在程序进入B.死循环处打上一个断点；
仿真复位，打开Keil中的NVIC中断控制器；
打开方式：
3.全速运行仿真，程序第一次进入B.异常中断，停止在断点处；
4.查看此时NVIC中断控制器中的中断情况，找出异常中断（例如我这里遇到的问题是SPI中断异常，那就对SPI进行彻底的分析）；
5.查看代码中，①是否配置该异常中断，②是否设计对应该异常中断的中断回调函数，③是否存在清中断标志位操作；
6.根据自己的情况完善异常代码。