開箱體驗

試用背景

去年年初，有新項目要讓移動式容器設備的監控數據上云，選型時主要考慮三個系列STM32L0、STM32G0和STM8。最初有意向選用STM32L052RB，主要是為了滿足低功耗需求。恰逢G0系列上市，價格親民，性能卻要高很多，但顧慮G0推出不久，生態不夠成熟，項目周期又趕得緊，綜合考慮，最終采用STM8。但用過之后，發現STM8不適合這個項目，最尷尬的，就是AD采樣不準和主頻太低，16MHz主頻下，無法實現快速的IO翻轉。

2019年底，電堂發起了G0試用活動，申請到一塊，用來完善一下這個移動式容器設備監控數據上云的項目。配合移遠的BC28模塊，STM32G0+BC28，實現數據上云。

開箱檢驗

NUCLEO-64的板子，外形尺寸都差不多，如圖。

報告組成

之前做過G4的試用，流程是先使用后整理報告，整理報告的時候又重新看了一遍當時設計的手稿，消耗時間長，且要點容易遺忘。本次優化一下試用流程，一邊使用，一邊記錄，把最原始的體驗記錄下來，以免時間一過，又忘了干凈。

試用分為兩部分：① NUCLEO-G071RB + IOT-AT3080V1.0 + X-NUCLEO-IKS01A2連接阿里云；② NUCLEO-G071RB + BC28 + X-NUCLEO-IKS01A2連接阿里云。為什么采用這樣的方式，前面學習過L4連接阿里云IoT的教程，當時是在NUCLEO-L4R5ZI上調試的，想先把相應的工程移植到G0上來，實現上行鏈路打通，之后再將WiFi模塊替換為BC28，這樣調試起來也會方便。

試用過程

NUCLEO-G071RB通過WiFi連接阿里云

項目的軟件框架、IAR工程及文件結構與L4的Demo類似，只是底層將L4的HAL改成了G0的HAL。

一、MCU外設的使用

使用的外設包括：與WIFI擴展板的接口、與傳感器擴展板的接口、虛擬串口接口、USER按鍵接口和LED等。下面將NUCLEO-L4R5ZI接口與NUCLEO-G071RB接口做一個對比展示，方便后續移植時對比參考。

1、與WIFI擴展板的接口

2、與傳感器擴展板接口定義

3、虛擬串口接口

4、按鍵與LED燈

同時，Systick提供系統延時，并未Paho協議棧提供Timer。

二、使用CubeMx生成原始工程

CubeMx生成原始工程的過程不詳述，按照2.1.1的外設配置，配置對應的引腳、接口即可。系統主頻配置為64MHz，TIM2_PWM控制燈以0.5s間隔閃爍，故預分頻為：1280-1；分頻后計數時鐘為50KHz，自動重載寄存器值為50000-1，捕獲/比較寄存器值為25000。配置界面如下：

三、軟件移植與調試

移植Paho MQTT協議棧、移植mbedtls，調試溫濕度傳感器，適配Paho MQTT的過程在L4的教程中有詳細描述，從L4上將代碼移植到G0上，主要是Flash讀寫有寫不一樣。L4是雙bank的Flash，Flash的操作較麻煩，相對而言，G0的操作要簡單很多，參考SDK中的Flash例程修改flash_l4R.c文件，（路徑：STM32Cube_FW_G0_V1.3.0ProjectsNUCLEO-G071RBExamplesFLASHFLASH_EraseProgram），主要是修改FLASH_unlock_erase()函數和FLASH_get_bank()函數，修改后，編譯無誤。

下載調試過程，沒有想象中那么順暢，輸入wifi信息時，一切正常，連接wifi也正常，但輸入三元組信息，一直報錯：

Error erasing at 0x08018000

調試①：Wifi信息用默認的，軟件執行到三元組保存的位置，仍然同樣的錯誤。數據是保存的同一個位置的，應該不是Flash函數讀寫的問題。

調試②：注釋掉net_if_init()函數中wifi信息獲取相關代碼，即不運行wifi信息獲取及wifi初始化過程，只運行三元組信息保存的過程，保存正確；

調試③：重新開啟wifi初始化過程，用已經設置正確的參數配網、連接阿里云，軟件運行正常；可以在云端看到上報的數據。

這進一步證明三元組保存的相關函數，是沒有問題的，但為何加上wifi配置相關的代碼后，會影響三元組信息保存呢，單步調試發現，當運行到EMW3080_GetVersionInfo()函數的*temp=0時，FLASH的SR寄存器的BIT CFGBSY就會置位，進一步排查發現，執行完temp = strstr(Token, ",")后，沒有查到到“,”，temp為0x00，此時給地址0x00的位置賦值，導致FLASH的SR寄存器的BIT CFGBSY置位。

解決方法：判定temp值，如果不為空，才執行賦值操作，如下圖示：

問題到這里已經完美解決了，指針跑飛，導致運行異常。那為什么在L4的板子上沒有出現這個問題呢？（具體的表現：執行完EMW3080_GetVersionInfo()函數后，三元組信息及后續的Flash保存操作都無法完成，因為CFGBSY一直為1）

分析L4和G0的HAL_FLASHEx_Erase()→FLASH_WaitForLastOperation()，有如此的不同：

L4沒有CFGBSY位，仿真發現，當執行*temp=0語句時，FLASH狀態寄存器并沒有發生變化，但這并不能說L4就是沒有問題的，給地址為0x00000000的位置寫數據0，可能會帶來不可預期的結果。

四、Demo演示與現象

正常運行的效果截圖，包括云平臺日志和終端日志截圖。

終端日志：

云端日志：

終端日志：

云端日志：

終端日志

云端日志：

終端日志：

云端日志：

NUCLEO-G071RB通過NB連接阿里云

在NUCLEO-G071RB通過WiFi連接阿里云基礎上，修改網絡設備層的相關配置，將WIFI改為NB模組（BC28），外設和CubeMx的原始工程都之相似。

一、軟件移植與調試

有NUCLEO-G071RB通過WiFi連接阿里云的基礎后，移植過程相對來說簡單。Demo運行時，每5s的數據上報是正常的，但是溫度異常報警上傳后，會導致軟件跑飛，分析程序發現，軟件是在發送完報警信息，再發送下一條正常上報信息時，發送不成功，觸發重新連接，重新連接三次失敗后軟件跑飛。

重連的機制是有問題的，就算是重連失敗，程序也不應該跑飛；經查實，發現網絡層操作了一個零指針，增加了防護機制；

導致數據發送失敗是跑飛的原因，為何數據會在發送完一條異常報警信息后，在下一次的正常數據幀中報錯？我在L4的程序上運行，是正常的，問題肯定是由G0導致的。

軟件上排查了一大圈，排查的過程就不描述了，最終定位到，在發送完異常報警幀后，NB模塊重啟了，BC28這個模塊有個特點，必須發送AT+CFUN=1后才能響應后續的聯網指令，因而網絡一直連接不成功。

比較坑的是，買完BC28模組后，在官網上并沒有下載到原理圖，因而不清楚各個引腳的分配布局（Arduino接口的UART、供電是固定的，所以調試還是沒有問題的），找店家詢問也一直沒有響應，最終，通過前項目的FAE拿到了原理圖，發現用于報警狀態指示的LED燈（PA5），連接到了Arduino接口的D13上，而在BC28的板子上，D13是RESET引腳，當發送完報警信息后，會控制LED狀態變化，此時就相當于復位了BC28！禁用掉點燈相關操作，問題解決。

關于這個調試，前后忙活了兩個禮拜（當然只有下班和周末零碎的時間弄），開始一直懷疑是軟件移植帶來的bug，拼命的查軟件問題，弄錯了方向。

二、Demo演示與現象

Demo運行效果，云平臺日志與NUCLEO-G071RB通過WiFi連接阿里云相似，終端日志如下：

總結

整體說來，本次試用還算比較順利，除了移植3080B、BC28外，還嘗試移植了ESP8266的驅動，STM32G0無論是速度還是外設資源，都要比8位機強大的多。將云連接移植到G0上實現還是有意義的，G0比其他系列更有性價比，也能跑起Paho等輕量級的協議棧。在以后的應用中，采用G0上云的方案會更有用武之地。

點擊鏈接觀看更多相關課程：

電堂科技?c.51diantang.com