项目中发现的SD卡部分的Bug

http://blog.csdn.net/gsymichael/article/details/3871622

最近项目中SD卡驱动出了些很奇怪的问题，客户那边的Map有个特点，在运行的过程中会始终维护文件系统的Handle，如果发现Handle出现错误那么就会提示说SD卡存在问题。而在驱动中在插，拔卡的时候都会发相关的消息给Map。在前面遇到说没有拔卡，而只是在系统经过Suspend/Resume之后，突然出现SD卡找不到的对话框提示。开始的时候经过简单的调试，发现实际卡是可以使用的，只是说在系统Suspend/Resume之后有了一次Unmount，Mount的动作导致文件系统重新加载了，这样之前的文件系统Handle自然就不存在了那么就自然会出现这个问题了。接下来分析什么情况会导致出现Unmount，Mount的动作。由于我们是需要支持文件续传的，那么自然文件系统的Handle也是需要保留的。能够导致文件系统重新加载要么是PnpDelayTimeOut的时间到了，要么是在Suspend的时候换卡了，导致后续判断卡的ID时出现错误从而重新给新的卡加载新的文件系统。

  根据上面的分析判断，在操作过程中没有换过卡，那么后一种情况不会发生了。那么一定是前一种情况了，那么在驱动部分和存储管理部分加入Celog信息去捕捉需要的信息，结果发现了一个情况：一只AP在系统启动的过程中去读取SD卡，而此时SD卡是不能够操作的，自然会导致读取出现Error。因为要支持续传，在系统Resume之后，驱动部分会去做拔卡然后插卡的动作，目的是让卡重新走一遍初始化过程（这里是卡的初始化，而不是SD Controller的初始化），那么在做了拔卡的动作后到Unload SDMemory之前对于文件系统来讲，SD卡这个设备是可以操作的(电源管理部分置为PowerOn)。等到Unload SDMemory之后，文件系统部分会把SD卡的文件系统的结构标记上Detached的flag，那么这时透过文件系统对SD卡的操作会被文件系统部分给保护起来（实际在这里发现flag为不能操作，那么会去Sleep一小段时间），仔细想下这部分的确是缺少保护，不过一般情况下AP的优先级达不到那么高，所以一般不会出问题。其实在这里可以在存储管理部分的Notify函数中去判断，如果是SD卡的文件系统，那么可以先把Flag置为Detached，之后置POWERON，随后在重新加载成功之后这个Detached标志会置~Detached。不过后来发现问题并不是由这里引起的。

  在后面的调试过程中发现，在过了800ms左右卡就被Unmount掉了，根本离Delaytime还早。那么只有后一种情况了，加入调试信息看果然是在读取StorageId的时候比较两次的Id不同导致的。但是对于同一张卡，Id怎么会不同？仔细看了Sdmemmain部分的代码发现在读取Id时候有问题，在最后的12个字节填充ID的时候，实际前10个Byte填进了Id，第11个Byte填字符串结束符'/0',而第12个Byte没受代码控制。那么这第12个Byte的值就随机了，根据申请到内存时上面的值决定，这样就会导致使用memcmp来比较时会出现错误。后来检查了存储管理部分，发现在这部分也没有做初始化动作，所以就导致了这个问题的产生。