FLASH Reset

I'm using an ST FLASH, M29W800, which appears to be equivalent to the AMD Am29L800. I've tied the reset line directly to 3 volts. I can't get the device to work, checked all the signals with a cro. The only thing that I can think of at the moment is that the reset line should have been tied to the system reset. Will it work okay tied directly to 3 volts?

Dan

Reply to
Dan
Loading thread data ...

I get a feeling you should use a current limiting resistor. It seems to be a general rule for tying signals high. Do you really want blocks to be unprotected all the time?

Reply to
Gary Kato

What do you mean with: 'can't get to work'? -does the chip return anything on a read? -does the chip identification respond? -did you notice that in 8 bit mode the addresses start at A-1?

I have usually started with new Flash chips by first making the chip identification work. Double check your connections to the address and data lines, and your code for key codes and locations.

My feeling is that the reset line has nothing to do with your problem. It does not change the sector protection as long as it's at normal logic levels. A Flash chip starts up in read mode even without the reset line, so you should not need it.

HTH

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

As Tauno said what do you mean by "it doesn't work"?

- Can't read at all? - Can't get ID bytes?

How cleanly does your 3V3 line rise? If you have a slow rise time or erratic Vcc then you may find problems with the flash (as you are then providing a bad reset signal). Generally it _should_ work tied to Vcc but I prefer to go to reset as, in the past, I have found that the "unclean reset" can cause strange faults (bytes written, etc.). It rather depends on how the other lines flap about while the power is coming up.

Andrew

Reply to
Andrew Jackson

Thanks for the replies. When I said it didn't work, I meant that I couldn't do anything with it, except to read 0xffff. I thought that maybe it needed a proper reset. But I've got it basically working now; software, not hardware. Thanks for the suggestions.

Dan

Reply to
Dan

Somewhat ironically, this is where I started, this is where I spent the most time, and this is the only bit that I can't get to work.

Dan

Reply to
Dan

Do you mean that you can read, erase and program the chip?

If so, please describe the sequence used for identification.

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

Yes.

int16u *Q, *R, *Y;

// Point to memory locations for query string. Q = ( int16u *)0x400020; R = ( int16u *)0x400022; Y = ( int16u *)0x400024;

*( int16u *)( base + 0xaa ) = 0x98; // Put into cfi query mode. ( base = 0x400000, the offset for the Hitachi processor.)

sprintf( sprintf_buff, "\r\n %x %x %x ", *Q, *R, *Y);

Should print 0x51, 0x52, 0x59 ( 'Q', 'R', 'Y' ), but get all as

0xffff.

Dan

Reply to
Dan

Does the order of the requests matter (i.e. do you have to read Q, then R, then Y? If it matters, remember that C passes arguments right to left, which means that Y gets read, then R, then Q in your code.

I don't know if that matters in your case, but I have been burned by that before...

--Keith Brafford

Reply to
Keith Brafford

IIRC, there should be the standard unlock sequence before the command.

The ID bytes are separately readable in whatever order needed. The chip must be reset back to the read state after identifying with the reset command.

HTH

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

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.