STM32F4浮点数赋值导致HardFault的终极解决办法

STM32F4浮点数赋值导致HardFault

1.问题描述

STM32F407+ucosII，调用函数对某float型变量赋值后进入HardFault，程序没有任何语法错误，且该函数第一次赋值同一变量没有问题

void main()
{
	```
	motor1.Init(1,*CAN1,1,1.0,0.5,0);
	motor2.Init(2,*CAN1,1,1.0,0.5,0); //第二次调用进入HardFault
	```
}

void Tmotor::Init(int _id,CANClass *_CANClass,int _CANType,float _Kp,float _Ki,float _Kd)
{
	id = _id;
	set_pos=0.f;
	set_vel=0.f;
	set_tor=0.f;
	CAN = _CANClass;
	CANType = _CANType;
	Kp = _Kp;
	Ki = _Ki;
	Kd = _Kd;
	startMotor();
	return;
}

2.分析过程

1）第一次调用该函数没任何问题
2）第一次调用该函数时，函数内所有的变量赋值都没问题
3）第二次调用该函数时出现HardFault
4）第二次调用该函数时，对float型变量赋值进入HardFault
5）注释函数中的内容只留下一个赋值语句，留Int型变量的赋值语句没问题，留float型变量进HardFault
综合以上信息，结论是又是一个玄学问题，因为曾经出现过对float型变量赋值为0进城HardFault，赋值成0.0就不会进的问题，也出现过对float赋值进HardFault，但是把赋值语句换到另外几个赋值语句下面就好了（各赋值语句没有任何关系）

3.解决办法

以前遇到过的一些玄学HardFault问题都是一些乱七八糟的解决办法，比如上面提到的赋值成0.0啊，换个位置啊之类的，这次尝试用相同的代码重新构建工程，发现问题解决了，然后想到是不是编译器在编译的过程中生成了一些bug文件，导致出现这种HardFault问题，因此尝试把工程的中间文件（.o文件等）全部删除，重新编译，发现问题解决了。

4.总结

至此，算是基本知道了这类玄学HardFault出现的原因了，编译的中间文件出现了问题，所以以后再遇到类似的玄学HardFault应该也能够用同样的方法解决了。