ATMEL at91sam9261，操作系统Wince5.0，256M的三星K9F2G08闪存，系统用了32M，其他是NandFlash文件系统，BSP用的是ATMEL官网公布的BSP。
一般情况下向NandFlash中读写文件都是正常的，但是长时间连续（大约一个多月，每10分钟大约写1M的文件，存储到100多M时会删除部分数据）多次写文件，删除文件重启后，NandFlash就不能写入了，一写入就会死机，读文件还都是正常的，看调试信息，发现逻辑0块被标记为坏块，擦除闪存后可恢复正常，而且逻辑0块可以擦除恢复正常。
各位兄弟有没有遇到类似问题的，出问题的原因可能有哪些呢？麻烦帮忙分析分析。
flash的驱动里面最重要是要做块的管理，对于写操作，还要做均衡算法；估计是你的这个驱动算法有问题。
引用: 引用 2 楼 rzsheng 的回复:
flash出现坏块了，重新格式化就应该是可以了
格式化肯定可以恢复正常，使用过程出现坏块是可以正常标记处理的，逻辑0块其实并没有坏，而误标记为坏块的，这样导致整个文件系统就不能再写东西了，一写就死机。
一般逻辑0块，都是用作特殊功能信息的储存；
我们也是用Wince6.0，256M的三星K9F2G08，我们的逻辑0块就用来储存ntim 和坏块重分配表。
一般不会逻辑0块 为坏块的。
LZ应该是破坏了NAND的MBR信息，就是在第0块
nandflash 频繁写的话,问题还真是比较多
wince里面,坏块管理和负载均衡的算法都是PB自带,ms提供的,BSP里面只要实现物理读写flash的函数就行了
按道理来说不应该有什么问题
可是我们也碰到过类似LZ的问题.因为我们那个项目的数据量比较小,但是读写频繁,后来就干脆存放在e2prom里面了.
没有去深究这个问题的真正原因.
猜测和异常断电这类的原因有关???
希望有高手来指点下.
而且我一直不太明白,三星的FMD驱动为什么要把每个block的page数强制设置成256
#define PAGES_PER_BLOCK 256 // Phisical 64 * logical 4
这样小页的flash需要用8个block来模拟一个大的block,不是严重影响写nand的性能.
对于大页的flash就没有什么问题
难道这么做就是为了兼容,不过现在小页的flash确实用的越来越少了.
你不是说逻辑0块坏掉了吗？重新擦写当然会重新出现逻辑0块，但这个逻辑0块在物理上可能已经换到别的块去了。
引用: 引用 8 楼 reallyu 的回复:
nandflash 频繁写的话,问题还真是比较多
wince里面,坏块管理和负载均衡的算法都是PB自带,ms提供的,BSP里面只要实现物理读写flash的函数就行了
按道理来说不应该有什么问题
可是我们也碰到过类似LZ的问题.因为我们那个项目的数据量比较小,但是读写频繁,后来就干脆存放在e2prom里面了.
没有去深究这个问题的真正原因.
猜测和异常断电这类的原因有关???
希望有高手来指点下.
而且我一直不太明白,三星的FMD驱动为什么要把每个block的page数强制设置成256
#define PAGES_PER_BLOCK 256 // Phisical 64 * logical 4
这样小页的flash需要用8个block来模拟一个大的block,不是严重影响写nand的性能.
对于大页的flash就没有什么问题
难道这么做就是为了兼容,不过现在小页的flash确实用的越来越少了.
可能与断电有关系，现在拿了几台在公司模拟测试呢，运行情况比较好的，大半年了也没出问题的。
BSP里面代码是很简单，只是把一些FMD接口实现，所以出问题也不知道从哪里找，实在不行准备直接进行读写了，不用文件系统了，这个问题真的弄的很郁闷。
ce6中不是带了FAL的源代码了吗？把它拿出来，加点调试信息，分析一下，看是在什么时候将0块标记为坏块的。
引用: 引用 11 楼 pilixuanke 的回复:
ce6中不是带了FAL的源代码了吗？把它拿出来，加点调试信息，分析一下，看是在什么时候将0块标记为坏块的。
用的CE5.0，现在模拟测试主要是看看在哪个环节可能导致问题的产生。
引用: 引用 13 楼 garyliu1104 的回复:
引用 11 楼 pilixuanke 的回复:
ce6中不是带了FAL的源代码了吗？把它拿出来，加点调试信息，分析一下，看是在什么时候将0块标记为坏块的。
用的CE5.0，现在模拟测试主要是看看在哪个环节可能导致问题的产生。
1. 你测试出来问题的机台测试方法是：十分钟写1MB&测试一个多月&中间频繁重启
没有问题的机台方法是：大半年了也没出问题
从这点上看测试方法并不一样呀，没啥可比性呀
2. 建议去掉机器重启的动作，以避免电压电流波动对flash ic的影响，重新挂机，不过时间比较长哦
这个测试的目的是验证是否是电压电流波动对数据产生的影响
引用: 引用 15 楼 guopeixin 的回复:
引用 13 楼 garyliu1104 的回复:
引用 11 楼 pilixuanke 的回复:
ce6中不是带了FAL的源代码了吗？把它拿出来，加点调试信息，分析一下，看是在什么时候将0块标记为坏块的。
用的CE5.0，现在模拟测试主要是看看在哪个环节可能导致问题的产生。
1. 你测试出来问题的机台测试方法是：十分钟写1MB&测试一个多月&中间频繁重启
? ? ? ? ? ? 没有问题的机台方法是：大半年了也没出问题
从这点上看测试方法并不一样呀，没啥可比性呀
2. 建议去掉机器重启的动作，以避免电压电流波动对flash ic的影响，重新挂机，不过时间比较长哦
这个测试的目的是验证是否是电压电流波动对数据产生的影响
以前十分钟写1M，一个月出现问题，现在你就不停的写，不停地删除，浮现问题应该比较快
引用: 引用 16 楼 guopeixin 的回复:
引用 15 楼 guopeixin 的回复:
引用 13 楼 garyliu1104 的回复:
引用 11 楼 pilixuanke 的回复:
ce6中不是带了FAL的源代码了吗？把它拿出来，加点调试信息，分析一下，看是在什么时候将0块标记为坏块的。
用的CE5.0，现在模拟测试主要是看看在哪个环节可能导致问题的产生。
1. 你测试出来问题的机台测试方法是：十分钟写1MB&测试一个多月&中间频繁重启
? ? ? ? ? ? 没有问题的机台方法是：大半年了也没出问题
从这点上看测试方法并不一样呀，没啥可比性呀
2. 建议去掉机器重启的动作，以避免电压电流波动对flash ic的影响，重新挂机，不过时间比较长哦
这个测试的目的是验证是否是电压电流波动对数据产生的影响
以前十分钟写1M，一个月出现问题，现在你就不停的写，不停地删除，浮现问题应该比较快
通过几天的测试：问题可以重现，Flash频繁写擦，1分钟1M，且多次调用文件读写函数，用5台测试一周，有两台出现问题，闪存一写就死机，看启动信息这两台均出现坏块，但是擦除后闪存重新整理就没有坏块了，说明是假坏块。不知道有没有朋友做过类似的测试，是不是CE5这么用闪存就可能会出现问题呢？现在打算改程序，减少闪存的使用，原因继续查找中。。有进展的话再和大家分享。
京公网安备 11010802033920号
