官方例程N(yùn)ET_MAC.C中，定時(shí)執(zhí)行ARP發(fā)送，當(dāng)發(fā)送完成觸發(fā)中斷后，查看中斷狀態(tài)字ISR的低八位，printf出來總是顯示0x18，也就是說發(fā)送完成后ISR的bit3和bit4均為1。

官方手冊(cè)定義：bit4=1時(shí)，表示發(fā)送完成。bit3=1時(shí)，表示發(fā)送緩沖區(qū)無效。

為何這里始終出現(xiàn)這個(gè)異常？發(fā)送緩沖區(qū)無效？如何消除掉發(fā)送緩沖區(qū)無效異常？

主要是我自己的寫的程序里，總是有這個(gè)異常，不管怎樣都消不掉，后來用官方例程試試，結(jié)果發(fā)現(xiàn)也是一樣。。。

我懷疑，這個(gè)bit3的定義是不是搞錯(cuò)了？比如bit3的實(shí)際定義，其實(shí)是數(shù)據(jù)已寫入TXFIFO的標(biāo)記位？

做了一波新的測(cè)試：

1、將R32_ETHE_IMR設(shè)置為0x02FF，即啟用所有的以太網(wǎng)中斷事件。

2、在數(shù)據(jù)發(fā)送函數(shù)中，臨發(fā)送前將發(fā)送緩沖區(qū)的地址（TX描述符的DES2）清0。

3、手動(dòng)發(fā)送數(shù)據(jù)。

保存、編譯、下載后，運(yùn)行結(jié)果很詭異。

第一次手動(dòng)（按鈕）執(zhí)行發(fā)送后，片子竟然沒有進(jìn)入中斷。。。

然后第二次手動(dòng)（按鈕）執(zhí)行發(fā)送，程序走死了。

分析：

因?yàn)槲业臄?shù)據(jù)發(fā)送函數(shù)中，一進(jìn)入函數(shù)首先查詢是否有現(xiàn)存發(fā)送任務(wù)：

while(mac_cotrl.txdes_cur->txdes0 & 0x80000000);? //如有現(xiàn)存發(fā)送任務(wù)，就死等

所以，在第一次執(zhí)行發(fā)送時(shí)，因?yàn)檎也坏桨l(fā)送緩沖區(qū)，所以發(fā)送動(dòng)作一直沒有完成，描述符的OWN位始終為1，同時(shí)因?yàn)闆]有進(jìn)入中斷，描述符也沒有切換到另一個(gè)，所以在第二次發(fā)送時(shí)，程序就卡在這里過不去了。

令人驚奇的是，為什么發(fā)送緩沖區(qū)無效時(shí)，沒有觸發(fā)中斷？？數(shù)據(jù)手冊(cè)說R32_ETHE_ISR的bit3標(biāo)記發(fā)送緩沖區(qū)無效事件?？蓪?shí)際運(yùn)作中，這個(gè)bit3卻失效了。反而在正常發(fā)送成功時(shí)，bit3又總會(huì)被置1？？

不知道官方大神們有沒有遇到這種狀況？？期待交流！

進(jìn)一步測(cè)試，R32_ETHE_ISR寄存器中，關(guān)于發(fā)送的4個(gè)標(biāo)記位，測(cè)試結(jié)果如下：

RB_XPKT_OK（bit5）：

? ? ?? 手冊(cè)描述該位標(biāo)記因沖突過多導(dǎo)致的數(shù)據(jù)發(fā)送失敗事件。

?????? 測(cè)試中在沒有插網(wǎng)線的情況下，執(zhí)行發(fā)送動(dòng)作，無法激活這個(gè)標(biāo)記。至于線路沖突，因無法模擬，所以無法驗(yàn)證。

RB_XPKT_OK（bit4）：

??????? 手冊(cè)描述該位標(biāo)記數(shù)據(jù)發(fā)送成功事件。

??????? 測(cè)試中證明該位有效，不論是不是插網(wǎng)線，這個(gè)位都會(huì)作出響應(yīng)。

RB_NOTXBUF（bit3）：

??????? 手冊(cè)描述該位負(fù)責(zé)標(biāo)記發(fā)送緩沖區(qū)無效事件。1=發(fā)送緩沖區(qū)無效；0=正常。

??????? 測(cè)試過程中，當(dāng)發(fā)送緩沖區(qū)無效時(shí)，該bit無響應(yīng)，也無法觸發(fā)中斷。當(dāng)發(fā)送緩沖區(qū)有效時(shí)，該bit會(huì)誤動(dòng)作置1。詳細(xì)描述見樓上。。。

RB_XPKT_FINISH（bit2）：

??????? 手冊(cè)描述該位負(fù)責(zé)標(biāo)記發(fā)送數(shù)據(jù)寫入TXFIFO事件。1=發(fā)送數(shù)據(jù)已寫入TXFIFO。0=無

??????? 測(cè)試發(fā)現(xiàn)，啟用該事件中斷后，執(zhí)行數(shù)據(jù)發(fā)送動(dòng)作，無法觸發(fā)該中斷。該標(biāo)記位對(duì)相關(guān)事件無響應(yīng)，就沒見它動(dòng)過，永遠(yuǎn)都是0。

綜上，在ISR寄存器中，只有數(shù)據(jù)發(fā)送成功（bit4）事件可以非?？煽康捻憫?yīng)事件觸發(fā)中斷。bit5可能有用，值得保留。bit3和bit2屬于神經(jīng)刀，目前我還沒有找到辦法用起來。。。

算不上大神，我也斗膽回復(fù)下。

ummm,你居然這么仔細(xì)，把所有的狀態(tài)位都打印出來了……很佩服你這樣的鉆研精神。其實(shí)我昨晚在你發(fā)帖后十五分鐘就看到了，然后我復(fù)現(xiàn)出來后也挺迷惑的。今天你又發(fā)帖了，我會(huì)先回復(fù)下，權(quán)當(dāng)拋磚。這個(gè)RB_NOTXBUF置位是什么意思我也不清楚。我猜測(cè)這個(gè)RB_NOTXBUF置位可能是以下幾種情況之一引起的：

1，發(fā)送緩沖區(qū)不是正確的SRAM地址。也就是你在三樓提出來的。這個(gè)情況幾率較小，按你的操作把DES2清零，CH563零地址是flash啊，umm，這不是讓DMA去讀flash的數(shù)據(jù)了么。這個(gè)操作的后果確實(shí)可能會(huì)直接死機(jī)額。

2，發(fā)送緩沖區(qū)被DMA使用結(jié)束了。這個(gè)位可能置位并不是表示異常的、不好的現(xiàn)象，也可能是表示當(dāng)前發(fā)送成功了，剛使用的發(fā)送緩沖和發(fā)送FIFO 也都空出了。用戶可以對(duì)空出來的發(fā)送緩沖區(qū)進(jìn)行操作了。

3，這個(gè)發(fā)送緩沖區(qū)掛靠的發(fā)送描述符當(dāng)前由CPU（軟件）占用，DMA無權(quán)使用，或者僅僅是這個(gè)發(fā)送緩沖區(qū)正在被CPU訪問，DMA的操作被拒絕了。

以上三個(gè)猜想我都覺得不是很靠譜，畢竟發(fā)送緩沖區(qū)實(shí)際上是個(gè)SRAM，誰都能讀寫，被同時(shí)要求訪問的概率太小。

?????? ?我個(gè)人覺得學(xué)習(xí)以太網(wǎng)收發(fā)器的重點(diǎn)在于理解以太網(wǎng)上的數(shù)據(jù)和描述符在FIFO,收發(fā)緩沖區(qū)和自己設(shè)的緩沖區(qū)之間的流轉(zhuǎn)過程，以及搞清楚CPU和DMA在這些過程中需要做的事情。以太網(wǎng)中斷有許多中斷源，也不是所有中斷源都要使能的，畢竟讓不重要的中斷打斷程序運(yùn)轉(zhuǎn)挺浪費(fèi)時(shí)間的，CH563是百兆的，如果加上協(xié)議棧再把速度跑滿時(shí)，所有以太網(wǎng)中斷都要響應(yīng)會(huì)讓處理速度大打折扣，是可惜的。CH563有個(gè)特點(diǎn)，即使不使能某個(gè)中斷源讓其產(chǎn)生中斷，你去讀中斷標(biāo)志位還是能讀到這個(gè)中斷的，這點(diǎn)需要注意。

? ? ? 還有就是我會(huì)繼續(xù)去搞清楚RB_NOTXBUF位的具體含義，也歡迎你接著探討。CH563的MAC收發(fā)源碼我覺得管理描述符不是很高效，有寫得更簡潔的空間。以后我再寫一個(gè)MAC收發(fā)的示例，請(qǐng)沁恒的前輩和你指點(diǎn)，我也是學(xué)物聯(lián)網(wǎng)的，大家共勉吧。

感謝5樓的兄弟，有人一起討論真的好開心！

關(guān)于你的三個(gè)猜測(cè)：

關(guān)于猜測(cè)1：

????? 我在把發(fā)送緩沖區(qū)地址清0之后，并沒有死機(jī)，因?yàn)槲以谥鞒绦驅(qū)懥艘粋€(gè)閃爍燈，每0.5秒翻轉(zhuǎn)LED狀態(tài)，所以可以很負(fù)責(zé)任的說，發(fā)送無效緩沖區(qū)并沒有造成死機(jī)，閃爍燈一直在閃，而且還可以執(zhí)行第二次發(fā)送。只是第二次發(fā)送會(huì)因?yàn)槲胰龢钦f的原因卡死。

關(guān)于猜測(cè)2：

???? 首先要說你的描述有問題。數(shù)據(jù)發(fā)送激活TXDMA后，將數(shù)據(jù)從緩沖區(qū)讀取到TXFIFO的動(dòng)作，并不會(huì)刪掉緩沖區(qū)里的數(shù)據(jù)。緩沖區(qū)不是FIFO，它是內(nèi)存。所以取完數(shù)據(jù)之后，緩沖區(qū)不會(huì)被清空。

???? 然后，按你的描述，這個(gè)bit3的功能將和發(fā)送完成標(biāo)記位的功能重疊。不過從事實(shí)來看，確實(shí)有這個(gè)可能。但從設(shè)計(jì)的角度，這就是個(gè)bug了。沒理由同一種狀態(tài)要關(guān)聯(lián)2個(gè)標(biāo)記位啊。

關(guān)于猜測(cè)3：

???? 個(gè)人認(rèn)為不可能。因?yàn)檫@個(gè)標(biāo)記位即使為1，也不影響下一次發(fā)送，所以不存在你說的DMA或者緩沖區(qū)被占用之類的問題。

關(guān)于CH563的MAC收發(fā)源碼效率問題，唉。。。不說了，說了都是淚

目前我的程序禁用了所有MAC發(fā)送相關(guān)的中斷，就在主程序中完成發(fā)送和發(fā)完之后的相關(guān)重置。

同時(shí)在主程序中監(jiān)控ISR中的2個(gè)標(biāo)記位：發(fā)送完成標(biāo)記位（bit4）和發(fā)送失敗標(biāo)記位（bit5）。

當(dāng)這兩個(gè)bit任意一個(gè)位被置1，就算是發(fā)完了。剩下2個(gè)神經(jīng)刀bit，因?yàn)楦悴欢?，所以不敢用。。?img src="http://www.findthetime.net/assets/js/UEditor/dialogs/emotion/images/jx2/j_0010.gif" alt="j_0010.gif">

今天咨詢了負(fù)責(zé)單片機(jī)方面的工程師，他說RB_NOTXBUF被置位是由于在發(fā)送完成讀狀態(tài)描述符的時(shí)候，DMA還沒有放開對(duì)發(fā)送緩沖區(qū)的控制。所以還是別糾結(jié)這方面了……那么請(qǐng)問你是在寫什么功能的代碼呢？就是自己寫一個(gè)以太網(wǎng)底層的驅(qū)動(dòng)嗎？

既然已經(jīng)被強(qiáng)奸，所以也就只能把眼睛閉上了。。。

這款芯片的最大特點(diǎn)就是集成以太網(wǎng)，所以把這塊搞明白很重要。你的這個(gè)解釋很牽強(qiáng)，首先是DMA把緩沖區(qū)里的數(shù)據(jù)寫入TXFIFO，然后PHY把TXFIFO中的數(shù)據(jù)發(fā)出去。按道理數(shù)據(jù)都發(fā)完了，DMA沒理由還在取數(shù)據(jù)。還是希望能有個(gè)更合理的解釋。

至于未來的方向，可能還是會(huì)以工控居多吧，應(yīng)該不會(huì)往娛樂方向發(fā)展。

改了一下代碼，驗(yàn)證一下8樓說的可能，發(fā)現(xiàn)不是那個(gè)狀況。

在發(fā)送完成后，我增加了一行代碼：while（own），確保DMA已經(jīng)釋放了緩沖區(qū)權(quán)限，然后再打印，仍然是0x18。。。

算了，不糾結(jié)了。正在琢磨接收，等把接收搞透了，就可以讓CH563帶我裝逼帶我飛了。。。