661023

引用 18 楼 guopeixin 的回复:
1. 有可能是驱动架构的问题，即fal里面的代码在操作slc和mlc的差异造成的
2. 如果是lz操作硬件方式不对的话，os也应该有概率的存在坏掉的情况，但是并没有出现，操作hw方式不对的可能性比较小
---------------------------------------
我觉得lz可以先验证一下问题的根源在那里
1. lz提到放置文件比较少的时候，重启盘符还在，文件没了
很可能是分区被格式化掉了，lz先在fmd的代码中打印一下开机时候被格式化的block的号，看一下这些是否在文件系统分区

2. 另外，你上面提到“还有就是当存储的东西多点之后，100兆，下次启动的时候，就没有了nandflash盘符，也就是存储部分都消失了，而东西少的
时候重启丢失数据，但是盘符还在，存储区也在。”，确认一下，发生问题的概率和文件个数的多少有关系么

1 FMD_EraseBlock 我在这个函数里面加的打印信息发现一次也没调用。拷东西进去的时候，
FMD_WriteSector里面有打印信息，而且拷进去的程序能正常使用。对这个格式化不太了解，还有其他
地方做这个操作吗?
2 东西多的时候，基本上每次都会导致盘符消失，东西少的时候偶尔会出现。不过总的做的次数也不太多3次拷贝大的都出现了，东西少的有10来次只有一次出现。

mfxbb

引用 15 楼 waterdream0820 的回复:
引用 14 楼 programmerno1 的回复:
配置问题~~~
不明白说的是哪部分？？

我选的是General ：release，Local：中文，
Build Options 里只选了 Enable eboot space in memory（IMGEBOOT = 1）
Environment 无，Custom Build Actions ：Pre-Sysgen
Subproject Image Settings 无

xiaozhou

引用 20 楼 waterdream0820 的回复:
引用 18 楼 guopeixin 的回复:
1. 有可能是驱动架构的问题，即fal里面的代码在操作slc和mlc的差异造成的
2. 如果是lz操作硬件方式不对的话，os也应该有概率的存在坏掉的情况，但是并没有出现，操作hw方式不对的可能性比较小
---------------------------------------
我觉得lz可以先验证一下问题的根源在那里
1. lz提到放置文件比较少的时候，重启盘符还在，文件没了
很可能是分区被格式化掉了，lz先在fmd的代码中打印一下开机时候被格式化的block的号，看一下这些是否在文件系统分区

2. 另外，你上面提到“还有就是当存储的东西多点之后，100兆，下次启动的时候，就没有了nandflash盘符，也就是存储部分都消失了，而东西少的
时候重启丢失数据，但是盘符还在，存储区也在。”，确认一下，发生问题的概率和文件个数的多少有关系么

1 FMD_EraseBlock 我在这个函数里面加的打印信息发现一次也没调用。拷东西进去的时候，
FMD_WriteSector里面有打印信息，而且拷进去的程序能正常使用。对这个格式化不太了解，还有其他
地方做这个操作吗?
2 东西多的时候，基本上每次都会导致盘符消失，东西少的时候偶尔会出现。不过总的做的次数也不太多3次拷贝大的都出现了，东西少的有10来次只有一次出现。

1. 从erase里面没有打印信息以及问题的概率和文件个数有关这个现象上看，
个人觉得基本上就可以肯定是fal的问题了；
2. 建议lz可以尝试更新pb到r2重新进行测试

huttu

引用 22 楼 guopeixin 的回复:
引用 20 楼 waterdream0820 的回复:
引用 18 楼 guopeixin 的回复:
1. 有可能是驱动架构的问题，即fal里面的代码在操作slc和mlc的差异造成的
2. 如果是lz操作硬件方式不对的话，os也应该有概率的存在坏掉的情况，但是并没有出现，操作hw方式不对的可能性比较小
---------------------------------------
我觉得lz可以先验证一下问题的根源在那里
1. lz提到放置文件比较少的时候，重启盘符还在，文件没了
很可能是分区被格式化掉了，lz先在fmd的代码中打印一下开机时候被格式化的block的号，看一下这些是否在文件系统分区

2. 另外，你上面提到“还有就是当存储的东西多点之后，100兆，下次启动的时候，就没有了nandflash盘符，也就是存储部分都消失了，而东西少的
时候重启丢失数据，但是盘符还在，存储区也在。”，确认一下，发生问题的概率和文件个数的多少有关系么

1 FMD_EraseBlock 我在这个函数里面加的打印信息发现一次也没调用。拷东西进去的时候，
FMD_WriteSector里面有打印信息，而且拷进去的程序能正常使用。对这个格式化不太了解，还有其他
地方做这个操作吗?
2 东西多的时候，基本上每次都会导致盘符消失，东西少的时候偶尔会出现。不过总的做的次数也不太多3次拷贝大的都出现了，东西少的有10来次只有一次出现。

1. 从erase里面没有打印信息以及问题的概率和文件个数有关这个现象上看，
个人觉得基本上就可以肯定是fal的问题了；
2. 建议lz可以尝试更新pb到r2重新进行测试

非常感谢，发现连发三次，没人回复，就没法继续回帖了，很郁闷。
不过我的用的就是r2的。。。

daniel_zhang

引用 16 楼 bearbrotherji 的回复:
CE的R2已经支持MLC了。这样吧，你把系统对SECTOR写的SECTORINFO打出来看一下，看看到底对同一个SECTOR写了几次SECTORINFO，分别写的是什么，这样就知道是不是MLC的问题的。

这个是我拷贝一个小文件打印出来的信息
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0xffffffff,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffe
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0x84dd,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffd
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0xffffffff,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffe
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0x813e,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffd
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0xffffffff,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffe
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0xc168,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffd
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0x84dd,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffd
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0xffffffff,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffe
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0x84dd,

pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffd
                                                                              
#wince### NAND_WriteSectorInfo!
##wince##pInfo->dwReserved1 = 0xffffffff,
pInfo->bOEMReserved = 0xff,
pInfo->bBadBlock = 0xff,
pInfo->wReserved2 = 0xfffe

hejizhu

引用 23 楼 waterdream0820 的回复:
引用 22 楼 guopeixin 的回复:
引用 20 楼 waterdream0820 的回复:
引用 18 楼 guopeixin 的回复:
1. 有可能是驱动架构的问题，即fal里面的代码在操作slc和mlc的差异造成的
2. 如果是lz操作硬件方式不对的话，os也应该有概率的存在坏掉的情况，但是并没有出现，操作hw方式不对的可能性比较小
---------------------------------------
我觉得lz可以先验证一下问题的根源在那里
1. lz提到放置文件比较少的时候，重启盘符还在，文件没了
很可能是分区被格式化掉了，lz先在fmd的代码中打印一下开机时候被格式化的block的号，看一下这些是否在文件系统分区

2. 另外，你上面提到“还有就是当存储的东西多点之后，100兆，下次启动的时候，就没有了nandflash盘符，也就是存储部分都消失了，而东西少的
时候重启丢失数据，但是盘符还在，存储区也在。”，确认一下，发生问题的概率和文件个数的多少有关系么

1 FMD_EraseBlock 我在这个函数里面加的打印信息发现一次也没调用。拷东西进去的时候，
FMD_WriteSector里面有打印信息，而且拷进去的程序能正常使用。对这个格式化不太了解，还有其他
地方做这个操作吗?
2 东西多的时候，基本上每次都会导致盘符消失，东西少的时候偶尔会出现。不过总的做的次数也不太多3次拷贝大的都出现了，东西少的有10来次只有一次出现。

1. 从erase里面没有打印信息以及问题的概率和文件个数有关这个现象上看，
个人觉得基本上就可以肯定是fal的问题了；
2. 建议lz可以尝试更新pb到r2重新进行测试
非常感谢，发现连发三次，没人回复，就没法继续回帖了，很郁闷。
不过我的用的就是r2的。。。

咱们换一种简单的方法来做，你在ce一下写一个测试程序，简单的写入文件和读取文件，然后进行数据比较，重复的进行测试

sheji105

引用 25 楼 guopeixin 的回复:
咱们换一种简单的方法来做，你在ce一下写一个测试程序，简单的写入文件和读取文件，然后进行数据比较，重复的进行测试

我在写操作里往文件里写了1000个数，一个一个写进去的，然后在读操作里一个一个读出来，判断是否出错。这个操作重复1000次。这样应该可以吧。

mcd511786450

引用 26 楼 waterdream0820 的回复:
引用 25 楼 guopeixin 的回复:
咱们换一种简单的方法来做，你在ce一下写一个测试程序，简单的写入文件和读取文件，然后进行数据比较，重复的进行测试
我在写操作里往文件里写了1000个数，一个一个写进去的，然后在读操作里一个一个读出来，判断是否出错。这个操作重复1000次。这样应该可以吧。

这样的操作数据量太小了
可以参照cetk测试的做法，就是简单的写入一个文件，文件的内容必须是随机的，然后读出来进行比较
这样的过程做个几个小时，至少要保证操作的总文件大小是磁盘容量了几十倍吧

zhaofei057

引用 27 楼 guopeixin 的回复:
引用 26 楼 waterdream0820 的回复:
引用 25 楼 guopeixin 的回复:
咱们换一种简单的方法来做，你在ce一下写一个测试程序，简单的写入文件和读取文件，然后进行数据比较，重复的进行测试
我在写操作里往文件里写了1000个数，一个一个写进去的，然后在读操作里一个一个读出来，判断是否出错。这个操作重复1000次。这样应该可以吧。

这样的操作数据量太小了
可以参照cetk测试的做法，就是简单的写入一个文件，文件的内容必须是随机的，然后读出来进行比较
这样的过程做个几个小时，至少要保证操作的总文件大小是磁盘容量了几十倍吧

我按前面说的测的倒是没问题，时间也有几个小时。不过用的不是随机数。
不太明白这个最后能得出什么结论呢？根据错误的多少能知道是哪部分的原因吗？可以分析出是FAL层的问题吗？目前程序在nandflash上跑是没问题的。

6604439

引用 28 楼 waterdream0820 的回复:
引用 27 楼 guopeixin 的回复:
引用 26 楼 waterdream0820 的回复:
引用 25 楼 guopeixin 的回复:
咱们换一种简单的方法来做，你在ce一下写一个测试程序，简单的写入文件和读取文件，然后进行数据比较，重复的进行测试
我在写操作里往文件里写了1000个数，一个一个写进去的，然后在读操作里一个一个读出来，判断是否出错。这个操作重复1000次。这样应该可以吧。

这样的操作数据量太小了
可以参照cetk测试的做法，就是简单的写入一个文件，文件的内容必须是随机的，然后读出来进行比较
这样的过程做个几个小时，至少要保证操作的总文件大小是磁盘容量了几十倍吧
我按前面说的测的倒是没问题，时间也有几个小时。不过用的不是随机数。
不太明白这个最后能得出什么结论呢？根据错误的多少能知道是哪部分的原因吗？可以分析出是FAL层的问题吗？目前程序在nandflash上跑是没问题的。

这样可以验证出来硬件电路板在没有频繁的上电动作的时候，你的flash driver是否健壮，换句话说，也可以来验证你的fal是否正确
之所以是使用随机数，是为了保证测试的全面性，单凭测试结果无法确定是fal的哪个地方出了问题，但是可以证明你的fal是有问题的，可能是不支持mlc引起的
这只是为了确认问题，解决问题的话还要进一步的debug

chunlei9924

引用 29 楼 guopeixin 的回复:
引用 28 楼 waterdream0820 的回复:
引用 27 楼 guopeixin 的回复:
引用 26 楼 waterdream0820 的回复:
引用 25 楼 guopeixin 的回复:
咱们换一种简单的方法来做，你在ce一下写一个测试程序，简单的写入文件和读取文件，然后进行数据比较，重复的进行测试
我在写操作里往文件里写了1000个数，一个一个写进去的，然后在读操作里一个一个读出来，判断是否出错。这个操作重复1000次。这样应该可以吧。

这样的操作数据量太小了
可以参照cetk测试的做法，就是简单的写入一个文件，文件的内容必须是随机的，然后读出来进行比较
这样的过程做个几个小时，至少要保证操作的总文件大小是磁盘容量了几十倍吧
我按前面说的测的倒是没问题，时间也有几个小时。不过用的不是随机数。
不太明白这个最后能得出什么结论呢？根据错误的多少能知道是哪部分的原因吗？可以分析出是FAL层的问题吗？目前程序在nandflash上跑是没问题的。

这样可以验证出来硬件电路板在没有频繁的上电动作的时候，你的flash driver是否健壮，换句话说，也可以来验证你的fal是否正确
之所以是使用随机数，是为了保证测试的全面性，单凭测试结果无法确定是fal的哪个地方出了问题，但是可以证明你的fal是有问题的，可能是不支持mlc引起的
这只是为了确认问题，解决问题的话还要进一步的debug

我没有等上次完成，大约进行了500多次，程序也关不掉，重启之后发现没有盘符了，必须重新格式化nandflash，这种情况就是文件系统挂掉了吧。

tigerhaha

现在按照这样的步骤做
1. 用你的应用程序测试大概500次左右的时候，关机重启，然后把fat volume的dbr打印出来；
2. 如果发现dbr和关机之前不一致则尝试找到dbr所在的block.page，并检测其在什么时候遭到破坏，这样你就可以准确知道了分区破坏的时间点和相关的操作行为
3. 接下来就好说了