跨越調試物聯(lián)網(wǎng)設備時(shí)的軟硬件鴻溝
不要忽略默認MCU設置
調試是嵌入式設計中很重要的一部分,并且必須跨越硬件/軟件之間的鴻溝。在系統級別,嵌入式設計的功能越來(lái)越多地由固件定義,因此要避免漏洞,需要具有特定訓練的工程師在項目的設計階段緊密合作。這也意味著(zhù)在漏洞不可避免地出現時(shí)需要抑制互相推諉的沖動(dòng)。
也許正是由軟件定義的硬件之特性,使現代嵌入式設計成為如此有意思的職業(yè)。每個(gè)新的微控制器(MCU)似乎都提供了更高的集成度和更先進(jìn)的功能,但是在對其完成編程之前,它完全沒(méi)有啟用。盡管這種集成和配置顯然是一個(gè)促進(jìn)因素,并且在為產(chǎn)品設計帶來(lái)巨大進(jìn)步,但它有時(shí)可能會(huì )給工程師帶來(lái)無(wú)法預料的問(wèn)題。
諸如MCU之類(lèi)的嵌入式元件所提供的功能和可配置特性也在不斷提高,并且這些元件提供了許多并非在每個(gè)設計中都需要的功能。這些額外的功能可能會(huì )被忽略,也較少引起問(wèn)題。
正如大多數工程師所理解的那樣,這些功能通常由可通過(guò)軟件修改的寄存器控制。因此,它們在開(kāi)機時(shí)具有默認設置,并且如果保持不變,將繼續在這些默認設置下運行。在很多情況下,這可能不會(huì )帶來(lái)問(wèn)題。但是,如果這些功能一直未使用,而且可能未經(jīng)測試,則可能會(huì )以某種無(wú)法預料的方式產(chǎn)生影響。漏洞可能在系統中產(chǎn)生,由可能被忽略的常規功能所導致。
查找故障可能會(huì )很困難、耗時(shí)且成本高昂,即使在理想條件下。通常,我們通過(guò)其影響來(lái)識別故障,這些影響一般為工程師提供了足夠的證據來(lái)追蹤原因。導致故障的原因與硬件還是軟件有關(guān),在很大程度上是無(wú)關(guān)緊要的,不過(guò)這也許仍存在爭論,重要的是找到并修復故障。
如果故障原因是未正確初始化的低級功能,那么發(fā)現它可能會(huì )變得更具挑戰性。要了解硬件平臺的初始狀態(tài)如何影響整個(gè)設計,就需要對整個(gè)系統有更高的了解,而追蹤這些難以捉摸的條件會(huì )消耗不少資源。
例如,MCU上的SPI總線(xiàn)訪(fǎng)問(wèn)串行閃存,是許多嵌入式系統中使用的相對簡(jiǎn)單的功能。如果在存儲的值中檢測到錯誤,會(huì )提示存儲(而不是MCU)出現故障。這是一個(gè)客戶(hù)的經(jīng)歷,當從閃存的狀態(tài)寄存器連續讀取時(shí)提示發(fā)現了讀/寫(xiě)錯誤。自然而然,被認為存儲器件發(fā)生了故障,這一理論由以下事實(shí)得出:如果在狀態(tài)寄存器讀取之間設置了短暫的延遲,則檢測到的故障數量似乎會(huì )減少。此外,重新啟動(dòng)電源似乎可以清除故障一段時(shí)間。
客戶(hù)工程師們認為,這些癥狀表明串行存儲器發(fā)生故障,即使它仍在指定規格的周期極限之內,僅完成了約60k的寫(xiě)周期。當客戶(hù)將串行閃存器件返回給我們進(jìn)行進(jìn)一步測試時(shí),即使在執行了超過(guò)300k的寫(xiě)周期后,我們都沒(méi)有發(fā)現任何故障。
為了找到真正的故障,我們的工程師調查了客戶(hù)的應用,并探究了SPI信號。我們發(fā)現,這看起來(lái)是存儲器件出現故障,實(shí)際上是系統噪聲問(wèn)題,可以很容易地糾正。盡管部分原因是由于MCU與閃存之間的PCB走線(xiàn)阻抗不匹配,但噪聲并非完全是由于不良的PCB設計或信號完整性問(wèn)題造成的。
盡管看上去似乎是PCB或電路設計問(wèn)題,但實(shí)際上噪聲是SPI信號的過(guò)沖和下沖,這是由于信號的驅動(dòng)強度過(guò)大引起的。該過(guò)沖足以影響閃存器件的電荷泵,并導致讀取和寫(xiě)入錯誤。在某些情況下,SPI信號的過(guò)沖和下沖也可以解釋為信號躍遷,也可能導致讀取或寫(xiě)入錯誤。
跟蹤圖像顯示了SPI線(xiàn)上的過(guò)沖和下沖
一種可能的解決方案是在信號走線(xiàn)上放置一個(gè)RC電路,以減慢信號躍遷的速度。不過(guò),我們發(fā)現該設計基于一個(gè)相對較新的MCU,允許在固件中修改I/O引腳的驅動(dòng)強度。降低信號的驅動(dòng)強度足以消除SPI信號線(xiàn)上的過(guò)沖和下沖,從而有效地消除系統級噪聲源。
這里的重點(diǎn)并不是閃存器件如何努力應對大量的系統噪聲,而是MCU上的可配置功能可能會(huì )引入一些影響,很容易讓人誤以為是設計中其他器件出現了故障。在這次事例中,我們通過(guò)有力的方法檢測到了設計中的故障,并通過(guò)我們工程師們的努力解決了問(wèn)題。
或許我們真正可以從中學(xué)到的是,看似硬件的故障也許可以通過(guò)軟件輕松修復??此颇硞€(gè)元件的故障,也許可以追溯到另一個(gè)元件中的錯誤配置。硬件和軟件工程師之間的合作關(guān)系,以及客戶(hù)與供應商之間的合作關(guān)系應足夠牢固,能夠承受得住使用最新技術(shù)進(jìn)行設計所面臨的挑戰。盡管默認設置的初衷是提供幫助,我們也應當對其進(jìn)行驗證,優(yōu)化這些設置可以極大地改善系統性能和可靠性。
評論