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应该也能够用同样的方法解决了。

你可能感兴趣的:(STM32,问题记录,经验分享)