【原创】由于flash CRE产生的死机问题
2009-07-12 01:36
260 查看
硬件:QSC6010+spansion S71WS256PD0HH3SR(配置为256M nor +128M psram)
软件:BREW3.1
FLASH空间分配: BOOT 0x0000--0xFFFF
AMSS 0x10000 -- 0xFFFFFF
EFS 0x1000000--0x1FDFFFF
------------------------------------------BUG的开始------------------------------------------------------------------------------------
在项目启动的时候发现系统一运行就马上跑飞,用TRACE32设置断点跟踪,发现BOOT运行正常,可以跳转到AMSS的入口地址(0X10000),所以问题是出在AMSS。进一步跟踪发现,AMSS在调用boot_configure_psram_to_burst来配置psram进入burst模式的时候,PSRAM就“挂”了----正常情况下TARCE32可以直接读写某个地址的PSRAM,而这个时候读写失败。 由于PSRAM已经不能正常读写,导致之后的boot_ram_test失败,系统不能正常运行。
boot_configure_psram_to_burst的代码如下:
HWIO_OUT(UXMC_PSRAM_CRE_CFG, 0x0);
gpio_out(GPIO_OUT_22,GPIO_HIGH_VALUE);
outpw(0x10102206,0);
gpio_out(GPIO_OUT_22,GPIO_LOW_VALUE);
HWIO_OUTI(EBI1_CSn_CFG0, ebi1_cs, ebi1_cfg0_val);
HWIO_OUTI(EBI1_CSn_CFG1, ebi1_cs, ebi1_cfg1_val);
问题就出在我们的硬件上用GPIO22用于连接MCP psram的CRE信号,当这个信号为高电平时,允许对psram的寄存器进行读写;为低电平时,允许访问ram空间。而我们的BOOT,AMSS的代码都会调用boot_configure_psram_to_burst这个函数,AMSS第二次调用这个函数的时候,又一次拉高了GPIO22,就导致了PSRAM访问失败,把AMSS中调用这个函数的地方屏蔽掉,系统就正常运行了。
--------------------------------------------BUG的威力------------------------------------------------------------------------------
由于项目的进度比较赶,没有去深究这个问题,但是后续的开发过程中就碰到了一系列莫名其妙的死机问题:
1. 用QPST连接手机,拷贝较大文件,拷贝的过程中随机的死机。
2.CAMERA连续拍摄几张高分辨率的图像后死机
3.系统进入SLEEP后唤醒,按任意键随机死机
4.。。。等等
--------------------------------------------BUG的解决------------------------------------------------------------------------------
在用DEBUG无果的情况下,又把目标指向最早的这个CRE问题。抱着试试看的心理,根据高通的参考设置,我们就把GPIO22改成了地址线的最高位EBI1_A24,相应的boot_configure_psram_to_burst的代码也改成:
HWIO_OUT(UXMC_PSRAM_CRE_CFG, 0x3);
outpw(0x10102206,0);
HWIO_OUT(UXMC_PSRAM_CRE_CFG, 0x2);
HWIO_OUTI(EBI1_CSn_CFG0, ebi1_cs, ebi1_cfg0_val);
HWIO_OUTI(EBI1_CSn_CFG1, ebi1_cs, ebi1_cfg1_val);
这样修改之后,死机问题基本上都解决。
--------------------------------------------后记------------------------------------------------------------------------------------
在解决BUG之后,就开始查找产生BUG的原因。自然而然就怀疑GPIO22是不是在系统运行的过程中有被拉高,但是用示波器查看,GPIO22一直是保持低电平。 提SR,高通反馈的结论是GPIO22确是可以作为CRE信号使用。而且用同样的代码在另外一个采用
S98WS512PD0FW0040(配置实际使用为256Mb+128Mbs )的项目上也是运行正常的。所以,到现在我还是没弄明白这个产生这个BUG的最终原因,
难道是因为不同的FLASH在对CRE信号时序上的要求不同而造成的??
PS: 由于硬件已经确定,如果采用修改硬件的方式解决死机问题会非常的麻烦。所以在参考spansion的规格书以后,决定软件上不对CRE信号进行操作,而是采用software sequence的方式来配置psram busrt mode:
inpw(0x10FFFFFE);
inpw(0x10FFFFFE);
outpw(0x10FFFFFE,1);
outpw(0x10FFFFFE,0x1103);
软件:BREW3.1
FLASH空间分配: BOOT 0x0000--0xFFFF
AMSS 0x10000 -- 0xFFFFFF
EFS 0x1000000--0x1FDFFFF
------------------------------------------BUG的开始------------------------------------------------------------------------------------
在项目启动的时候发现系统一运行就马上跑飞,用TRACE32设置断点跟踪,发现BOOT运行正常,可以跳转到AMSS的入口地址(0X10000),所以问题是出在AMSS。进一步跟踪发现,AMSS在调用boot_configure_psram_to_burst来配置psram进入burst模式的时候,PSRAM就“挂”了----正常情况下TARCE32可以直接读写某个地址的PSRAM,而这个时候读写失败。 由于PSRAM已经不能正常读写,导致之后的boot_ram_test失败,系统不能正常运行。
boot_configure_psram_to_burst的代码如下:
HWIO_OUT(UXMC_PSRAM_CRE_CFG, 0x0);
gpio_out(GPIO_OUT_22,GPIO_HIGH_VALUE);
outpw(0x10102206,0);
gpio_out(GPIO_OUT_22,GPIO_LOW_VALUE);
HWIO_OUTI(EBI1_CSn_CFG0, ebi1_cs, ebi1_cfg0_val);
HWIO_OUTI(EBI1_CSn_CFG1, ebi1_cs, ebi1_cfg1_val);
问题就出在我们的硬件上用GPIO22用于连接MCP psram的CRE信号,当这个信号为高电平时,允许对psram的寄存器进行读写;为低电平时,允许访问ram空间。而我们的BOOT,AMSS的代码都会调用boot_configure_psram_to_burst这个函数,AMSS第二次调用这个函数的时候,又一次拉高了GPIO22,就导致了PSRAM访问失败,把AMSS中调用这个函数的地方屏蔽掉,系统就正常运行了。
--------------------------------------------BUG的威力------------------------------------------------------------------------------
由于项目的进度比较赶,没有去深究这个问题,但是后续的开发过程中就碰到了一系列莫名其妙的死机问题:
1. 用QPST连接手机,拷贝较大文件,拷贝的过程中随机的死机。
2.CAMERA连续拍摄几张高分辨率的图像后死机
3.系统进入SLEEP后唤醒,按任意键随机死机
4.。。。等等
--------------------------------------------BUG的解决------------------------------------------------------------------------------
在用DEBUG无果的情况下,又把目标指向最早的这个CRE问题。抱着试试看的心理,根据高通的参考设置,我们就把GPIO22改成了地址线的最高位EBI1_A24,相应的boot_configure_psram_to_burst的代码也改成:
HWIO_OUT(UXMC_PSRAM_CRE_CFG, 0x3);
outpw(0x10102206,0);
HWIO_OUT(UXMC_PSRAM_CRE_CFG, 0x2);
HWIO_OUTI(EBI1_CSn_CFG0, ebi1_cs, ebi1_cfg0_val);
HWIO_OUTI(EBI1_CSn_CFG1, ebi1_cs, ebi1_cfg1_val);
这样修改之后,死机问题基本上都解决。
--------------------------------------------后记------------------------------------------------------------------------------------
在解决BUG之后,就开始查找产生BUG的原因。自然而然就怀疑GPIO22是不是在系统运行的过程中有被拉高,但是用示波器查看,GPIO22一直是保持低电平。 提SR,高通反馈的结论是GPIO22确是可以作为CRE信号使用。而且用同样的代码在另外一个采用
S98WS512PD0FW0040(配置实际使用为256Mb+128Mbs )的项目上也是运行正常的。所以,到现在我还是没弄明白这个产生这个BUG的最终原因,
难道是因为不同的FLASH在对CRE信号时序上的要求不同而造成的??
PS: 由于硬件已经确定,如果采用修改硬件的方式解决死机问题会非常的麻烦。所以在参考spansion的规格书以后,决定软件上不对CRE信号进行操作,而是采用software sequence的方式来配置psram busrt mode:
inpw(0x10FFFFFE);
inpw(0x10FFFFFE);
outpw(0x10FFFFFE,1);
outpw(0x10FFFFFE,0x1103);
相关文章推荐
- 20061023个人技术日志(mssql链接服务器链接到oracle,由于数据长度不定产生的问题)
- 【原创】再次强调MLC Nandflash 6410 开发板的不稳定性带来的安全隐患问题
- 解决firefox打开flash死机的问题
- 20061023个人技术日志(mssql链接服务器链接到oracle,由于数据长度不定产生的问题)
- xcode5 asset catalogs 由于图标尺寸错误导致编译问题解决[原创]
- WINDOWS 2003和IIS 6.0由于安全性增强而可能产生的问题
- 由于gcc检查过严产生的Open函数通不过问题
- 由于Adobe Flash Player 版本问题引起的播放swf文件到一半卡住的问题
- Linux环境下段错误的产生原因及调试方法小结 最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多、花费时间最长的问题就是
- 一个由于springboot自动配置所产生的问题的解决
- flash 由于此SWF不包含ActionScript问题的解决
- display:inline-block 元素之间由于换行所产生的间距问题
- spring2.5 注解依赖注入由于jdk1.8产生的问题
- [原创]用windows7连接windows2003的终端服务器时,出现"由于这台计算机没有远程桌面客户端访问许可证,远程会话被中断"的问题
- WINDOWS 2003和IIS 6.0由于安全性增强而可能产生的问题
- flash+webservice 乱码问题解决一例(原创)
- 转载+原创 使用记事本以及sqlyog编辑文件产生的文件编码格式问题
- 用dwz时, 由于粗心产生的一些问题(记录方便自己查阅)
- 2012年6月18日技术总结(由于初参与工作,很多地方的解决方案仍需完善,记录一些简单的问题)
- Java内存管理第三篇 - 内存可能产生的问题