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）第⼀次调⽤该函数没任何问题
浮点型变量float2）第⼀次调⽤该函数时，函数内所有的变量赋值都没问题
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应该也能够⽤同样的⽅法解决了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。