您的位置:首页 > 其它

【原创】由于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);
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐