how to erase flash?

Sep 25, 2006 8 Replies

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


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.

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.

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

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

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 ?

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

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?

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?

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required