在Nandflash廣泛應用的今天,其高性價比和極大燒錄不良率幾乎時刻共存,那么 Nandflash究竟有何特性導致其頻發燒錄事故?今天就和大家分享nandflash排雷攻略。
Nandflash芯片以其高性價比,大存儲容量在電子產品中廣泛應用。但是,在此量大質優的應用領域,很多客戶卻痛苦于批量質量問題:專用工具無法滿足量產,量產工具卻可能出現極大的不良品率,那么究竟要如何解決呢?
其根本原因在于:目前大部分用戶并不是很了解Nandflash燒錄的復雜性。
用戶常采用很直接的方法,即用一顆能正常運行的NandFlash芯片作為母片,在連接編程器之后,點擊燒錄軟件上的“讀取”按鈕,把數據從芯片里面完整讀取出來,再找幾顆空芯片,把數據重復寫進去。本以為可達到量產的目的,但實際上生產出來的產品卻達不到品質的要求,往往會出現批量的產品異常開機或啟動的狀況!
1
原因分析
原因究竟在哪里呢,在分析之前,那就先得了解一下Nandflash基本的工藝特性:
首先,我們來看NandFlash存儲結構,它由多個Block組成,每一個Block又由多個Page組成,每個Page又包含主區(Main Area)和備用區(Spare Area)兩個域。其次NandFlash是有壞塊的,由于NandFlash的工藝不能保證Nand的Memory Array在其生命周期中保持性能的可靠。
因此在Nand的生產中及使用過程中會產生壞塊的。
1
壞塊的影響
因為壞塊影響了數據的存放地址,用戶就不能按常用方法那樣,把母片的數據全部讀取出來,然后再把數據原原本本拷貝到其他芯片上了,也就產生了傳統拷貝機無法量產Nandflash的問題!
既然NandFlash有壞塊是無法避免的問題,那就要想辦法避開那些壞塊;最簡單、最有效、最常用的方法就是:跳過!
使用“跳過壞塊”,我們很好地解決了NandFlash的壞塊問題,原本寫到壞塊的數據,我們也安全轉移到下一個塊里面!
2
地址變化
跳過是一種常用而有效的方法,但是實際上,根本問題還依然存在,細心的人會發現,數據存放的地址也發生了變化!
實際應用中,很多用戶會把多個文件數據同時存儲到NandFlash上(比如uboot、uImage、Logo、rootfs等燒錄文件),并給每個文件在NandFlash存儲單元中劃分了一定大小的存儲空間區域,指定了每個文件存儲的起始物理地址塊;如果某個區域出現了壞塊,為了避開它,勢必需要把數據安全往下一塊轉移,而引起的后果就是后續燒錄文件的起始物理地址也隨著發生了偏移,這將會導致主控MCU無法通過固定的地址,準確、完整地獲取到每個文件的數據,最終造成的結果就是產品異常啟動。
2
解決建議
解決建議:分區燒錄
分區燒錄,用戶提前設置好每個文件燒錄的起始塊地址,無論壞塊出現在哪個空間區域,都可以確保每個文件起始塊地址都不會發生偏移變化,數據也將根據客戶預設方案存放在NandFlash存儲區域內,主控MCU也能準確完整讀取到每個文件的數據,那么產品就正常跑起來了!
3
解決方案參考
ZLG立功科技·致遠電子的P800系列編程器支持按分區燒錄(并可支持多種分區格式),可按照每個用戶方案需求,設置每個文件的起始塊地址和燒錄塊長度,即可達到高效率燒錄,又可提高芯片燒錄良品率!
同時,P800系列搭載獨立操作系統,還可滿足工廠全脫機,一鍵批量的燒錄要求。
-
芯片
+關注
關注
456文章
51190瀏覽量
427293 -
mcu
+關注
關注
146文章
17324瀏覽量
352655 -
nandflash
+關注
關注
0文章
48瀏覽量
20272
原文標題:Nandflash量產燒錄排雷攻略
文章出處:【微信號:ZLG_zhiyuan,微信公眾號:ZLG致遠電子】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
【小e物聯網申請】智能排雷小車
GPIO中斷與NandFlash讀寫不能同時成功
nandflash啟動問題
基于SEP4O20的Linux NandFlash驅動設計
![基于SEP4O20的Linux <b class='flag-5'>NandFlash</b>驅動設計](https://file1.elecfans.com//web2/M00/A5/E1/wKgZomUMOpmAb1bEAAAOJ5Et-fQ250.jpg)
基于AMBA APB總線NandFlash控制器的設計
cheap_flash_fs極速版--嵌入式NandFlash文
NorFlash、NandFlash、eMMC閃存三者對比
NANDFLASH快速BCH編解碼算法及便件實現
![<b class='flag-5'>NANDFLASH</b>快速BCH編解碼算法及便件實現](https://file.elecfans.com/web1/M00/D9/4E/pIYBAF_1ac2Ac0EEAABDkS1IP1s689.png)
評論