【原创】由于flash CRE产生的死机问题

硬件：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);