【求助】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]