EMIF16 to Strata P30 NOR flash problem

Please provide a diagram showing how the EMIF16 is connected to the FLASH and the values you are writing to the EMIF16 configuration registers. Have you captured a bus access that is returning a bad value using a logic analyzer? You stated that the flash begins to work after you've issued a reset. When the EMIF16 is reset it will return the default values to the EMIF16 configuration registers which will increase the length of your access.  Have you tried adding some addition delay cycles to your read strobe to see if that improves your performance?

Regards, Bill

Thanks for reply.

Bill Taboada said:

and the values you are writing to the EMIF16 configuration registers

Out EMIF16 configuration is: 

Async 1 Config Register (A1CR) = 0x3FFFFFFD
Page Mode Control Register (PMCR) = 0xFDFDFDFD
Async Wait Cycle Config Register (AWCCR) = 0xF0000080
*(unsigned int*)0x20C00008 |= 0x80000000;

Bill Taboada said:

Please provide a diagram showing how the EMIF16 is connected to the FLASH

Connections Strata Flash to EMIF16:
EMIF16 FLASH
EMIFD[15:0] <=> DQ[15:0]
EMIFA[22:0] <=> A[23:1]
EMIFA[23] <=> A[0]
EMIFCE0 <=> CE
EMIFOE <=> OE
EMIFWE <=> WE
EMIFWAIT0 <=> WAIT

Bill Taboada said:

Have you captured a bus access that is returning a bad value using a logic analyzer?

Unfortunately the most of nets are routed on internal layers and we can't analyze data bus.

Bill Taboada said:

You stated that the flash begins to work after you've issued a reset. When the EMIF16 is reset it will return the default values to the EMIF16 configuration registers

After the reset EMIF16 is configured again (configuration function  is called every time when I start my program).

Bill Taboada said:

Have you tried adding some addition delay cycles to your read strobe to see if that improves your performance?

All timings are already the slowest.

I don't see any problems with your configuration or you connections to the EMIF interface. Can you provide details on the connections of the other pins on the flash such as WP, ADV# and RST#? When the interface fails you stated that the data input was 0xFFFF. Do all accesses return 0xFFFF until the system is reset or does a repeated read get a different value?  When it is the failure state can you probe the CS to see if the external accesses are occurring at all?

WP is pulled up over 4.7k resistor to 1.8V;

ADV# is pulled low over 4.7k resistor to gnd;

RST# is directly connected to 1.8V.

Bill Taboada said:

Do all accesses return 0xFFFF until the system is reset or does a repeated read get a different value?

When I turned on "Continuous Refresh" mode in memory browser to observe emif16 memory space, 0xFFFF was appeared spontaneous at different addresses.

Bill Taboada said:

When it is the failure state can you probe the CS to see if the external accesses are occurring at all?

I will try to catch this.

 P.S. When in our project C6678's resets (RESETFULL and POR) were implemented over RC-chains directly connected to RESETFULL and POR, we also had problems with flash writes (0xFFFF was returned instead of 0x0080 (ready status) even after System Reset over JTAG). After that we implemented resets over schmitt triggers. Now we don't have problems with flash writes.  Definitely there is dependency from C6678's resets. 

I'm confused by your reference to RC-chains connected to RESETFULL and POR.  Can you provide your reset control circuit for the C6678?

hello  Vladimir,

may I ask you how did you configure A1CR? I wanna connect dsp with an external FPGA. and I have no idea about how to set those cycles. 

hope you can respond me. thanks in advance.