AnsweredAssumed Answered

Problems when drive micron JS28F640J3F75 with ADSP BF537

Question asked by Heizenberg on Dec 27, 2011
Latest reply on Jan 16, 2012 by CraigG

Has anybody used bf537 to drive micron parallel nor flash J3 65nm-- JS28F640J3F75A ?

I have problems during porting u-boot 1.1.6 on this flash. The uboot is from the blackfin.uclinux.org.

 

I have a board which is designed refer to bf537-stamp board,  whose parallel flash is JS28F640J3F75 rather than the ST one.

Information about JS28F640J3F75A can refer to http://www.micron.com/products/nor-flash/parallel-nor-flash/parallel-nor-flash-embedded-part-catalog .

The paralell flash is 8M bytes, every blk size is 128kbytes, but bf537 can only use half of them.

It is cfi compitable, which obeys the intel cmdset, and it works in x16 mode.

As described by datasheet,  all status can be indicated by flash status register,

like ReadyStatus/ Erase Suspend/Erase Error/ProgramError/Program&Erase Voltage Error....

 

JS28F640J3F75 is connected to ebiu of bf537-v0.3, and controlled by AMC.

The bf537 works on clkin = 25MHz, vco_multi=20, cclk=500Mhz, sclk=100Mhz,

AMGCTL=FF, AMBCTL0/1 = 0xFFC2FFC2, which means enable clkout at freq sclk=100Mhz,

read 15cycles, write 15cycles, setup=3, hold=4, transition=4 cycles.

Rd impuls = 15*1s/100Mhz = 150ns>75ns, transition = 4*10ns = 40ns>35ns, which means timing character suffices parallel flash AC character.

 

When I porting this one onto my own board, I have to modify flash diver file 'flash.c' under the uboot1.1.6/board/bf537-stamp/.

(The cfi driver can't work properly.Even the latest uboot 2010 R3-R5).

 

I followed instruction of norflash datasheet and software driver in C download from the micron official website.

However, hardware does not work as it's described, StatusRegister state can not imply practice states of norflash.

 

For instance, I wanna erase former 31 blks one by one, and called this func 31times.

Of cource no blk is locked, or any hardware problems.

 

flash base addr = 0x20000000, blocksize = 0x20000,

flash cmds:

0xFF reset/read array mode;

0x20 erase a blk, setup cmd;

0xd0 blk erase  confirm;

0x50 clear status register;

 

int erase_blk(int blknum)

{

  volatile ushort *blk_base_addr;

 

   blk_base_addr = (volatile ushort *)ALIGN_ADDRESS( BASE_ADDR + blknum*FLASH_BLOCK_SIZE); //get block base addr, x16 addr align.
  *blk_base_addr = CMD_ERASE_SETUP; /* erase cmd 0x0020 */
  *blk_base_addr = CMD_ERASE_CONFIRM;/* erase confirm  0x00d0*/

  first=(*blk_base_addr);/* read sr as soon as cmds sent. */

  do // wait here until sr.7=1
  {
    read = (*blk_base_addr); /* read sr during, read will save sr value when jump out the loop. */        
    if( (read&0xff00)||(!read) )
       state = 0;
   else if( (0x0080&read)== 0x0080 ) // sr.7 readystatus bit =1
     state = 1;

  }while( ! state ); 
 
last = *blk_base_addr;  // read status register after sr.7 ReadyStatus=1

if( (read)!=0x0080)
{
  rtval = 1;
  printf("sr=%x|%x|%x ",first,read ,last);// show status register during operations.
  printf("Erase Fail! ");
}
else
{
  rtval = 0;
  printf("sr=%x|%x|%x ",first,read,last);

  printf("(OK)%d",blknum);
}

 

*blk_base_addr = CMD_READ_ARRAY;

return rtval;

}

 

response from uart port is shown :

sr=d0|80|80 (OK)0
sr=d0|80|80 (OK)1
sr=d0|80|80 (OK)2
sr=d0|80|80 (OK)3
sr=d0|80|80 (OK)4
sr=d0|80|80 (OK)5
sr=d0|80|80 (OK)6
sr=d0|80|80 (OK)7
sr=d0|80|80 (OK)8
sr=d0|80|80 (OK)9
sr=d0|80|80 (OK)10
sr=d0|80|80 (OK)11
sr=d0|80|80 (OK)12
sr=d0|80|80 (OK)13
sr=d0|80|80 (OK)14
sr=d0|80|80 (OK)15
sr=d0|80|80 (OK)16
sr=d0|80|80 (OK)17
sr=d0|80|80 (OK)18
sr=d0|80|80 (OK)19
sr=d0|80|80 (OK)20
sr=d0|80|80 (OK)21
sr=d0|80|80 (OK)22
sr=d0|80|80 (OK)23
sr=d0|80|80 (OK)24
sr=d0|80|80 (OK)25
sr=d0|80|80 (OK)26
sr=d0|80|80 (OK)27
sr=d0|80|80 (OK)28
sr=d0|80|80 (OK)29
sr=d0|80|80 (OK)30
sr=d0|80|80 (OK)31
done.

 

which means erase operation succeed on 31blks.

However, when I use 'md' cmd of uboot to shown content, not all blks are 0xffff.

only a few blks are erase actually. If we used udelay() to wait 4s in the do-while loop, all blks are clean.

 

It seems that bf537 works too fast, flash can not response properly. Is it really too FAST?

I used to bypass pll and use sclk downto 25Mhz(tooo slowly), this phenomena still exits.

 

This problem torture me a lot.

Micron does not have branch in the local erea, I can't get tech support from micron.

Therefore I ask a favor here, and really,really appreciate it.

Outcomes