在利用MCC開發(fā)Bootloader和Application時需要注意一些關鍵問題。

Bootloader部分

1）Bootloader最大空間-Bootloader能分配的最大空間由目標Application和Flash的大小決定。在Bootloader區(qū)還應提供額外的備用閃存大小，以允許在項目的整個生命周期內(nèi)增加Bootloader的大小。如果Bootloader的大小需要增加，它將影響所有現(xiàn)有的Application項目。所以在開發(fā)初期，一定要留充足的Flash空間大小，避免后續(xù)空間不足導致更改的內(nèi)容過多。

2）應用程序確認方式-驗證Application的方法是什么？ MCC生成的示例代碼將檢查代碼的第一個地址是否有效。雖然這是有效的，但它的覆蓋范圍相對較低。開發(fā)者可能想要實現(xiàn)CRC檢查例程。 HEXMATE提供了不同的工具來幫助計算十六進制文件中數(shù)據(jù)的校驗和。（關于如何驗證后續(xù)會單獨開篇介紹）

3）中斷選擇-Bootloader開發(fā)者還需要使Application端的所有開發(fā)人員都同意將轉發(fā)到特定處理程序和默認處理程序的中斷列表。

4)配置字-Bootloader開發(fā)者需要確保Application的所有開發(fā)人員都進行相同的配置。在使用Bootloader下載代碼之前，請通過在Application項目上使用MCC重新驗證Bootloader與Application之間的配置位是否匹配，這一點非常重要。

5）Boot區(qū)選項-Bootlaoder開發(fā)者需要為任何選項（如引導選項或指示器選項）創(chuàng)建最終代碼。此外，如果設備的任何外設均已通過其重置設置進行了修改，則需要對相應的Application進行修改，因為他們可能需要在配置其外設時解決這些差異。

Application部分

在理想的情況下，可以在不考慮Bootloader如何工作的情況下完成Application的開發(fā)，并且對于大多數(shù)問題，可以獨立地開發(fā)兩者。但是，由于它們共存于同一芯片上，并且Bootloader是在Application之前設置的，因此兩者之間存在依賴性。無法避免交互的關鍵區(qū)域是共享外設，內(nèi)存映射，中斷和其他區(qū)域的配置。

1）共享資源-共享資源的配置是需要解決的主要問題之一。例如，考慮如果Bootloader和Application都使用UART，但它們以不同的方式使用UART，會發(fā)生什么情況。在Application開發(fā)期間，由于Application固件不使用Bootloader，它們始終會從復位狀態(tài)配置UART，因此，它們僅需根據(jù)初始系統(tǒng)復位值來修改UART寄存器。但是，如果Bootloader在運行時且在跳轉到Application代碼之前配置UART，則UART將不再具有與沒有Bootloader時相同的初始值，并且如果不解決這些差異，則Application將使用UART可能會在此時失敗。因此，對于共享資源，Application代碼需要知道Bootloader如何使用外設以及Bootloader使用的設置和這些設置對Application使用的影響。

2）中斷-雖然Bootloader和Application之間的中斷不是“共享的”，但由于Application中斷向量確實位于Bootloader的閃存地址空間中，因此應用程序需要與Bootloader合作，以使所有中斷都使用正確的方式跳轉至Application方法。 

3）配置位-Bootloader和Application之間的配置位必須相同是非常重要的。Application配置位與Bootloader的配置位匹配非常重要，以至于當MCC提取Bootloader的配置時，它會驗證它們是否相同，如果不一致，則MCC將顯示差異。原因很簡單，配置位僅在運行Bootloader固件之前在設備復位時讀取。這些配置位中的部分將控制時鐘和其他設備特性。如果這些與Application設置不匹配，則該Application需要一個特定的時鐘；如果Bootloader具有不同的設置，則Application代碼將失敗。