【求助】KE02跑一会儿就进不了串口中断了
用的是MKE02Z32VLD2型号的单片机,外部20Mhz晶振,串口波特率为57600,开了UART1串口接收中断,禁用了发送中断,采用查询的方式发数据。问题是:做了几块板子,发现串口通信不正常,有的跑了十几分钟就没通信了,有的几个小时后才没通信,可以确定没通信后单片机没死机,按按键有反应,能进定时器中断闪个灯什么的,没开看门狗。
发现问题后,在串口中断里不做任何串口数据处理,只是亮个灯,空读数据,然后在main主循环里熄灭在串口中断里亮起的那个灯。单片机跑起来后开始那个灯会闪,不一定的时间后就不闪了,单片机也没死机。
可以确定是进不了串口接收中断了,非常郁闷啊!
串口配置:
void UART_Config( void )
{
UART_ConfigType sUART_Config;
sUART_Config.u32SysClkHz = BUS_CLK_HZ; //总线时钟20MHz
sUART_Config.u32Baudrate = UART1_BAUD_RATE; //波特率57600
UART_Init(UART1,&sUART_Config);
UART_EnableInterrupt(UART1,UART_RxBuffFullInt); //使能串口接收中断
//关闭发送完成中断
UART_DisableInterrupt(UART1,UART_TxBuffEmptyInt);
UART_DisableInterrupt(UART1,UART_TxCompleteInt);
UART_SetCallback(&UART_ReceiveTask);
/* enable UART1 interrupts */
NVIC_EnableIRQ(UART1_IRQn);
}
串口接收中断函数里的内容:
void UART_ReceiveTask( UART_Type *pUART )
{
volatile unsigned char temp = 0;
Light_FaultLED(0); //亮个指示灯
if( UART_IsRxBuffFull(pUART) )
{
temp = UART_ReadDataReg(pUART);
}
}
main主循环里就是按键检测,AD采样,清那个指示灯。还开了KBI和PIT中断,没开看门狗。
{:dizzy:} 各位大神帮忙分析一下可能的原因吧,我已经无计可施了~
查查串口有没有溢出等错误 xzp21st 发表于 2015-3-13 11:09
查查串口有没有溢出等错误
谢谢回帖!
原来有加过测试串口溢出的语句,没有效果~
/* check overrun flag *///防止溢出卡死,空读数据,使之能正常接收数据
if( UART_CheckFlag(pUART,UART_FlagOR) )
{
temp = UART_ReadDataReg(pUART);
} 其他的数据有没有溢出的? lpantonie 发表于 2015-3-13 11:48
谢谢回帖!
原来有加过测试串口溢出的语句,没有效果~
有溢出错误 不清错误位? jinyi7016 发表于 2015-3-13 13:23
其他的数据有没有溢出的?
谢谢回帖!
暂时没找到其他数据有没有溢出的情况,按理说一般有数据溢出也只会造成逻辑混乱,最糟糕的情况也就是死机,好像和串口中断搭不上边啊,但是现在能观测到的基本功能正常,也没死机,就是进不了串口中断,好苦恼哇~
我再看看吧 xzp21st 发表于 2015-3-13 13:45
有溢出错误 不清错误位?
我按手册上的理解,如果串口溢出,只要空读一遍接收寄存器就可以清除了
仿真器打断点看一下寄存器的值 包括中断使能和串口其他错误位等等 都看看 xzp21st 发表于 2015-3-13 14:02
仿真器打断点看一下寄存器的值 包括中断使能和串口其他错误位等等 都看看 ...
正在试,等它停掉好痛苦啊~
而且Keil 5不给力,不稳定,敲代码时经常崩溃,仿真时有时无响应,好坑人啊!
真是遇到了个非常棘手的问题{:cry:} 检查一下串口收不到数据时,外部晶体是否震荡正常。用示波器量一下波形。 postek 发表于 2015-3-13 14:40
检查一下串口收不到数据时,外部晶体是否震荡正常。用示波器量一下波形。 ...
好的,稍后汇报结果!
漫长地等待中...... postek 发表于 2015-3-13 14:40
检查一下串口收不到数据时,外部晶体是否震荡正常。用示波器量一下波形。 ...
串口收不到数据后,晶振正常,20MHz嘎嘎的! lpantonie 发表于 2015-3-13 13:50
谢谢回帖!
暂时没找到其他数据有没有溢出的情况,按理说一般有数据溢出也只会造成逻辑混乱,最糟糕的情 ...
是否存在硬件上的干扰呢? 不要光查串口,看看其它的地方是否影响了中断,最好把其它的全屏蔽掉,只留串口试试 lpantonie 发表于 2015-3-13 14:13
正在试,等它停掉好痛苦啊~
而且Keil 5不给力,不稳定,敲代码时经常崩溃,仿真时有时无响应,好坑人啊! ...
你可以用KDS试下 {:smile:}谢谢各位的回帖,各种尝试中...... lpantonie 发表于 2015-3-13 14:13
正在试,等它停掉好痛苦啊~
而且Keil 5不给力,不稳定,敲代码时经常崩溃,仿真时有时无响应,好坑人啊! ...
keil5这么不济么? 你只留串口中断其他功能都关了,看看串口中断正常么
这样找是串口问题还是其他引起的问题,如果是其他的一次添加就行了
ccrt 发表于 2015-3-14 11:10
你只留串口中断其他功能都关了,看看串口中断正常么
这样找是串口问题还是其他引起的问题,如果是其他的一 ...
Keil 5确实感觉不如Keil 4稳定,关闭文件标签容易卡死,还有那个代码提示功能有时有有时没有
正在逐步关闭单片机的其它模块功能进行比较测试,漫长的等待啊... 哪能确定单片机不进入Receive中断后,程序还可以正常执行其他操作吗? FSL_TICS_ZP 发表于 2015-3-16 14:19
哪能确定单片机不进入Receive中断后,程序还可以正常执行其他操作吗?
目前来看,进不了串口中断后,按按键有反应,PIT定时器中断能正常控制闪灯~ lpantonie 发表于 2015-3-16 16:08
目前来看,进不了串口中断后,按按键有反应,PIT定时器中断能正常控制闪灯~ ...
在这种情况下,又进行过单步调试,查看寄存器的各个位状态吗? FSL_TICS_ZP 发表于 2015-3-17 09:49
在这种情况下,又进行过单步调试,查看寄存器的各个位状态吗?
Keil 5不给力,调到串口罢工的时候,就没响应了,下断点多调试几次有时也会没响应,真是够了!!!{:cry:}
不过经过现在初步测试,有很大的原因是和AD采样计算有关,注释掉后目前还算正常,正在看计算有没有溢出之类的。
还有一点就是让AD管脚悬空,不插采样电路小板时串口挂地快一点,插上采样小板能撑好久,最终还会挂掉~
AD采样计算这块程序已经作了类型转换等严防溢出处理,看起来AD这块的程序还有问题...... lpantonie 发表于 2015-3-17 12:34
Keil 5不给力,调到串口罢工的时候,就没响应了,下断点多调试几次有时也会没响应,真是够了!!!{:cry: ...
你有没有设置嵌套中断优先级?
现在确定是ADC中断影响了串口接收中断吗?
{:sweat:}今天来结贴,问题应该解决了,跑了好多天未出现问题!
结论是和我写的程序计算溢不溢出没有关系,是官方提供的串口接收例程有点问题,串口接收容易溢出,但是中断里加溢出判断好像没有作用,以下是目前使用的解决方案:
1.一开始将PIT0定时中断里的语句提到main主循环里根据标志位处理,中断里只剩置标志位语句,测试没发现问题。以为该问题解决,先这样跑着吧,但是毫无理由PIT0中断能干扰到串口接收中断彻底进不去的地步!
2.后来另外一同事也遇到了相同的问题,发现串口接收溢出比较频繁,多次尝试,在串口中断里再判断一遍接收是否溢出就可以了,或在主循环里判断也行
可以这样写:
void UART_ReceiveTask( UART_Type *pUART )
{
volatile unsigned char temp = 0;
/* check overrun flag *///防止溢出卡死,空读数据,使之能正常接收数据
if( UART_CheckFlag(pUART,UART_FlagOR) )
{
temp = UART_ReadDataReg(pUART);
}
/* check receiver */
else if( UART_IsRxBuffFull(pUART) )
{
//这里写串口接收到数据后的处理程序
temp = UART_ReadDataReg(pUART);
...............
}
else
{
/* default interrupt */
temp = UART_ReadDataReg(pUART);
}
/* check overrun flag *///再判断一遍,防止溢出卡死,空读数据,使之能正常接收数据
if( UART_CheckFlag(pUART,UART_FlagOR) )
{
temp = UART_ReadDataReg(pUART);
}
}
{:smile:} 好了,此贴结贴,各位散了吧!
这个感觉是串口接收中断里又被定时中断了,定时中断时间太长,又接收到数据了,你最后又清一遍,要丢数据 helloshi 发表于 2015-6-5 08:17
这个感觉是串口接收中断里又被定时中断了,定时中断时间太长,又接收到数据了,你最后又清一遍,要丢数据 ...
差不多是这样,或者说串口接收中断里语句太长({:sweat:} 其实也就几行代码),又来数据了没读取,然后就卡住进不去了~
现在定时中断里只剩置标志位一个语句,发送端字节间稍稍延时,保险起见又多判断了一遍是否溢出,数据有校验,数据丢失率可容忍,要求不高
页:
[1]