电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: mc13192死机问题 [打印本页]

作者: poullin 时间: 2008-2-14 17:06 标题: mc13192死机问题

我用2块13192EVB版子做的beaconed的网络，BO和SO设的都是3，uart部分设的是watermark等于80，每个mcps里的buffer长度设的也是80。串行口为115200bps。现在问题是，我在enddevice端从串行口大量输入数据，enddevice不间断的往coordinator发数据包，每个包的payload为80byte，通过设断点可知，一个包发送出去后，要等将近相当于串行口进了90byte的时间，才能收到ACK，所以可以得出一次性不间断的往串行口里输入2080byte后，mac里的等待队列达到4。以上是理论值，实际上2080byte里的任何一个包延迟的话，等待队列很快就到4了。
事实上我往enddevice的串行口里一次性进1000byte，10次有8次会引起enddevice死机，当然有2次是无错误的成功的。或者我以固定周期每次往串行口里进128byte，周期放大一些，进了几十个包之后也是会死机。
现在问题是，通过设断点可知，只要一旦有个mcps-confirm的return值是NO_ACK,马上mac就好像死机了一样，接下来的3个mcps-request就都发不出去了，然后等待队列马上冲4，随后整个系统死机。必须重启。
首先，我不理解这个no_ack的mcps-confirm是怎么引起的，是因为正好这个包跟coordinator发过来的beacon冲突了吗？但是不是说beaconed的网络里用的是slotted的csma-ca算法吗，slotted的算法是不会引起mcps和beacon的冲突的应该。
然后如果一个包发送返回的是no_ack的confirm，好像那个包就赖在mac里不走了，mac不会自动丢弃的吗？发送是我选择是direkt的发送，然后后面的包就让前面的包堵住了一样。直到死机。另外，死机的原因我也不太想的明白，程序里明明定义的是当等待队列到4之后，就不会申请新的mcps内存空间了，uart进来的数据就会被丢弃，不应该会导致整个系统死机啊，真是奇怪。
说的有点乱，望见谅，哪位mac 802154的达人能给指点一下迷津啊。谢谢

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)