官方例程NET_MAC.C中,定时执行ARP发送,当发送完成触发中断后,查看中断状态字ISR的低八位,printf出来总是显示0x18,也就是说发送完成后ISR的bit3和bit4均为1。
官方手册定义:bit4=1时,表示发送完成。bit3=1时,表示发送缓冲区无效。
为何这里始终出现这个异常?发送缓冲区无效?如何消除掉发送缓冲区无效异常?
主要是我自己的写的程序里,总是有这个异常,不管怎样都消不掉,后来用官方例程试试,结果发现也是一样。。。
我怀疑,这个bit3的定义是不是搞错了?比如bit3的实际定义,其实是数据已写入TXFIFO的标记位?
做了一波新的测试:
1、将R32_ETHE_IMR设置为0x02FF,即启用所有的以太网中断事件。
2、在数据发送函数中,临发送前将发送缓冲区的地址(TX描述符的DES2)清0。
3、手动发送数据。
保存、编译、下载后,运行结果很诡异。
第一次手动(按钮)执行发送后,片子竟然没有进入中断。。。
然后第二次手动(按钮)执行发送,程序走死了。
分析:
因为我的数据发送函数中,一进入函数首先查询是否有现存发送任务:
while(mac_cotrl.txdes_cur->txdes0 & 0x80000000); //如有现存发送任务,就死等
所以,在第一次执行发送时,因为找不到发送缓冲区,所以发送动作一直没有完成,描述符的OWN位始终为1,同时因为没有进入中断,描述符也没有切换到另一个,所以在第二次发送时,程序就卡在这里过不去了。
令人惊奇的是,为什么发送缓冲区无效时,没有触发中断??数据手册说R32_ETHE_ISR的bit3标记发送缓冲区无效事件。可实际运作中,这个bit3却失效了。反而在正常发送成功时,bit3又总会被置1??
不知道官方大神们有没有遇到这种状况??期待交流!
进一步测试,R32_ETHE_ISR寄存器中,关于发送的4个标记位,测试结果如下:
手册描述该位标记因冲突过多导致的数据发送失败事件。
测试中在没有插网线的情况下,执行发送动作,无法激活这个标记。至于线路冲突,因无法模拟,所以无法验证。
手册描述该位标记数据发送成功事件。
测试中证明该位有效,不论是不是插网线,这个位都会作出响应。
手册描述该位负责标记发送缓冲区无效事件。1=发送缓冲区无效;0=正常。
测试过程中,当发送缓冲区无效时,该bit无响应,也无法触发中断。当发送缓冲区有效时,该bit会误动作置1。详细描述见楼上。
手册描述该位负责标记发送数据写入TXFIFO事件。1=发送数据已写入TXFIFO。0=无
测试发现,启用该事件中断后,执行数据发送动作,无法触发该中断。该标记位对相关事件无响应,就没见它动过,永远都是0。
综上,在ISR寄存器中,只有数据发送成功(bit4)事件可以非常可靠的响应事件触发中断。bit5可能有用,值得保留。bit3和bit2属于神经刀,目前我还没有找到办法用起来。
0