不要忽略默認MCU設置

調試是嵌入式設計中很重要的一部分，并且必須跨越硬件/軟件之間的鴻溝。在系統級別，嵌入式設計的功能越來越多地由固件定義，因此要避免漏洞，需要具有特定訓練的工程師在項目的設計階段緊密合作。這也意味著在漏洞不可避免地出現時需要抑制互相推諉的沖動。

也許正是由軟件定義的硬件之特性，使現代嵌入式設計成為如此有意思的職業。每個新的微控制器（MCU）似乎都提供了更高的集成度和更先進的功能，但是在對其完成編程之前，它完全沒有啟用。盡管這種集成和配置顯然是一個促進因素，并且在為產品設計帶來巨大進步，但它有時可能會給工程師帶來無法預料的問題。

諸如MCU之類的嵌入式元件所提供的功能和可配置特性也在不斷提高，并且這些元件提供了許多并非在每個設計中都需要的功能。這些額外的功能可能會被忽略，也較少引起問題。

正如大多數工程師所理解的那樣，這些功能通常由可通過軟件修改的寄存器控制。因此，它們在開機時具有默認設置，并且如果保持不變，將繼續在這些默認設置下運行。在很多情況下，這可能不會帶來問題。但是，如果這些功能一直未使用，而且可能未經測試，則可能會以某種無法預料的方式產生影響。漏洞可能在系統中產生，由可能被忽略的常規功能所導致。

查找故障可能會很困難、耗時且成本高昂，即使在理想條件下。通常，我們通過其影響來識別故障，這些影響一般為工程師提供了足夠的證據來追蹤原因。導致故障的原因與硬件還是軟件有關，在很大程度上是無關緊要的，不過這也許仍存在爭論，重要的是找到并修復故障。

如果故障原因是未正確初始化的低級功能，那么發現它可能會變得更具挑戰性。要了解硬件平臺的初始狀態如何影響整個設計，就需要對整個系統有更高的了解，而追蹤這些難以捉摸的條件會消耗不少資源。

例如，MCU上的SPI總線訪問串行閃存，是許多嵌入式系統中使用的相對簡單的功能。如果在存儲的值中檢測到錯誤，會提示存儲（而不是MCU）出現故障。這是一個客戶的經歷，當從閃存的狀態寄存器連續讀取時提示發現了讀/寫錯誤。自然而然，被認為存儲器件發生了故障，這一理論由以下事實得出：如果在狀態寄存器讀取之間設置了短暫的延遲，則檢測到的故障數量似乎會減少。此外，重新啟動電源似乎可以清除故障一段時間。

客戶工程師們認為，這些癥狀表明串行存儲器發生故障，即使它仍在指定規格的周期極限之內，僅完成了約60k的寫周期。當客戶將串行閃存器件返回給我們進行進一步測試時，即使在執行了超過300k的寫周期后，我們都沒有發現任何故障。

為了找到真正的故障，我們的工程師調查了客戶的應用，并探究了SPI信號。我們發現，這看起來是存儲器件出現故障，實際上是系統噪聲問題，可以很容易地糾正。盡管部分原因是由于MCU與閃存之間的PCB走線阻抗不匹配，但噪聲并非完全是由于不良的PCB設計或信號完整性問題造成的。

盡管看上去似乎是PCB或電路設計問題，但實際上噪聲是SPI信號的過沖和下沖，這是由于信號的驅動強度過大引起的。該過沖足以影響閃存器件的電荷泵，并導致讀取和寫入錯誤。在某些情況下，SPI信號的過沖和下沖也可以解釋為信號躍遷，也可能導致讀取或寫入錯誤。

跟蹤圖像顯示了SPI線上的過沖和下沖

一種可能的解決方案是在信號走線上放置一個RC電路，以減慢信號躍遷的速度。不過，我們發現該設計基于一個相對較新的MCU，允許在固件中修改I/O引腳的驅動強度。降低信號的驅動強度足以消除SPI信號線上的過沖和下沖，從而有效地消除系統級噪聲源。

這里的重點并不是閃存器件如何努力應對大量的系統噪聲，而是MCU上的可配置功能可能會引入一些影響，很容易讓人誤以為是設計中其他器件出現了故障。在這次事例中，我們通過有力的方法檢測到了設計中的故障，并通過我們工程師們的努力解決了問題。

或許我們真正可以從中學到的是，看似硬件的故障也許可以通過軟件輕松修復。看似某個元件的故障，也許可以追溯到另一個元件中的錯誤配置。硬件和軟件工程師之間的合作關系，以及客戶與供應商之間的合作關系應足夠牢固，能夠承受得住使用最新技術進行設計所面臨的挑戰。盡管默認設置的初衷是提供幫助，我們也應當對其進行驗證，優化這些設置可以極大地改善系統性能和可靠性。

原文標題：跨越調試物聯網設備時的軟硬件鴻溝

文章出處：【微信公眾號：Dialog半導體公司】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq