程序调试经验 for MCU

程序调试经验 for MCU

1,串口在要发送数据的时候发送乱码0X80、0X00,检查波特率、时钟分频、配置都没错
结果:系统总时钟有误,所以即使串口时钟分频是正确的,串口的波特率也会不正确。
当串口出现问题是,检查步骤:1.波特率,2.数据位、停止位等配置,3.检查有无开启时钟及时钟的分频是否正确,4.检查时钟分频的源时钟是否正确,及一直往上检查直到系统时钟。

2,程序出现莫名其妙的错误或者程序中某些参数在没有运行到的时候被修改!
结果:RAM中自上而下由编译器分配的程序栈与RAM中自下而上的变量区发生重叠,故需要调整函数内部临时buf的大小,buf越大编译器分配的栈空间越大。
检查RAM是否超出范围的方法:程序调试时在memory 工具中将RAM的地址在合理范围内全部写入0XFF,然后允许程序所有功能,检查是不是所有的0XFF全部被改变。
PS:
IAR中给出的RAM使用量是变量加所有函数内的临时buf的大小总和,故此值会偏大。
CS+ for CC和CA,CX给出的RAM使用量是所有RW变量,不包括栈,故会偏小。
因此最好自己检查一遍RAM。
特别要注意函数的嵌套调用,比如当一个函数使用了500字节的栈,它在调用一个使用了500字节的栈时ram就需要1K的空间来处理这2个函数。

3,程序在一个阻塞函数没有出结果之前跳过了该函数直接运行下一个函数!
结果:函数内的临时枚举变量没有给定初始值,此变量有可能在函数一进去被初始化为枚举内一个正确的结果值,而实际上我们期望的是一个等待值。

4,IAR中程序在运行到某个函数时复位!
结果:IAR中定义的栈空间过小,导致程序分配不到栈空间,所以发生复位现象,另附堆栈总结:
转载:堆栈总结

5,IAR中编译器分配的RAM使用量过大,明显不符合已使用的空间大小
结果:分析map可知,IAR在编译阶段为函数内的初始化后的临时数组分配了空间,例如char buf[500]={0};,如果定义成char buf[500];,则不分配RAM空间,因此暂时用memset手动初始化,至于具体原理待后期分析。
分析结果:以上结论是错误的,IAR在编译阶段并没有给临时数组分配空间,只不过IAR认为内存中字节为0的是已使用的RAM,0XFF是未使用的RAM,因此在定义时将数组初始化为0后编译器认为这段空间被使用了,故给出的RAM用量不准确。
6,gcc中禁用某一段的代码优化
#pragma GCC push_options
#pragma GCC optimize(“O0”)
//代码块
#pragma GCC pop_options

猜你喜欢

转载自blog.csdn.net/qq_35333978/article/details/105690751