原文：
调试计划和实际过程记录以及明细
必须保证程序所哟分支全部经过！！！
***************************************************
测试模块：测试射频中断处理程序
测试时间： 2008.12.11
__________________________________
测试方法：
1.从射频串口输入如下序列
X0123456789ABCDEF00（正确序列）
预期结果：
缓冲区中出现数据 0x0123456789ABCDEF，并触发事件
2.从射频串口输入如下序列
X0128456789ABCDEF00（校验错误序列）
预期结果：
缓冲区中不出现数据，不触发事件
3.从射频串口输入如下序列
X012345X0123456789ABCDEF00（中断以及正确序列）
预期结果：
缓冲区中出现数据 0x0123456789ABCDEF，并触发事件一次
4.从射频串口输入如下序列
X0123G56789ABCDEF00（出现怪字符）
预期结果：
缓冲区中不出现数据
实际结果：正常
修改：有
由于实际发送过程需要时间都在几百毫秒，此间如果不对射频队列处理，可能会导致输入溢出，从而丢失数据
为防止数据丢失。做如下处理：
1设定射频队列足够长。
队列满则丢弃新数据。（说明系统不看重负。出速度太慢）
2应用队列固定。GPRS硬件允许的最大包（60个ID）
满则发送，或定时发送。因此不会溢出。
3已发送队列尽量长。（使用所有剩余RAM）
满 删除老数据，加入新数据
修改后：使用数据移动操作。测试表明，移动10K数据约虚1.3ms左右时间。
***************************************************
***************************************************
测试模块：测试射频GPRS中断接收程序
测试时间： 2008.12.13
__________________________________
测试方法：
***********************************************
已发送队列测试过程中，出现以外情况，原因不明
1：计算到零，但没被删除。出现0xffff情况。该数出现在第一个
原因：数据类型错误，导致数据错位
struct RFID <= struct strSendedRFID
/*******************************************
测试MCU复位，gprs模块复位 以及网络侧复位对通信的自恢复功能
××××××××××××××××××××××××××××××××××××
GPRS模块有死机现象：
此时串口没有任何回应。
该现象一般出现在网络数据发送过多，缓存没有时发生
1.MCU复位
能正常和服务器建立连接
2.GPRS复位（没考虑其他原因的GPRS异常）
能正常和服务器建立连接
3.网络服务复位
服务一直关闭测试
CPU不断尝试连接 有错误提示：服务拒绝4或连接超时5
服务挂断再打开：CPU不断尝试，但有时总是超时，并且服务器没收到任何连接请求包。
有时实际连接已断开，但GPRS模块还保持旧连接。发送数据一直成功，只是服务器收不到。
只是从发送缓存越来越少，可以看出发送数据一直不成功。
？网络管理公司 还是 GPRS模块的限制
现象：有时服务器已打开，但连接一直失败，总是超时。
原因：此时是网络侧出现问题。
解决方法：退出GPRS网络，重新加载 TCPIP可以解决问题
现象：对一个服务器（ip,端口号相同），重复建立连接时，网络侧会自动断开以前的连接。
gprs网络中的TCP连接是分段连接的：GPRS网络内部TCP连接 和 互联网的TCP连接
有时候：GPRS网络没断开，而互联网的已经断开。造成虚假连接的假象。
现象：有时服务器侧连接成功，但GPRS侧没有反应，导致没有生成连接，而频繁尝试连接都会失败。
解决方法：退出GPRS网络，再重新连接。
问题整理和处理
1，2类即MCU复位和GPRS复位：系统工作正常
3.网络服务复位（UDP一般没有问题。下面针对TCP的）
现象：一旦网络服务复位，若出现连接断开，则没有问题。但有另外两种情况：
(1)GPRS网络侧虚连,实际连接断开：更多时和GPRS网络连接没有断开,发送数据表面成功，但实际上数据全部发送失败，导致
GPRS模块最后内存耗尽。
原因：GPRS网络连接保持，而互联网内连接已断开（服务器意外中断）。这样所有数据不会有回应。
解决方法：根据缓存的使用情况。先断开连接，再建立连接。
检查GPRS模块TCP发送缓存的变化，若该值持续减少，则说明连接已断开。
如何把握缓存实际的变化情况。若在一定时间里一包也没发送，则认为连接中断。
解决方法：根据目前可用缓存的总量，若小于一个极限值，则断开连接，重新连接。（只对TCP采取措施）
方法：先
(2)并多次尝试，屡连屡败。MCU侧一直失败。
导致连接无法建立。失败提示是连接超时。
原因：服务器端有防火墙。因为软件处理延迟了甚至过滤了连接请求或对连接不应答，造成连接失败。
解决方法：无需处理。
处理结果：已解决
时间2008.12.19
/********************************************
数据包发送测试
测试目的：
测试方法：
现象1：TCP连接中发送会少一个ID
发生规律：重新连接，再发送时第二个包的第一个ID丢失。
原因：发送队列满时，而发送不成功。导致新来的第一个ID丢失。因为此时队列不能存放新数据。
解决方法：先检查再加入。
以前采取的是先加入再检查。加入后才知道队列已满但数据已认为被处理。
现象2：已发送队列处理定时器会失效。造成队列死锁，数据全部停止发送。
/********************************************
关于队列处理：以及队列之间关系问题
射频队列采取循环缓存：使中断程序处理方便。加快中断处理速度。
应用队列采取先进先出。
/********************************************
射频队列转发到应用队列过程中，会碰到应用队列满的情况。
？此时停止加入，不处理射频队列。等待发送队列被清除。
这样可能因射频队列满而丢失后来ID。
？还是继续处理射频队列，放弃当前ID的处理。
这样会丢失当前ID。
采取后一种方法。队列满说明发送出现问题。及时放弃当前，后来的也可能不能被处理。
/*******************************************
串口死机：
现象：在和服务器连接成功后，若服务器频繁启动和断开。则会造成串口对命令失去反应。
原因：GPRS模块在处理服务器端断开连接时的一种表现。不能在该连接上发送数据。
当服务器端连接已断开，但是GPRS认为没断。此时发送数据 就会表现为发送缓存区满，但对其他连接没有影响。
现象：当此时发送AT%IPCLOSE=关闭连接时，串口出现吊死现象。对任何输入都没有反应。
解决方法：出现缓冲区满时，退出GPRS网络并重新加载TCPIP
发送“AT%IPCLOSE=5退出GPRS网络并重新加载TCPIP，成功解决该问题
/**************************************************
现象：已发送定时器会启动失败：
原因：可能是GPRS接收定时器启动过多，没有关闭造成。
现象：测试定时器错误时，出现”硬件错误“中断，死机
/*************************************************
防止过度创建定时器，启动前先kill以前
现象：等待事件有时会变 0x0001 ->0x0002？？
?????????????该问题没找到原因???????????????????????????????
可能原因:GPRS中断接收程序中使用定时器.调试时发现会消耗所有用户定时器资源.
解决方法:不使用用户定时器,使用延时函数.
效果:问题解决,并且连带事件等待标志被修改问题一起被解决.
GPRS模块:
现象:有时会被关闭,此时打电话不能接通,但模块指示灯状态D,和正常状态没有差别?
解决方法:模块RESET
有时GPRS初始化应该失败时却执行成功?InitGPRS
/*********************************
考虑数据安全和可靠,对通信协议做了修改.
对GPRS和服务器之间数据采用校验和加密形式传输，防止恶意和意外干扰。
2009。1。17
阅读(1349) | 评论(0) | 转发(0) |
