被1T的单片机困住了 [复制链接]

一个C语言写的小程序，12MHz外部时钟，外部中断低电平触发，在STC89C52下写成的，任何情况下运行都正常。
后来芯片升级，改用STC12C5A32，出现问题如下：
当中断服务程序运行时间长的时候，连续外部中断触发，系统正常；
当中断服务程序运行时间短的时候，连续外部中断触发，系统就不返回主程序，一直呆在中断里，中断服务程序仍然可以执行。
采取过的解决办法有：
在中断服务程序里加空指令、强制清除中断标志、进入中断服务程序立即关闭外部中断、强制将外部中断端口置1、将中断服务简化成一条指令、软件设置中断优先级、将时钟频率分频以降低工作频率等方法，均无效，问题依旧。
请教各位老师，有啥好的解决办法吗？谢谢。

看中断执行什么内容，采用强制跳转咋样

内容来自Android手机客户端

中断内嵌套了定时器0和定时器1。

在服务程序末端加过 return 指令，问题依旧。

由于是C语言写的，类似汇编那样的直接跳转到主程序的办法做不到——不会汇编

那应该是有东西死循环无法退出，仔细分析下跑飞的时候程序在运行什么，再查找原因

内容来自Android手机客户端

基本都是时序的问题。
比如里面有自己写的delay吗？

回楼上各位：

里面有自己写的DELAY，用的是定时器1。

循环指令也是与定时器有关，定时器中断一次，计数加1，加到指定值后退出循环。

外部中断低电平有效，触发定时器，外部中断的服务程序第一条指令就是关闭外部中断，然后清中断标志，外部中断口置1，再后才是各种功能指令。

当定时器阈值大于等于50ms的时候一切正常，定时器阈值小于50ms的时候，就会出现外部中断服务程序不退出的情况，此时定时器中断服务程序已经退出。

正在恶补STC12C5A的特殊寄存器设置。

打了个技术服务电话，根本不仔细听，结论就是你的程序有问题，这不是废话么，没问题我打电话干啥。

同一芯片两种运行速度下两种结果就解释不了。

跟没打这个电话一样。

看不到程序我们都是猜测，
看到程序没有亲手调试还是靠猜测。以前学这东西，基本就是靠几个led灯来判断状态，某个状态点亮那个led，然后判断问题所在。
没有仿真器比较麻烦。
基本还是得靠你自己调试。

程序逻辑上应该是没问题的，因为在89C52上运行正常，在12C5A60上低速运行也正常，只不过速度高了就出现问题。

根据问题的表现，自己分析，由于外部中断是低电有效，而且是连续触发的，外部中断服务程序嵌套有定时器的中断，虽然中断优先级做了设置，但1T的芯片速度有点快，而且外部中断申请不锁存，在连续触发的情况下芯片的系统管理程序自己出现矛盾，导致不退出中断。

虽然外部中断服务程序的起始部分是关闭外部中断、清除中断标志，并且加上了一些空指令，但没有解决问题。

以这个分析为出发点，尝试提高中断服务程序的响应速度，将定时器设定为1T模式，情况大为好转，仅偶尔出现卡阻，而且是可以处理的卡阻。

但两个定时器T0、T1同时设定为1T模式就又乱了，计算了好几个初值都不行，两个定时器相互影响。

厂家的手册上没有讲这方面的事情，网上也没有搜到相关的内容。

1、由于采用的是低电平中断，所以中断可能会连续发生，并反复进入中断服务程序执行。
2、由于使用了至少3个中断，所以中断可能会发生相互多重嵌套。

这样我猜可能会出现以下问题：
1、频繁发生的中断，使得主程序循环基本无法执行或执行次数过少，即主程序循环刷新过慢，中断中使用的全局变量在主程序中来不及进行相关处理，这样会使人直观上的感觉主程序没有执行或呈现出卡死状态。
2、频繁发生的中断多重嵌套，使得堆栈溢出RAM耗尽，正常变量被意外改写，系统当然会完全跑飞。

所以楼主的问题可能还是逻辑问题，重新理顺一下执行的逻辑吧。

使用12T的芯片就没有问题，1T的芯片在T0定时大于50m的时候也没有问题，小于50ms就开始出现问题。

优先级设定为T0-T1-INT0-INT1。

尝试过把外部中断服务程序的指令就留下一条赋值指令、不 触发定时器，在连续触发外中断时间长了也不行。所以，觉得中断嵌套、中断优先级都不是问题的根源。

由于工作方式必须使用低电平触发，而且连续触发的状态肯定会存在，否则系统就无法实现预定的功能。

外部中断服务程序的第一条指令就是禁止外部中断，第二条是清除中断标志，第三条是中断端口置高电平，服务程序执行完毕后打开外部中断，再执行数个空指令后结束。

楼上说的第2条可能性最大。

翻遍手册没有找的可以限制连续出发外部中断的寄存器设置。

有没有这种可能：用C写的程序，编译的有关设置不对？

试验了多种极端情况，感觉是芯片的低电平触发和中断嵌套处理上有问题。

在主程序中先把外部中断关闭，直接触发定时器运行没问题，但恢复外部中断需要2-3秒的时间，又不像1T的芯片。

怪哉！

毛病应该还是在芯片的中断系统上和中断嵌套上，虽然中断优先级按照要求进行了设置，但速度提高后出现问题。

现在减少了中断的使用，测试了一遍，还没出现问题。

应该是你程序问题，以前我写的中断时间比你这还短，频率还快都没有问题的。毕竟这个芯片都是老芯片了，不可能现在出现中断BUG。

errjoin:应该是你程序问题，以前我写的中断时间比你这还短，频率还快都没有问题的。毕竟这个芯片都是老芯片了，不可能现在出现中断BUG。 (2017-09-16 23:50) 

又反复检查了程序，语法错误没有，功能错误没有，逻辑错误还没发现。

感觉像是原来的逻辑关系不适应现在的1T芯片。

主循环里有延时程序，延时使用定时器，定时器中断是最高优先级别。
主循环里还有外部中断，外部中断的优先级别低于定时器中端；在外部中断服务程序里使用了定时器，进入中断服务程序后，外部中断被关闭。
按照优先级的设定，定时器中断有效时候，外部中断应该是不动作的，即使外部中断连续触发。

低速运行的时候问题没出现或者不明显，高速的时候就出来了。

现在的程序里，主循环里取消了延时程序，只保留了外部中断，问题再没出现过。

但原因还是没搞清楚。

这种问题就是逻辑错误，逻辑上存在一种你没有考虑到的状态。

虽然你还没有想到这种状态的发生机理，但它却是真实存在的。

BG4UVR:这种问题就是逻辑错误，逻辑上存在一种你没有考虑到的状态。
虽然你还没有想到这种状态的发生机理，但它却是真实存在的。
[表情] [表情]  (2017-09-20 16:07) 

应该是这样的。
在写程序的时候也考虑过是否存在递归调用的问题，但总觉得设定中断优先级和关闭外部中断之后，几个中断之间不会打架。
现在看来是由于外部中断连续的低电平触发引起的，在中断服务程序里也曾强制将外部中断口置1，改变连续触发状态，但没起作用。
现在的15系列芯片取消了外部中断低电平触发，只有下降沿触发和上升沿触发，说明在低电平触发问题上芯片还是有点问题。