|
來源：Digi-Key 作者：Jacob Beningo 這是最奇怪的問題之一。該系統似乎在按預期工作，但遙測數據表明情況并非如此。決定電機轉速的“按需輸入”報告為 85%，但幸運的是，電機并沒有轉起來。我很想揮揮手說這沒什么大不了的，或者說這是遙測分析軟件的問題，但有些地方不太對勁。現在應該好好研究一下了，進行全系統檢查，找到問題原因。 這個特殊的系統使用的是 Allegro Microsystems A4964 無刷直流 (BLDC) 電機驅動芯片。我越來越喜歡這個芯片，因為它是一種靈活的電機驅動解決方案，而且把所有可能占用 CPU 周期的控制代碼從微控制器 (MCU) 移走，由專門的硬件芯片執行（圖 1）。 
圖 1：A4964 很有用，因為它將無刷直流電機的控制功能從 MCU 遷移至專用硬件。（圖片來源：Allegro Microsystems） 在這個系統配置中，我利用 SPI 通信接口來設置 32 個片上寄存器，這些寄存器將決定 BLDC 電機的驅動和控制方式。 對于該應用，A4964 在安裝過程中由初始化程序讀取包含所需電機配置參數的配置表完成其配置。偽碼（此處僅用于舉例）如下所示（列表 1）。 副本 for(uint8_t WriteIndex = 0; WriteIndex < A4964MaxRegister; WriteIndex++) { // Write value stored in A4964Config at index WriteIndex to the chip } 列表 1：所示為讀取電機配置參數的初始化程序。（代碼來源：Jacob Beningo） 從初始化角度來看，這段代碼沒有什么問題，所以我很快決定檢查該應用中經常被調用的主要邏輯。這段代碼有點兒意思。該應用所處的環境中存在大量輻射，這可能會影響 RAM 中存儲的值。初始化值在啟動時被寫入 A4964 的 RAM 中，所以為了迅速克服可能發生的“位翻轉”，A4964 的內存被定期讀取：如果出現不匹配，則會更新設置。偽代碼如下（列表 2）： 副本 for(uint8_t Index = 0; Index < A4964MaxRegister; Index++) { // Read the A4964 configuration register at location Index // If read value does not match expected value, write configuration value } 列表 2：本地輻射可能會影響存儲在 RAM 中的值，因此為了應對“位翻轉”，A4964 的內存會被定期讀取，如果出現不匹配，則更新設置。（代碼來源：Jacob Beningo） 又出現類似情況，代碼非常簡單，不可能出錯，但芯片中莫名其妙地被寫入了不正確的需求輸入值。這個值似乎是短暫存在的，在報告正確值之前，該值在一些遙測值中出現，然后又一次提供了錯誤的值。真令人費解！ 更為有趣的是，沒有任何配置值或應用值可以將 85% 的值寫入寄存器！那么，這個 85% 的值到底是從哪里來的呢？十進制 85 轉換成十六進制時為 0x55。在代碼庫中有出現 0x55 的地方嗎？當然有。0x55 被用作 SPI 總線上讀操作的虛設寫字符！但是，讀操作是如何被轉換為寫操作的呢？ 事實證明，只要我們仔細觀察 A4964 的規格書（圖 2），答案就非常明顯。
圖 2：數據手冊中的一個片段顯示了這個問題。寄存器 30 的特點是只寫！（圖片來源：Allegro Microsystems） 寄存器 30 管理電機的“按需輸入 (DI)”，是只寫寄存器！嘗試從該寄存器中讀出數據，會導致向該寄存器中寫入虛字節！簡單的初始化和芯片刷新功能嘗試從“按需駛入”寄存器中讀取以驗證設置，并在無意中寫入了一個新的“按需輸入”值。系統繼續按預期工作，因為對寫寄存器的讀取操作總是導致隨后會寫入正確的值，但并不總是足夠快，所以錯誤值沒有出現在系統遙測值中。 對于 A4964，軟件開發者不應在整個內存圖中寫入配置數據，而是需要在寫入寄存器 29 之后停止。最后兩個可尋址的寄存器是特殊的寫和只讀寄存器。 有時，不管我們為正確編寫驅動程序或實施軟件付出了多少努力，總會有一些奇奇怪怪的問題。奇怪的問題往往是一個學習有關硬件新知識的機會，而且總會形成新的最佳實踐。就是由于這個奇怪的問題，我把“仔細觀察只讀/只寫寄存器”添加到我的列表中，并確保我正確理解、使用這些寄存器。否則，讀取那個只寫寄存器可能會給系統帶來生災難性后果。 |
