1. Home
  2. Embedded Programming
  3. Question about strange flash problem

Question about strange flash problem

Hi all,

I'm seeing a strange bug with a flash chip. So far it's isolated but I was wondering if anyone has opinions about what might be happening here:

Chip: Spansion 32MBit

formatting link

When I program certain sectors (3f8000,3fa000,3fc000,3fe000) they act like RAM. I can write data and read data back but when I power cycle the device the data is back to 0xFFFF...

I can think of a few explanations but I don't know enough about the inner workings of flash to know which ones to eliminate:

1) The chip is defective and acts like a RAM chip on those sectors 2) The sectors in question are write-protected and act therefore act like RAM 3) There's a defect on our PCB and I actually am writing to the SRAM chip sharing the address bus 4) There's a defect on the chip that causes the sectors to be erased each time the device powers up

Some background:

- It's an FPGA based system with flash and SRAM sharing the bus.

- We don't have any high voltages hooked up to the flash chip so our only way of programming are the in-system CFI routines.

- The programming routines include a normal SRAM-like write cycle at the end so that would explain how it could look like SRAM

- So far only one of several devices exhibit the problem, all others work fine.

Thanks, Andrew

Reply to
andrew queisser
Loading thread data ...

Does your system have a cache ? It sounds like that part of the memory is cached.

I would rule out options 1 and 2. Option 3 may be possible. Number 4 is unlikely. Can you do a soft reset of the CPU alone to rule out option 4 ? You could use a scope on the RAM/Flash control lines (CS#, OE#, WE#) and see if the SRAM is addressed instead of the Flash during programming.

Reply to
Arlet

Thanks for the tips.

We don't have data cache on our design right now, just instruction cache.

When I do a soft reset of the CPU the flash contents stay unchanged, it's definitely something related to the power-up phase. The idea of looking at the CS,OE and WE lines is a good one. Since this is an FPGA I can use the built-in signal analyzer to set that up. Otherwise it would be hard to probe those lines.

So it seems Option 3 is most likely right now. In addition to probing I'll do a memcheck to see if I find the pattern I program into flash anywhere in the memory map...

Thanks again, Andrew

Reply to
andrew queisser

How are you sure that it is acting as SRAM?

If you

write to one of these locations with no other devices on the bus, then WRITE the invereted pattern to a non-existant device on that bus then read the original location

What do you get?

I suspect you think it is acting as SRAM when actually you have bus capacitance causing the last pattern to stay on the bus for a 'long' time so you are reading the old bus value back and the device is not actually being read at all. I.E. nothing is driving the bus at that time.

Considering how regular the pattern is I would suspect that there are addressing/data line problems as 3f8xxx is a problem and I assume

3f9xxx is OK.

Suggesting that A12 (on 8 bit wide addressing) is shorted to something. or similar, which suggests a PCB fault or FPGA programme fault.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

Hmm, haven't studied it to that depth. I should do some pattern testing although the data I have written and read was pretty random.

I've written whole sectors with test data, not just individual locations. I've used both application data (some tables that drive device behaviour) as well as test data from files so I'm pretty sure that the device is acting like RAM.

What I haven't done, and this is my next test, is to search the actual RAM space to see if I find the test data I thought I had written to flash.

Andrew

Reply to
andrew queisser

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.