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

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

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

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

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

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

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

結果確實是這樣。。經過和同事確認，FRAME_INT中斷確實不是SOF中斷，它只是和SOF中斷有點像而已。當VBUS沒有掉電且MCU執行Remote wakeup(Resume)的時候, FEAME_INT還是會”如期而至”。。他和SOF包沒有必然聯系。。。疑惑中

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

代碼如下所示：

補充：

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

FRAME_INT中斷在SDK中默認是關閉的，需要在INTEN寄存器中打開對應的標志位才可以使用。

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

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

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

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

來源：恩智浦MCU加油站

審核編輯：湯梓紅