程序跑飞,就是程序跑得跟设计想法完全不一样,而且单片机此时对于各种外接的设备(按键、显示屏、LED灯等等),还有之前程序中设置的外中断,计时器,串口中断等等本来应有的反应也彻底没有了,单片机进入了一个不可控的死机状态。比方说我现在写的程序,主程序正常的,但是一旦按了0号外中断,LCD1602显示屏上就出现了一串乱码,然后本来应该过一会儿中断程序完成退回主程序,恢复正常显示,结果等了几倍的相应时间也没反应,肯定是彻底死机了,对于这个我的老师就认定为程序跑飞了,不过跑飞其实是我们认定的,单片机不认为自己跑飞了,只要不是外部强电磁干扰引起的跑飞(工控现场的恶劣使用环境引起的),那么人家单片机可是按照我们写给它的程序兢兢业业地执行着呢,只是我们自己写错程序了,要是LZ也是正在学单片机,我们一起探讨下吧?另外,求采纳啊~~~ ^-^ 我也在百度上提了个问题,也是单片机的,一起探讨吧~
问题二:程序跑飞一般是什么原因造成的 我是在DM642上做jpeg2000编解码的,先是调通了板子的VIVO,然后再把代码移植进去,编译通过,就是下载进去后跑不起来我的配置基本上都是在BOIS里面做的,cmd文件里面没写什么东西,能不能帮忙分析下大概是哪些原因导致程序跑步起来啊?谢了!
忽略一切硬件因素,例如是电压不稳或者外部干扰等等问题。因为我这程序用keil软件仿真的时候PC指针都会都飞开,所以应该不关硬件的事。光从软件上看,怎么样的原因会使单片机跑飞呢?程序是用C写的,编译时keil没有报错,也没有warning。ram用了218B,flash用了16kB。
用的芯片是SM5964,ram大小是256+768,flash是64k。按理来说都没超标,求大神解围!
问题三:什么是跑飞? 程序(常见于单片机,DSP中)因编写问题没有按照作者意思运行而进入死循环或者毫无意义地乱运行.
问题四:51单片机程序跑飞什么意思?怎么解决? 程序跑飞就是程序执行错误,程序不知道运行到哪里,这就需要设定标志位,寻找跑飞的地方,再改
问题五:程序跑飞一般是什么原因造成的 原因很多啊
1)程序没有结尾或不是循环的程序。
2)nmi管脚没有上拉。
3)在看门狗动作的时候程序会经常跑飞。
4)程序编制不当也会引起程序跑飞。
5)硬件系统有问题。
问题六:程序跑飞一般是什么原因造成的 原因很多啊
1)程序没有结尾或不是循环的程序。
2)nmi管脚没有上拉。3)在看门狗动作的时候程序会经常跑飞。
4)程序编制不当也会引起程序跑飞。
5)硬件系统有问题。
问题七:c语言程序跑飞的原因有哪些?指针? 跑飞指的是程序指针混乱,堆栈被破坏,跑飞算是程序运行问题中较严重的一类,对指针未初始化或未指向值就解引用常会引起跑飞
如: struct AA
{
int i
char j
} *p
如未p = (AA *)malloc(sizeof(struct AA))等之类进行初始化就 使用p->i,j等就会使得程序跑飞
问题八:程序跑飞是怎么回事? 10分 看看这两个吧,或许对你有用
baike.soso/v4640480
h触tp:/...15547/
问题九:单片机程序跑飞 一种可能是硬件上抗干扰设计有缺陷。
另一种可能是软件处理有问题,需要提供软件才能具体分析问题所在。
STM32F103不至于那么娇贵,你怎么知道是程序跑飞而不是程序错误?不是偶尔出现,每次只要上电几秒就死机。这不像程序跑飞的节奏。
建议你对外控制只点亮LED,其他最外控制都注释掉,如果还是同样情况,肯定程序有问题。
【解决过程】1. 看着这现象,貌似是RAM不稳定或者没有初始化好,而导致J-Flash ARM运行有问题,没有正常烧写。
所以去尝试取消了RAM,即Options ->Project Settings ->CPU中,取消Use target RAM(faster)的话,好像是不会出错的,但是烧写起来,速度就太慢了,是一个一个字节烧写的,烧个200多K的u-boot.bin的话,估计得几十分钟,所以无法忍受。
还是需要用到Use target RAM(faster)来实现快速烧写的,这个只要一二十秒即可。
2.后来又去更改JTAG的工作频率,从很低的100KHZ到很高的4MHz,12MHz等,或者是Auto模式,都试了试,但是还是会出错。
3. 后来又去折腾,更改很多设置,看看是否有用。最后的最后,幸运地,终于找到解决办法了:
Options ->Project Settings ->CPU ->'Use following init sequence:'中,默认只有一行:
0 reset 0 0ms reset and Halt target,
然后选中该行,点击Edit,修改Delay为2ms,确定,即可。
如图
即在通过JTAG去reset重启目标开发板之后,再delay延迟个2毫秒,等待板子各种硬件都稳定了,然后再通过J-Flash ARM去烧写Nor Flash,此时就都一切正常了。
额外说句:
后来输入英文“PC of target system has unexpected value after programming”的时候,发现google上,也有对应的帖子的,只是自己之前没发现而已,惭愧啊。
不过刚去看其解决方法,倒是和我不太一样,其是把'Use following init sequence中的动作从默认的reset改为Halt,即使cpu暂停,使得CPU不会乱跑,然后接下来去烧写nor flash,也就正常了。而我此处的是reset后,等待2ms,目的也是等待系统稳定。目的相同,实现方法不同而已。
刚又看到别人讨论此现象的原因,说是可能是watchdog还在运行,导致系统reset,所以程序跑飞了,所以才出错的。
个人感觉不是很像,如果是watchdog还在运行导致出错,那么我们上面的reset后,多加的2ms的delay后,也还是会出错才对,但是我这里是可以解决问题,不会出错的,所以,感觉是系统reset后,需要一段时间,等稳定下来,继续 *** 作,才正常的。
不过有空是可以尝试去设置关闭watchdog,看看是否能解决问题。
经过尝试,发现添加对应动作去在reset后,关闭watchdog:
0x53000000= 0x0/* make sure bit5=0 to disable watchdog */
如图:
但是再去烧写nor flash,还是会出错,所以,可以确定不是watchdog的问题,而很可能是TQ2440在reset后,系统稳定性的问题,需要有个延迟以等待系统稳定。
【总结】
1.遇到问题,还是需要大胆地多去折腾折腾,最后往往会有效果的。即使没解决问题,也会有新的发现的。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)