bootloader·開發總結

1、關于到底要不要加看門狗。現在看來是要加的。跑飛，不意味着一定會停在某個地方不同，可能是到處亂竄，是以就可能跑到擦寫flash的地方，是以通過狗複位初始化，讓程式重新運作，這樣就至少不會讓片子弄壞，除非複位後又跑飛。無論如何，看門狗就是最穩妥的做法。

2、擦寫flash驅動放在RAM，通過通信傳輸，這樣進一步降低了非人為原因擦寫flash的可能性。

     ST官方的一篇文章非常好《幹擾環境下 Flash 資料丢失.pdf》

寫到：

----------------------------

什麼是可控性？如何做到嚴格的邏輯驗證？在這個問題上不妨借鑒一下成功的案例：美國飛彈核潛艇上對飛彈發射按鈕的管理。核武器的威力是強大的，發射按鈕的管理權掌握在單個人的手裡是可怕的。為了避免如此危險的武器被濫用，在飛彈核潛艇上，飛彈的發射按鈕是由三個人共同管理的。艇長、副艇長各有一把鑰匙，武控官掌握着密碼。發射飛彈時，必須由武控官輸入密碼，然後艇長、副艇長同時用各自的鑰匙操縱各自的按鈕，飛彈才得以發射。考慮特殊的情況，如果某個人通過特别的手段同時掌握了兩把鑰匙和密碼，能否發射飛彈？答案是不能。因為艇長、副艇長和武控官各自的作業位置相距很遠，而且有時間限制，一個人是無法完成這三項作業的。如果艇長、副艇長和武控官合謀叛亂又如何呢？還是發射不了飛彈。因為發射飛彈的另一半密碼和飛彈的瞄準參數根本不在潛艇上，隻有在下達核攻擊指令時才通過密文發給潛艇。甚至，在飛彈發射之後，艇上人員也無從知到它将飛往何處，也控制不了。這樣，強大的武器最終掌握在中央指揮機關的手裡。回到 

STM32 的問題，如表（一）、表（二）所示的函數，談不上邏輯驗證，一旦被調用會好不猶豫的執行下去，而不在乎調用是合法的還是非法的。為了避免 Flash 被誤擦、誤寫，STM32 在硬體設計上是有所考慮的，就是在擦除或寫入之前，必須驗證密碼，如果密碼不對 Flash 控制器拒絕相應的操作。然而，表（一）、表（二）所示的函數中，密碼的驗證形同虛設，沒有起到應有的作用。因為，在這兩段程式中，密碼的驗證是無條件通過的。猶如鎖上門後，卻把鑰匙留在鎖眼裡，是不能防盜的。

------------------------------------------------------------------------

3、開發過程中我犯了兩個錯誤，并且這個錯誤的後果多次顯現。

第一個問題是我對上位機MOSX的pcomm元件不太熟悉，尤其是對timeout不熟悉。浪費我好多時間。緻使後來被搞得疲憊，一些功能也沒心思加上了。比如通過上位機将一些資訊傳送至單片機中，像電腦下載下傳時間、電腦MAC位址等。

第二個問題是開發前期我就應該對CAN過濾展開充分的測試。我對這個過濾當時太自信了。自以為能搞定。結果等開發快結束了才展開充分測試，就說過現在有些東西都沒有過濾掉。願意不明。但是我弄一個簡單的例子就行過濾都沒有問題。難道是在unlocked flash模式下CAN過濾就不好用了，不得而知。反正現在的過濾能把标準frame都過濾掉就可以了。

還有一個問題是開發進度太慢，導緻上位機界面弄的很粗糙，拖到後期人搞得疲憊，是以一些很人性化的小功能都懶得添加了。