how to erase flash?

I have tryed to erase flash am29lv040b,but get no process. what should the matter to be? here is my main() and MHS file?

//==================================================== #include "xparameters.h" #include "xcache_l.h" #include "stdio.h" #include "xutil.h" //==================================================== int main (void) {

long int i=0; int j=0; char*cmdAddr= (char*)XPAR_GENERIC_EXTERNAL_MEMORY_MEM0_BASEADDR; XCache_EnableICache(0x80000000); XCache_EnableDCache(0x80000000); print("-- Entering main() --\r\n"); xil_printf("enter erase\n "); { cmdAddr[0x555] = 0xaa; cmdAddr[0x2aa] = 0x55; cmdAddr[0x555] = 0x80; cmdAddr[0x555] = 0xaa; cmdAddr[0x2aa] = 0x55; cmdAddr[0x555] = 0x10; xil_printf("%08x \n",cmdAddr); for(i=0;i

Reply to
xtmtd
Loading thread data ...

Try declaring the cmdAddr variable as 'volatile char *'. Otherwise. your compiler may optimize away the multiple assignments to the cmdAddr[], and only keep the last two.

Also, I would recommend not busy waiting in simple loop, but use the data polling mechanism supported by the flash to time the end of the erase cycle.

Reply to
Arlet

Does the above line imply that data references are cached? If so, your programing commands may not even reach the Flash.

cmdAddr was not declared as volatile, and even if it was, for some compilers you must apply some tricks to prevent optimizing the above sequence int writing the last value to the destination.

Reply to
Bernard

I have modifyed the cmdAddr[] as volatile,but it seems not work,how t "prevent optimizing the above

Reply to
xtmtd

Check the assembler output of the compiler to verify that optimisation is [not] the problem.

Use a CRO (you could probably get away with A0 and WE) or better yet a Logic Analyser on the flash chip pins to see if all 6 writes are being sent to the flash, or if caching (you never did answer that question) is the culprit.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266
Reply to
Mark McDougall

destination."

Like other posters have suggested:

  1. Look at assembly output to verify all the writes are still present.
  2. Make sure memory area is not cached.
  3. Use scope/logic analyzer to verify the accesses.

Also, you may want to start with reading the ID bytes first, instead of doing an erase, to make sure the magic sequence is working.

By the way, can you read the flash normally ?

Reply to
Arlet

If this is a new prototype board rather than a stock or eval board, then I suggest that you double check the hardware design.

We recently had a prototype board where an error in the schematic library part for the flash caused the data bus to the flash to be wired incorrectly. The result was days of head-scratching.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

to

the destination."

yes, I can read the flash correctly. and there is no cache . when using the logic analyzer to analysis the WE, it is none. Looking at the assembly output, the command has not been writed into the register,but why?

Reply to
xtmtd

does it have any matter the emc port connected? in the MHS, I declare PORT fpga_0_Generic_External_Memory_Mem_A_pin = fpga_0_Generic_External_Memory_Mem_A, DIR = O, VEC = [0:31] but in the UCF, I only use the VEC 13-31 port,which connect the V2Pr and EMC,will it the reason? meanwhile,when i have modifyid VEC = [0:31 to 13--31 or 0-18, I can not read from flash correctly, that is onl costain the 13-31 in the ucf that i can read flash rightly.why?

Reply to
xtmtd

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.