USB中的SOF(Start Of Frame)包是USB開發(fā)中，經(jīng)常接觸也是很簡單的一個概念：SOF由USB主機每1ms定時發(fā)出(FS)，作用很多，相當(dāng)于是一個時鐘節(jié)拍基準，如果暫時用不到，就忽略也沒有關(guān)系。LPC5528的USB模塊中，有一個FRAME_INT中斷描述如下:

這個中斷 ”感覺好像就是SOF中斷”，似乎只是名字換成了FRAME_INT，在手冊中的描述也和SOF中斷幾乎一樣，但是手冊里就是沒有說它就是SOF中斷。

經(jīng)過小編實測和向同事確認，發(fā)現(xiàn)這個中斷實際上并不完全等同于SOF中斷，兩者還是有一定區(qū)別的。本文就來探討一下這個問題：

事情是這樣的: 小編最近支持一個客戶，客戶的代碼中涉及低功耗按鍵喚醒，USB Remote wakeup, 也需要用到SOF中斷做為定時器來驅(qū)動上層app事件。

客戶發(fā)現(xiàn)：當(dāng)PC關(guān)機的時候，LPC5528被按鍵喚醒，喚醒后執(zhí)行Remote Wakeup(實際就是MCU將USB總線設(shè)置為K states)，因為這時候主機Host已經(jīng)關(guān)機，USB總線上沒有任何信號，永遠維持的K states上，但是MCU卻莫名其妙的進入了FRAME_INT中斷，而且還是1ms的周期！

測試使用一個GPIO引腳——GPIO_SOF_EVT，每當(dāng)進入FRAME_INT中斷后，Toggle一次；測試波形如下圖：

這有點奇怪了。。。USB總線上沒有任何包發(fā)過來，但是還是會進FRAME_INT中斷！難道FRAME_INT中斷不是SOF中斷？

結(jié)果確實是這樣。。經(jīng)過和同事確認，F(xiàn)RAME_INT中斷確實不是SOF中斷，它只是和SOF中斷有點像而已。當(dāng)VBUS沒有掉電且MCU執(zhí)行Remote wakeup(Resume)的時候, FEAME_INT還是會”如期而至”。。他和SOF包沒有必然聯(lián)系。。。疑惑中

那么如果想用SOF中斷咋辦呢？有一個簡單的辦法：USB->INFO寄存器中的前11位為FRAME_NR，它記錄了正確解碼SOF的幀號，每當(dāng)收到一個真正的SOF幀，F(xiàn)RAME_NR都會自加，所以在FRAME_INT中斷中可以讀入FRAME_NR來輔助判斷，這次FRAME_INT到底是不是真正的SOF包到來:

代碼如下所示：

補充：

小編同時也測試了HS-USB的FRAME_INT中斷，其結(jié)論和FS是一樣的，只不過HS的FRAME_INT中斷是微幀，125us一次。

FRAME_INT中斷在SDK中默認是關(guān)閉的，需要在INTEN寄存器中打開對應(yīng)的標(biāo)志位才可以使用。

到此為止，有必要進一步地思考一下，為什么這個USB的內(nèi)部模塊中，沒有專門的SOF中斷，卻出現(xiàn)了這個與SOF有關(guān)，又不來源于SOF的FRAME_INT中斷。

盡管沒有與芯片設(shè)計人員溝通，但可以合理地推論，這個FRAME_INT中斷是為SOF相關(guān)應(yīng)用而設(shè)計的，之所以沒有直接使用SOF作為觸發(fā)源，是因為在USB主機休眠時，不再有SOF信號，而對于在主機休眠時仍需要周期中斷源的USB應(yīng)用而言，則需要使用其它定時器資源來實現(xiàn)相應(yīng)功能，這樣就會占用其它片上資源，又會增加軟件調(diào)度的負擔(dān)。

而在片內(nèi)USB模塊中，設(shè)計這樣的機制，即可以在沒有外部SOF信號時，繼續(xù)維持周期性的中斷，也可以在SOF信號恢復(fù)后，保持這個周期中斷與SOF同步，即實現(xiàn)了SOF中斷的功能，又兼顧了軟件的實現(xiàn)與層次劃分。

最后，這樣的設(shè)計并不增加硬件的成本。

來源：恩智浦MCU加油站

審核編輯：湯梓紅