1、仓库溢出导致频频重启:
事例1:
concern_tower_num为从铁电内读取的数据,因为铁电没有初始化,所以concern_tower_num的值很大
下面的程序一向循环到铁电内concern_tower_num所在位置的值,所以超过了option内所设置的stack的最大容量导致仓库溢出,重启。
界说了一个29字节长度的数组: char back_info[29]={0};
成果给其填充50个字节的内容 memcpy( back_info+19,send_back_data,data_len); ,现象是仓库没有溢出,机器重启。
问
MSP430F147程序总是不可思议的重新启动?
现已查看了仓库没有溢出,WDT仍然仍是HOLD状况
哪位高手点拨一下,还有哪种或许性?
现已查看了仓库没有溢出,WDT仍然仍是HOLD状况
哪位高手点拨一下,还有哪种或许性?
答 1:
先看IFG1.0位状况,看是什么原因导致复位
答 2:
您丈量一下复位脚上的波形,看是否是硬件复位。
答 3:
你的工作环境??是不是搅扰问题?
是不是指针弄飞了??
是不是指针弄飞了??
答 4:
外部有看门狗吗?有的话要先关掉。
答 5:
谢谢以上各位的答复:
我的具体状况是本来程序是用查询方法,现现已过测验,没有这个问题
而现在需求增加部分功用,为此把查询方法改为了中止方法(新功用还未增加),
我的具体状况是本来程序是用查询方法,现现已过测验,没有这个问题
而现在需求增加部分功用,为此把查询方法改为了中止方法(新功用还未增加),
现在现已查看过IFG1.0位0,不是内部看门狗导致复位
外部无看门狗,也无显着搅扰源
硬件复位或许性也不大,不过这个能够再测一下!
有或许是指针弄飞等程序过错,可是这种内部程序过错会导致体系复位吗?
答 6:
过错写FLASH也能复位,程序超出,复位向量过错等也或许导致复位。
答 7:
或许是复位电路问题!
答 8:
经测验,不是外部复位电路的问题!
现在问题应该在中止子程序对主函数造成了不确定的影响上,
可是现在仍无法定位问题在哪?
抑郁ing!!!
现在问题应该在中止子程序对主函数造成了不确定的影响上,
可是现在仍无法定位问题在哪?
抑郁ing!!!
答 9:
是无法进入中止吗仍是其他的原因,能具体说的具体些吗。
答 10:
呵呵,我的问题是430呈现不确定的复位,有时运转几分钟就复位,有时能到几十分钟
而在这之前,我的程序是用的查询方法处理外部业务,一向运转正常,没有这个问题
现在改为中止来处理外部业务,就呈现了莫名的复位问题
而在这之前,我的程序是用的查询方法处理外部业务,一向运转正常,没有这个问题
现在改为中止来处理外部业务,就呈现了莫名的复位问题
中止是能正常进入的!!
经过几天的排查,现在问题应该在中止子程序对主函数造成了不确定的影响,
然后导致了体系复位。但无法定位问题所在!
答 11:
查看一下数据指针吧,是否超出内存规模,看现象或许是这方面的影响
答 12:
程序发出来看看,否则干说也是查不出来
答 13:
一个中止一个中止使能,一个一个排查。多试几回就是了。把问题分块一个一个来。看哪个出的问题
这个跟单片机支撑的断点个数也是有关的。假如只支撑一个断点,你设置了2个,然后复位的话就简单跑到Cstart而不是Main。别的要注意IAR run to Main的复选框你勾上没?
事例二:跑飞
void send_basic_data_to_dis_part()
{
}
//basic_data_buf[60] 数组所拓荒的长度为60,可是在下面从basic_data_buf首地址起填装数据的进程傍边,填写的数据长度超过了60,数组越界,破坏了栈内坚持的进入send_basic_data_to_dis_part()函数之前保存的现场数据,成果跳出该函数调用,要履行下步的时分,因为SP内的值现已被修正,导致程序跑飞。(这种状况症状往往表现为:进入某个函数内正常,在跳出的时分就跑飞,多为在函数内SP的指针被修正)
声明:本文内容来自网络转载或用户投稿,文章版权归原作者和原出处所有。文中观点,不代表本站立场。若有侵权请联系本站删除(kf@86ic.com)https://www.86ic.net/fangan/dianlu/260506.html