BLDC 控制作業中令人匪夷所思的軟體程式錯誤：留意「唯寫」暫存器

這堪稱是個最離奇的程式錯誤。系統看似正常運算，但遙測資料卻截然不同。根據系統回報，設定馬達轉速的需求輸入值為 85%，但所幸馬達並未運轉。遇到這種情況，人們可能擺擺手說：「不要大驚小怪，沒什麼大不了。」或以為這是遙測解析軟體出了問題，可是總覺得不太對勁。現在是時候深入研究系統，找出造成程式錯誤的原因了。

這款特殊系統採用 Allegro Microsystems 的 A4964 無刷 DC (BLDC) 馬達驅動器晶片。我一直都特別喜愛這款晶片，因為它可以為馬達驅動器提供彈性的解決方案，而且還具備一切所需的控制程式碼，可完全承擔微控制器 (MCU) 的 CPU 週期的工作，並交由專用硬體晶片處理 (圖 1)。

圖 1：A4964 之所以好用，在於能分擔 MCU 的 BLDC 馬達控制工作，並交由專用硬體處理。(圖片來源：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 之後。最後這兩個可定址暫存器是特殊的唯寫與唯讀暫存器。

有時，無論多麼努力撰寫正確的驅動程式或實作軟體，往往都會發生突發狀況。那些令人匪夷所思的程式錯誤，往往也是學習硬體新知的契機，而且通常也會因此收穫了一種新的最佳作法。這個離奇的小程式錯誤，使我不得不「格外留意唯寫／唯讀暫存器」，也因此更慎重地處理這些暫存器。否則若稍有疏忽，讀取唯寫暫存器可能導致系統內發生重大錯誤。