佚名通过本文主要向大家介绍了wince系统8g卡补丁,工控机wince系统,扫描枪 wince,车载导航wince系统,wince开发教程等相关知识,希望对您有所帮助,也希望大家支持linkedu.com www.linkedu.com
问题： WINCE60 SD卡 唤醒后无法被识别
描述:
问题很奇怪，定位很烦琐，修改很简单！
这个问题困扰了很久，一直奇怪为什么同样的代码，同样的硬件配置，在另一个项目中是正常的，在这个项目中就是不行。不幸啊！
问题是这样的，卡一直在，系统sleep-wakeup之后，卡中的很多文件及目录都没有了。其实，不是没有了，是没有识别了，并且不是全没有，是sleep之前访问到的同级目录之后的都没有了。这个还是可以解释的，文件系统在sleep之前记住了这些目录，至少是所访问到的目录的深度。电是一直供着的，pwr-down和pwr-up对sd的驱动是没有任何操作的。照正常情况来说，在sleep期间没有拔插卡，醒来之后至少可以读写卡的，但是现在什么都不行。所以这个说来就是奇怪。查遍整个工程，也没有发现哪个针对sd的io口在别处被占用了。在wakeup的时候模拟卡的一次拔插，是可以规避解决这个问题，别的问题先不说，就一个速度问题就已经不可忍受了。不过越想越是这个问题，一定是数据口被怎么搞没了。恢复原来的代码，直接在pwr-on的时候重置了数据位的配置。好了！时间急任务重，就先这么着吧。
不过还是高兴的有点早了，在sleep期间拔出sd卡再唤醒系统，在对sd卡操作的时候竟然挂了。但是在sleep期间插入的话，是没有问题的。跟踪代码，结果一无所获。对于上面的问题，是在sdhc的驱动来通知上层unmount的时候挂了，文件系统的东西我是不太会去怀疑的。不同的音频驱动，竟然会影响sd卡唤醒后的不同。可能是注意wakeup时的串口消息注意的太多了，无意间发现了这个：ERROR: Power Handler function yield to low priority thread.救命稻草啊！
In V5.0 MS added a power down thread so that power down handlers are called on a thread instead of in the former no-thread kernel context.
The documented idea is that you can now handle synch objects in powerdown code. (There are still limits to synch objects so CloseHandle is still off limits.)
Unfortunately, they implemented this in a way that generates the error mentioned if the driver's powerdown function blocks on a thread of lower priority, which would be normal for an application that called into the driver and has acquired a lock on the synch object in question.
So the upshot is that you are supposed to be able to do synch stuff in power handlers and under light testing might even seem to work but it is virtually guaranteed to fail at some point in the future, usually well after product release. So don't do that.
先将目前的thread的priority 设置为最高，timeslice 为“永远”
调用GWES driver的power off function
调用PowerProc，会一一调用各device driver的PowerDown( )
硬件 poweroff ---- suspend，直到有人power - resume
调用PowerProc，会一一调用各device driver的PowerUp( )
调用GWES driver的Power on function
将目前的thread设回原来的TimeSlice & Priority
Device Driver 的PowerUp/Down function 就是在PowerProc( )调用的，也就是run 在priority 最高，no timeslice consume 的状态。除非该driver funciton 自行release 控制权，否则不会被task switch 掉。
这样说来就比较清楚了，是在power-up的函数中有sleep函数的调用了。还真是，在音频驱动中的。
本文出自 “bluefish” 博客，请务必保留此出处http://bluefish.blog.51cto.com/214870/474674
文字太多了
贴个关键部分吧
Sending command register 0x071B
Sending command Argument 0xB3680000
[SD ]SDHCControllerIst - Card EVENT!
HandleInterrupt (0) - Normal Interrupt_Status=0x01
CSDHCSlotBase::WaitForReg: Timeout (5000 ms) waiting for (ReadReg<2>(0x30) & 0x00000002) == 0x00000002
CSDHCSlotBase::HandleCommandComplete: Timeout waiting for NORMAL_INT_STATUS_TRX_COMPLETE
卡在这了，求大神指导一下，这个超时是怎么回事
解决方案1:
你有没有对比正常插入和异常插入的 LOG 有什么不同？
描述:
本帖最后由 lishizhao276 于 2016-07-02 16:25:09 编辑
WINCE6.0SD卡休眠和唤醒
先引用一下别人的文章:问题很奇怪，定位很烦琐，修改很简单！
这个问题困扰了很久，一直奇怪为什么同样的代码，同样的硬件配置，在另一个项目中是正常的，在这个项目中就是不行。不幸啊！
问题是这样的，卡一直在，系统sleep-wakeup之后，卡中的很多文件及目录都没有了。其实，不是没有了，是没有识别了，并且不是全没有，是sleep之前访问到的同级目录之后的都没有了。这个还是可以解释的，文件系统在sleep之前记住了这些目录，至少是所访问到的目录的深度。电是一直供着的，pwr-down和pwr-up对sd的驱动是没有任何操作的。照正常情况来说，在sleep期间没有拔插卡，醒来之后至少可以读写卡的，但是现在什么都不行。所以这个说来就是奇怪。查遍整个工程，也没有发现哪个针对sd的io口在别处被占用了。在wakeup的时候模拟卡的一次拔插，是可以规避解决这个问题，别的问题先不说，就一个速度问题就已经不可忍受了。不过越想越是这个问题，一定是数据口被怎么搞没了。恢复原来的代码，直接在pwr-on的时候重置了数据位的配置。好了！时间急任务重，就先这么着吧。
不过还是高兴的有点早了，在sleep期间拔出sd卡再唤醒系统，在对sd卡操作的时候竟然挂了。但是在sleep期间插入的话，是没有问题的。跟踪代码，结果一无所获。对于上面的问题，是在sdhc的驱动来通知上层unmount的时候挂了，文件系统的东西我是不太会去怀疑的。不同的音频驱动，竟然会影响sd卡唤醒后的不同。可能是注意wakeup时的串口消息注意的太多了，无意间发现了这个：ERROR: Power Handler function yield to low priority thread.救命稻草啊！
In V5.0 MS added a power down thread so that power down handlers are called on a thread instead of in the former no-thread kernel context.
The documented idea is that you can now handle synch objects in powerdown code. (There are still limits to synch objects so CloseHandle is still off limits.)
Unfortunately, they implemented this in a way that generates the error mentioned if the driver's powerdown function blocks on a thread of lower priority, which would be normal for an application that called into the driver and has acquired a lock on the synch object in question.
So the upshot is that you are supposed to be able to do synch stuff in power handlers and under light testing might even seem to work but it is virtually guaranteed to fail at some point in the future, usually well after product release. So don't do that.
先将目前的thread的priority 设置为最高，timeslice 为“永远”
调用GWES driver的power off function
调用PowerProc，会一一调用各device driver的PowerDown( )
硬件 poweroff ---- suspend，直到有人power - resume
调用PowerProc，会一一调用各device driver的PowerUp( )
调用GWES driver的Power on function
将目前的thread设回原来的TimeSlice & Priority
Device Driver 的PowerUp/Down function 就是在PowerProc( )调用的，也就是run 在priority 最高，no timeslice consume 的状态。除非该driver funciton 自行release 控制权，否则不会被task switch 掉。
这样说来就比较清楚了，是在power-up的函数中有sleep函数的调用了。还真是，在音频驱动中的。
本文出自 “bluefish” 博客，请务必保留此出处http://bluefish.blog.51cto.com/214870/474674
文字太多了
贴个关键部分吧
Sending command register 0x071B
Sending command Argument 0xB3680000
[SD ]SDHCControllerIst - Card EVENT!
HandleInterrupt (0) - Normal Interrupt_Status=0x01
CSDHCSlotBase::WaitForReg: Timeout (5000 ms) waiting for (ReadReg<2>(0x30) & 0x00000002) == 0x00000002
CSDHCSlotBase::HandleCommandComplete: Timeout waiting for NORMAL_INT_STATUS_TRX_COMPLETE
卡在这了，求大神指导一下，这个超时是怎么回事
解决方案1:
你有没有对比正常插入和异常插入的 LOG 有什么不同？