是的，這個問題糾纏了我乙個多月，我都要崩潰了放棄了。今天還是在網際網路上找到了答案，太感謝發帖的人了。抑鬱的情懷終於得到釋放，啦啦啦~~
平台：stm32f207+ucos ii v2.85+lwip
問題：網口接收到資料來中斷時，通過ossempost告知任務進行處理。只要接網口，有網口資料接收，不管是否傳送，執行一段時間後任務排程就會出問題。stm32f207自帶網口有這個問題，擴充套件的dm9000也有這個問題，而且dm9000更容易出現。修改**除錯定位，有的時候十分鐘出現，有的時候跑兩個小時出現，有的時候跑乙個晚上出現，或乙個週末出現。出問題之後，只有乙個任務在跑，再也排程不起來了。
跟蹤發現ospriocur和ostcbcur->ostcbprio不相等。但是這兩個值都是在pendsv_handler中賦值，賦值前後有中斷保護。理論上兩者不應該不等呀。一直定位定位，遮蔽這個遮蔽那個，以為好了，久了問題又來。最終沒有辦法，自己打了個補丁。在os_sched()和osintexit()裡加上語句：if (ospriocur != ostcbcur->ostcbprio) ospriocur = ostcbcur->ostcbprio;
原來是ucos ii本身的bug，v2.88以後的版本改正了這個任務排程的bug。
ostcbhighrdy = ostcbpriotbl[ospriohighrdy]; 把這句提到判斷語句之外。
if (ospriohighrdy != ospriocur)
最終表現是ospriocur和ostcbcur->ostcbprio不一樣。
分析是因為ospriohighrdy和ostcbhighrdy不一樣引起的，而且應該ospriocur > ostcbcur->ostcbprio。
純屬個人分析，不知道對不對。
1）假設ospriocur=7，ostcbhighrdy->ostcbprio=7；調完os_schednew();後，ospriohighrdy=8，ostcbhighrdy->ostcbprio=8；觸發一次任務排程。
2）因為pendsv中斷優先順序最低，此時有乙個中斷來臨，此次任務排程未來得及執行。
3）中斷中排程，引起ospriohighrdy=7，此時ospriohighrdy==ospriocur，沒有更新ostcbhighrdy，使得ospriohighrdy和ostcbhighrdy不一樣。
STM32F207 USB復合裝置
最近乙個專案需要用f207的usb做乙個復合裝置，目標是將msc和vcp裝置復合，msc裝置使用的是spiflash。根據其他人的經驗，做usb復合裝置的過程，大致上就是將兩個裝置的描述符和 融合在一起。不過做起來可是沒有這麼簡單，我剛開始把兩部分 一下子融合在一起，各種問題和錯誤，什麼描述符問題，...
STM32F207外部中斷實驗
stm32的每個io口都可以作為外部中斷輸入。gpiox.0對映到exti0，gpiox.1對映到exti1，同乙個時間只能有乙個io口對映到中斷線。對於每乙個中斷線，可以設定相應的觸發方式 上公升沿觸發 下降沿觸發 邊沿觸發 和使能。io外部中斷在中斷向量表中只分配了7個中斷向量，也就是只能使用7...
STM32F103 UCOSII 移植實驗
ucosii 移植 一 向工程中新增相應資料夾 1 建立相應資料夾 在工程目錄下新建ucosii資料夾，並在ucosii資料夾中另外新建3個資料夾 config core和port，如下圖所示 2 向core資料夾中新增原始碼檔案 2 新增原始碼檔案 向core資料夾中新增cosii原始碼檔案，開啟...