[U-Boot-Users] CFI flash driver problem

[U-Boot-Users] CFI flash driver problem

[Jeff Mann]

U-Boot users:
 
I am having a problem using the CFI flash drivers on a new board and
would appreciate any suggestions to find my mistakes. (Wolfgang: this is
the AMCC Acadia board that is on its way to you). The processor is a
PPC405ez. 

When writing or erasing the flash, the processor has an Program Check
Exception. Below you can see the exeption handling data I receive when
trying to erase a sector on flash:
 
NIP: 00000700 XER: 00000000 LR: 03FDC27C REGS: 03f6a9a0 TRAP: 0700 DAR:
03FD0014
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
 
GPR00: 00000000 03F6AA90 FFFFFFFF 03FFD1A8 00000030 03F6AAA0 00000030
BE59D81C
GPR08: 00000000 FF000000 03F6AAA5 00000005 574FBDE6 FFFFFFFF 03FF9800
0400D000
GPR16: FFFFFFFF FFFFFFFF DFFFFFFD 03F6ABAA 00000001 00000000 00000000
00000000
GPR24: 00000000 0000007F 03FFD9F4 03FFD1A8 03FFD1A8 03F6AF4C 03FF9E9C
00000040
** Illegal Instruction **
Call backtrace:
Program Check Exception

I have debugged the error, and when stepping through code in "human
time," I do not get this exeption. So, I put in in some basic debugging
printouts and I can see that the problem occuring some place in the
flash_write_cmd() function when calling it with "flash_write_cmd (info,
sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in flash_erase(). 

I've added wait states to the flash chip select with no change. Because
the flash shares the EBC bus with memory through a bus transiever, I
thought that possibly there were problems with the transiever's timing.
But after adding the maximum number of wait states, I do not think this
is the case. 

Thanks for you help,
JM

[U-Boot-Users] CFI flash driver problem

[Tolunay Orkun]

Jeff Mann wrote:
> U-Boot users:
>  
> I have debugged the error, and when stepping through code in "human
> time," I do not get this exeption. So, I put in in some basic debugging
> printouts and I can see that the problem occuring some place in the
> flash_write_cmd() function when calling it with "flash_write_cmd (info,
> sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in flash_erase(). 
>   
Did you update to the latest driver from git. If not please try and 
report back..

Best regards,
Tolunay

[U-Boot-Users] CFI flash driver problem

[Jeff Mann]

>Did you update to the latest driver from git. If not please try and
report back..

Of course. I've learned my lesson before :) In any case, cfi_flash.c has
not changed since 2006-11-13. 

The "Illegal Instruction" exeption really makes me suspecious of an
access timing problem.

Thanks,
JM

[U-Boot-Users] CFI flash driver problem

[Wolfgang Denk]

In message <1628E43D99629C46988BE46087A3FBB98BAB33@ep-01.EmbeddedPlanet.local> you wrote:
> >Did you update to the latest driver from git. If not please try and
> report back..
> 
> Of course. I've learned my lesson before :) In any case, cfi_flash.c has
> not changed since 2006-11-13. 

You must be missing something, i. e. at least the following commits:

Commit: 3a197b2fe49d6fa03978e60af2394efe9c70b527 
Author: Haiying Wang <Haiying.Wang@freescale.com> Wed, 21 Feb 2007 16:52:31 +0100 

    [PATCH v3] Add sync to ensure flash_write_cmd is fully finished
    
    Some CPUs like PPC, BLACKFIN need sync() to ensure cfi flash write command
    is fully finished. The sync() is defined in each CPU's io.h file. For
    those CPUs which do not need sync for now, a dummy sync() is defined in
    their io.h as well.
    
    Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>

plus 5 or 6 more commits that affect drivers/cfi_flash.c

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Life and death are seldom logical."
"But attaining a desired goal always is."
	-- McCoy and Spock, "The Galileo Seven", stardate 2821.7

[U-Boot-Users] CFI flash driver problem

[Jeff Mann]

>  
> I have debugged the error, and when stepping through code in "human 
> time," I do not get this exeption. So, I put in in some basic 
> debugging printouts and I can see that the problem occuring some place

> in the
> flash_write_cmd() function when calling it with "flash_write_cmd 
> (info, sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in
flash_erase().
>   

UPDATE:

I am proving this update in case someone searches the list archives to
solve a similar problem. 

The problem was the result of both NOR Flash and Cellular RAM driving
the EBC_READY signal (also called CRAM_WT, and WAIT in the CRAM
documents). Because of this configuration, after doing an operation on
the Flash that requires a delay, such as erase or write, the Flash held
EBC_READY low for a long time while erading or writing. So the processor
never saw the CRAM release CRAM_WT when its data was ready. The
processor never could retrieve the next instruction and intrepreted this
as an "illegal instruction."

The problem had nothing to do with bus transievers or accessing timing. 

In "human time" the erase cycle completed before I made the next step in
code. 

-Jeffrey Mann

[U-Boot-Users] CFI flash driver problem

[Tolunay Orkun]

Jeff Mann wrote:

>> flash_write_cmd() function when calling it with "flash_write_cmd 
>> (info, sect, 0, AMD_CMD_ERASE_SECTOR);" at around line 490 in
>>     
> flash_erase().
>   
>>   
>>     
>
> UPDATE:
>
> I am proving this update in case someone searches the list archives to
> solve a similar problem. 
>
> The problem was the result of both NOR Flash and Cellular RAM driving
> the EBC_READY signal (also called CRAM_WT, and WAIT in the CRAM
> documents). Because of this configuration, after doing an operation on
> the Flash that requires a delay, such as erase or write, the Flash held
> EBC_READY low for a long time while erading or writing. So the processor
> never saw the CRAM release CRAM_WT when its data was ready. The
> processor never could retrieve the next instruction and intrepreted this
> as an "illegal instruction."
>
> The problem had nothing to do with bus transievers or accessing timing. 
>
> In "human time" the erase cycle completed before I made the next step in
> code. 
>
> -Jeffrey Mann
Jeff,

Thank you for the update. Did you make changes to your board design to 
solve this problem?

One solution would be to disconnect nor flash from EBC_READY and 
configure that CS for appropriate number of wait cycles. Another would 
be to disable bus timeout if possible.

Tolunay