在一些新的 STM32 系列中，比如 STM32L4、STM32G0、STM32G4 等，除了 Flash 標準編程之外，還可以支持 Flash 的快速編程。那么對于 STM32G0 來說，在使用快速編程時，有哪些需要注意之處？

難點

某STM32用戶在其產品設計中，采用了 STM32G070RBT6，開發工程師希望在進行代碼升級的時候使用快速編程來提高編程速度，但是寫代碼時遇到很多問題。而在目前的 STM32G0 的 Cube 庫中并沒有 FLASH_FastProgram 例程，所以客戶希望得到一個參考例程來快速實現設計。

調研

1

了解問題

檢查最新版本的STM32Cube_FW_G0_V1.3.0/Projects/STM32CubeProjectsList.html 文件，確實可以看到現有的 STM32G0Cube 庫中并沒有 FLASH_FastProgram 例程，根據參考手冊，參考STM32Cube_FW_L4_V1.16.0ProjectsNUCLEO-L452REExamplesFLASHFLASH_FastProgram 例程，對 STM32Cube_FW_G0_V1.2.0ProjectsNUCLEO-G070RBExamplesFLASHFLASH_EraseProgram 進行修改以移植代碼。以下就撰寫例程代碼時，需要注意的問題簡單地介紹一下。

2

分析問題

首先，先來看一下 STM32L4 中 FLASH_FastProgram 例程中 readme.txt 對本示例的解釋，可以看到這是一個演示如何配置和使用 API 函數對內部 Flash 存儲器進行擦除和快速編程的示例。

先來看一下 FastProgram 最核心的函數 FLASH_Program_Fast()。

在 STM32L4Cube 中的 stm32l4xx_hal_flash，它是這么定義的：

static void FLASH_Program_Fast(uint32_t Address, uint32_t DataAddress)

而在 STM32G0Cube 中的 stm32g0xx_hal_flash，其定義是：

static __RAM_FUNC void FLASH_Program_Fast(uint32_t Address, uint32_t DataAddress)

這兩者有什么區別呢？就是在 STM32G0Cube 庫中使用了__RAM_FUNC 指明了這個函數是位于 RAM 區域的。為什么呢？

第一個要點：對 Flash 進行快速編程的時候不允許對 Flash 進行讀取，所以需要將這個快速編程的代碼放置于 RAM 中運行，以避免對 Flash 進行命令讀取。

那么，大家可能又有疑問了，那為什么 STM32L4Cube 中并沒有使用__RAM_FUNC 關鍵字，STM32L452 的 Flash 是 single bank，難道它就不需要放到RAM 里？如果大家細心的話，可以看到STM32L4這個例程中的鏈接文件是 stm32l452xx_sram.icf，在icf 文件中定義了ROM的地址為 0x20000000~0x20015FFF，也就是說這個示例代碼是跑在 RAM的，所以就不需要在這邊使用__RAM_FUNC 關鍵字了。還可以在 STM32L4 示例代碼中看到對整片 Flash 進行擦除而猜到這一點。從 STM32G0Cube 庫中 FLASH_Program_Fast() 這個函數的定義，可以看出它是可以直接使用 stm32l452xx_flash.icf 將快速編程核心代碼以外的其他代碼都放在 Flash 上面跑的，這個可能更符合用戶做 IAP 升級的習慣，當然，在這個情況下，我們就可能需要在程序中使用頁擦除而不是整片擦除了。

第二個要點：因為 Flash 進行快速編程的時候不允許對 Flash 進行讀取，所以還需要注意快速編程的源數據應該位于 RAM 而非 Flash，以避免對 Flash 進行數據讀取。

因為在 Flash 快速編程的時候，需要將 64 個 word 一個行 (256 Bytes) 的數據寫到目標地址中，所以也就是說快速編程時，還會去訪問源數據，如果源數據放在Flash就會導致問題產生。下面，我們解答一個移植中常見問題。

在從 STM32L4 到 STM32G0 的移植中，直接將 STM32L4 示例代碼中定義的源數據的數組代碼：

/* Table used for fast programming */ static const uint64_t Data64_To_Prog[FLASH_ROW_SIZE] = {0x0000000000000000, 0x1111111111111111, 0x2222222222222222, 0x3333333333333333, 0x4444444444444444, 0x5555555555555555, 0x6666666666666666, 0x7777777777777777, 0x8888888888888888,0x9999999999999999, 0xAAAAAAAAAAAAAAAA,0xBBBBBBBBBBBBBBBB,0xCCCCCCCCCCCCCCCC,0xDDDDDDDDDDDDDDDD, 0xEEEEEEEEEEEEEEEE, 0xFFFFFFFFFFFFFFFF, 0x0011001100110011, 0x2233223322332233, 0x4455445544554455, 0x6677667766776677, 0x8899889988998899,0xAABBAABBAABBAABB, 0xCCDDCCDDCCDDCCDD,0xEEFFEEFFEEFFEEFF, 0x2200220022002200, 0x3311331133113311, 0x6644664466446644, 0x7755775577557755, 0xAA88AA88AA88AA88,0xBB99BB99BB99BB99, 0xEECCEECCEECCEECC, 0xFFDDFFDDFFDDFFDD};

原封不動地拷貝到 STM32G0 的項目中，在測試的時候，總是會發現程序會死在快速編程的過程中。最后檢查才發現問題出現在這個數組的定義上。STM32L4 使用 stm32l452xx_sram.icf 定義了 ROM 的地址為 0x20000000~0x20015FFF，因此這個 const 關鍵字的數據實際上也是位于 RAM 中的。但是將這個數組搬到 STM32G0 的項目時，因為使用的是stm32l452xx_flash.icf，導致這個數組位于 Flash 中，在快速編程的時候程序就會去訪問 Flash 讀取源數據，就導致程序死在快速編程過程。所以，需要將數組修改為：

/* Table used for fast programming */ uint64_t Data64_To_Prog[FLASH_ROW_SIZE] = { 0x0000000000000000, 0x1111111111111111, 0x2222222222222222, 0x3333333333333333, 0x4444444444444444, 0x5555555555555555, 0x6666666666666666, 0x7777777777777777, 0x8888888888888888,0x9999999999999999, 0xAAAAAAAAAAAAAAAA,0xBBBBBBBBBBBBBBBB, 0xCCCCCCCCCCCCCCCC,0xDDDDDDDDDDDDDDDD, 0xEEEEEEEEEEEEEEEE,0xFFFFFFFFFFFFFFFF,0x0011001100110011,0x2233223322332233, 0x4455445544554455, 0x6677667766776677, 0x8899889988998899,0xAABBAABBAABBAABB, 0xCCDDCCDDCCDDCCDD,0xEEFFEEFFEEFFEEFF, 0x2200220022002200, 0x3311331133113311, 0x6644664466446644, 0x7755775577557755, 0xAA88AA88AA88AA88,0xBB99BB99BB99BB99, 0xEECCEECCEECCEECC, 0xFFDDFFDDFFDDFFDD};

這樣程序就可以正常運行。

第三個要點：使用在 Flash 上跑 IAP 代碼進行快速編程的話，建議看一下參考手冊里快速編程的步驟，在步驟中的第一步時使用 Page Erase 對當前頁進行擦除后對當前頁進行快速編程，每次一頁，也就是“擦除當前頁→快速編程當前頁→擦除下一頁→快速編程下一頁→……”。

下面來仔細閱讀參考手冊，關注一下另外幾個要點。

第四要點：關于時鐘，在快速編程的過程中，CPU 的時鐘頻率（HCLK）不得低于 8MHz。這個在大家的應用中一般都是滿足的，所以還好。另外，在“注”里邊說明，FSTPG 位置 1 時，內部振蕩器 HSI16 會自動使能，在 FSTPG 位清零時自動禁止，但 HSI16 之前已經通過 HSION 使能的情況除外。

第五要點：這一行 32 個雙字必須連續寫入，兩個雙字寫入請求的最大時間間隔大約為 20us。如果后面的寫入請求時間超出了這個范圍，那么將導致 MISSERR 錯誤產生。一般來說，只要您使用的是庫文件的函數，不用擔心這個問題。

第六要點：在兩次擦除之間，每一行的寫入，高壓持續時間不能大于8ms。一般來說，只要HCLK 的時鐘保證在8MHz以上，對32個雙字的連續寫序列，時間上還是沒問題的。如果真的程序沒寫好，導致存在這種情況，那么在芯片內部有個7ms 的檢測機制，超時就會自動停止編程，并置位 FASTERR。

第七要點：關中斷。至于為什么？大家都知道，就不多說了。如果大家使用 Cube 庫，也可以看到在 FLASH_Program_Fast() 在進行關中斷，但是示例中并沒有恢復打開中斷，所以大家在實際應用中根據情況看是否需要將中斷打開。

3

問題解決

上面幾個要點，如果軟件工程師使用的是 STM32Cube 庫，那么在撰寫代碼上最主要是檢查一下前面三個要點的情況。后面幾個要點稍微了解就可以了。

結論

Flash的快速編程可以節省編程的時間，但是在使用上因為有不少限制因素，使得它的軟件設計比標準編程復雜，需要工程師細心調試。

建議

軟件工程師在撰寫Flash快速編程時，仔細閱讀下參考手冊，并參考本文中的各個要點，然后根據自己的實際應用情況，理清邏輯，來撰寫完整的 Flash 編程代碼。

原文標題：被STM32G0快速編程難倒的，看這里

文章出處：【微信公眾號：嵌入式ARM】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq