首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

mc13192死机问题

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的达人能给指点一下迷津啊。谢谢
返回列表