这两天遇到一个问题，大概就是程序跑一半嗝屁了，然后嗝屁在了一个非常奇怪的地方。

9 O# Q' t# f$ j

0 D5 N& W, |% m+ M, g4 x" A首先呢，我是怀疑变量出问题了，因为很显然，我们卡在了赋值这里，难不成是double类型的赋值出现了问题？
  M( E& J/ v9 S( c: H
4 D: \0 Y+ ]. o" t6 k首先我尝试将double类型修改为了float类型，这里虽然觉得很大的可能并不是这个的原因，但是没有办法，程序确确实实卡在了这么个奇怪的地方，我当然也怀疑单片机在处理双精度浮点数是不是出问题了。
1 Y! X  C4 b3 L! S4 u$ u0 c
不过随着我修改完数据类型，问题并没有得到有效的解决，程序依旧是在这里卡住。
0 S, h  W* H5 e3 ^4 o# ?
1 ~. V* ^: l8 f) a不过有一点非常奇怪，程序是在这个地方卡住没有错，但是卡住的位置会在这两个语句之间切换，就是可能是这条语句，也可能下一条语句！这时候我已经有一点懵逼了，不过为了确认程序卡在了哪里（通常这个情况是进异常中断了）我们暂停程序，查看程序指针当前的位置。
0 I0 t; b! @. U6 I" x  d( S

1. void HardFault_Handler(void)
   
2. {
   
3.   /* USER CODE BEGIN HardFault_IRQn 0 */
   ( r0 ^" k( ^% Q* J
4. 
   
5.   /* USER CODE END HardFault_IRQn 0 */
   
6.   while (1)
   8 W: A0 B# z7 e" A5 j" a! Z0 {
7.   {
   6 f1 e/ G$ y, |( \+ \2 r
8.     /* USER CODE BEGIN W1_HardFault_IRQn 0 */
   
9.     /* USER CODE END W1_HardFault_IRQn 0 */
   
10.   }
    
11. }

复制代码

0 h2 d: ^% n2 J我发现程序指针所在的位置非常的奇怪，程序指针这时候卡在的地方是一个异常中断没错，但是这个中断回调函数的所在.c文件居然是dma的附属文件，没错这份工程是开了ADC的DMA采样的，采样的数据是传输进入DMA的。
! y# q3 ?9 @/ J8 m- R9 p/ y6 d
这说明问题的主要的原因和DMA有关系，并且查看关于这个中断的说明造成这个中断的主要原因是：
未完成硬件初始化而使用硬件
& W9 R( _0 H3 k/ A" B数据越界
野指针
. T3 H: C  j- o1 {+ [# `% D
其实这三个的问题都可以归类为指针问题，而由于我的程序是初始化部分是正常执行的，那么可以排除硬件初始化未完成导致的异常。
至于野指针也几乎没有出现使用指针而未声明的情况。

因此大概率是数组越界导致的原因，结合出现在DMA文件的报错，猜测可能是由于DMA传输的时候，缓存区和缓存区大小不匹配，导致传入数据的时候，索引超出发生数组越界错误。
3 q9 H% Q! M. X, y* l( m$ }

0 T. |# v# o5 C6 ^% p/ m6 I

1. HAL_UART_Transmit (&huart1,(uint8_t*)message1,strlen(message1),100);
   
2. end();
   4 `1 X2 _& Q( P, i+ @
3.   HAL_TIM_PWM_Start(&htim1,TIM_CHANNEL_1);
   
4.   HAL_ADCEx_Calibration_Start(&hadc1);  //ad校准  
   
5.   HAL_ADC_Start_DMA(&hadc1,(uint32_t *)ADC_Value,1024);

复制代码

之后去查看DMA的缓存区，发现其数组大小是100（其实这时候我就知道了）因为我之前使用ADC信号的缓存区大小通常是1024的，再不济也是2的倍数，因为这样子好方便计算机处理。
/ ~1 v4 c. `$ {
  m) t* n/ ^2 B1 ?1 E
8 W& Y9 x' r. Z" K! G
9 i: U6 S$ Y& i所以这里的主要原因还是在于DMA传输的时候数组越界问题。
3 Y2 q& W% p" M2 t( G
" E$ d+ u% o2 B0 Y8 v+ i8 Z而ADC的触发采样则正好是定时器触发，定时器触发越界之后刚好卡在了那段话。

! U# O( E, G1 l4 Z4 }( i这类也提醒大家，一定要注意编程习惯，如果在编程中我们习惯性的使用宏定义的方式来编程，就能即方便而又能有效的规避掉这类的错误。
& D1 l& ^% H' D  O% r/ O! Q: k$ }
/ L; w$ F; r1 C2 l6 y同样的关于STM32的中断源除了我们常见的硬件中断例如定时器，外部中断等等。
( U1 E9 h1 s  S! _
还不能忽略了其软件中断，包括一些硬件错误，未知命令错误以及我们程序员自己出现的错误，因此关注我们的中断错误类型可以有效地避免我们的程序出现很多异常的错误。也可以帮助我们更快地修改我们的异常代码。
* c7 y9 g6 O+ z3 Y- o" W
6 q4 X6 x, t/ ]$ p0 F( K2 c
转载自：电路小白
: n9 C( P. J) T, B如有侵权请联系删除
4 d' S, @5 y2 D2 ~9 D- o% d

+ \+ J1 w# K* L& g  Z