strange problem with flash, M29F040B

Hello,

I have a micro-controller application (XC167) connected to an 512KByte 
flash M29F040B from ST via 8 bit demultiplexed bus.

I can clear the flash, erase single sector and write something.

But in every sector (64kByte each) I have problems with the addresses 
0x300...0x30F. On a clean flash I read 0x55 where it should be 0xFF.
I can write up to address 0x300 ok and the it fails.

The address logik is ok and first I thougth that some sfr from the CPU 
are causing that but as it is repeatedly in every sector I think that is 
something with the flash. Also the 0x55 is a quite magic number in 
programming flash devices. But just reading in sequential or even single 
order gives that result.

Someone an idea what that is ? I am doing something wrong?
Any special oddy thing?


Thx,

Adib.
---

On Apr 17, 6:07 pm, Adib Taraben <tarabe...@st-innovation.com> wrote:
> Hello,
>
> I have a micro-controller application (XC167) connected to an 512KByte
> flash M29F040B from ST via 8 bit demultiplexed bus.
>
> I can clear the flash, erase single sector and write something.
>
> But in every sector (64kByte each) I have problems with the addresses
> 0x300...0x30F. On a clean flash I read 0x55 where it should be 0xFF.
> I can write up to address 0x300 ok and the it fails.
>
> The address logik is ok and first I thougth that some sfr from the CPU
> are causing that but as it is repeatedly in every sector I think that is
> something with the flash. Also the 0x55 is a quite magic number in
> programming flash devices. But just reading in sequential or even single
> order gives that result.
>
> Someone an idea what that is ? I am doing something wrong?
> Any special oddy thing?

I doubt the flash chip itself is doing that, unless perhaps it got
physically damaged (wrong voltage, ESD).

How do you know your logic is OK ?

Are there any other devices on the same bus ?

Try disconnecting the CS# or OE# pin, and see if the problem persists.
If you don't get well defined data, hold a pull-up resistor on a data
line while you read.

If the flash is socketed, take it out, and program it externally, and
see what you read back.

On Apr 17, 12:07 pm, Adib Taraben <tarabe...@st-innovation.com> wrote:

> But in every sector (64kByte each) I have problems with the addresses
> 0x300...0x30F. On a clean flash I read 0x55 where it should be 0xFF.

Are you sure there is no address space conflict? Put your software in
a continuous loop reading 0x300-0x30F. Scope the address and select
lines on the flash chip.

Arlet schrieb:
...
>> But in every sector (64kByte each) I have problems with the addresses
>> 0x300...0x30F. On a clean flash I read 0x55 where it should be 0xFF.
>> I can write up to address 0x300 ok and the it fails.
...
> 
> I doubt the flash chip itself is doing that, unless perhaps it got
> physically damaged (wrong voltage, ESD).
> 
> How do you know your logic is OK ?
> 
> Are there any other devices on the same bus ?
> 
> Try disconnecting the CS# or OE# pin, and see if the problem persists.
> If you don't get well defined data, hold a pull-up resistor on a data
> line while you read.
> 
> If the flash is socketed, take it out, and program it externally, and
> see what you read back.
> 
Unfortunately the flash is a soldered plcc device.
There is a to strong pattern (error in every block) to not beleave that 
it comes from that flash. CS is only attached to that flash device.

Thx, Adib

Adib Taraben wrote:
> Arlet schrieb:
> ...
> 
>>> But in every sector (64kByte each) I have problems with the addresses
>>> 0x300...0x30F. On a clean flash I read 0x55 where it should be 0xFF.
>>> I can write up to address 0x300 ok and the it fails.
> 
> ...
> 
>>
>> I doubt the flash chip itself is doing that, unless perhaps it got
>> physically damaged (wrong voltage, ESD).
>>
>> How do you know your logic is OK ?
>>
>> Are there any other devices on the same bus ?
>>
>> Try disconnecting the CS# or OE# pin, and see if the problem persists.
>> If you don't get well defined data, hold a pull-up resistor on a data
>> line while you read.
>>
>> If the flash is socketed, take it out, and program it externally, and
>> see what you read back.
>>
> Unfortunately the flash is a soldered plcc device.
> There is a to strong pattern (error in every block) to not beleave that 
> it comes from that flash. CS is only attached to that flash device.

Looks like you will need to change the flash.
Is there room to fit a SMD PLCC socket ?

Before you replace the flash, pgm and verify one with
a test pattern.
A pattern we use here, is a decrementing counter,
that shifts on every 256 byte page ( XOR with upper Adr byte)
- that makes every page unique, and the direction
is 'opposite' the address, but it is a very simple pattern
to verify.

-jg

Jim Granville schrieb:
> Adib Taraben wrote:
...
> 
> Looks like you will need to change the flash.
> Is there room to fit a SMD PLCC socket ?
> 
> Before you replace the flash, pgm and verify one with
> a test pattern.
> A pattern we use here, is a decrementing counter,
> that shifts on every 256 byte page ( XOR with upper Adr byte)
> - that makes every page unique, and the direction
> is 'opposite' the address, but it is a very simple pattern
> to verify.
> 
> -jg
> 
> 
ok. first thing tomorrow I will try that and report.
This issue costed my hours and hours. A flash I can program externaly.

thx, Adib.

Adib Taraben wrote:
> ok. first thing tomorrow I will try that and report.
> This issue costed my hours and hours. A flash I can program externaly.

Also clean-up the pins on the one you remove [ if it is still intact :) 
], and read that in the programmer, just to check it really does have
some 55H, then try and PGM those stuck locations.

-jg

On Apr 17, 11:15 pm, Adib Taraben <tarabe...@st-innovation.com> wrote:
> Jim Granville schrieb:
...
> > Looks like you will need to change the flash.
> > Is there room to fit a SMD PLCC socket ?
...
The flash is ok. I can measure something on the data bus now. Still I
read 55 on that specific addresses :-? Still 3 more chips connected to
the data bus.
Removing the whole chip was even simpler than disconnect a single pin
that I was focused on :-)

Thx, for pointing me in right direction.

Adib.
--

Adib.Taraben@gmail.com wrote:

> ...
> The flash is ok. I can measure something on the data bus now. Still I
> read 55 on that specific addresses :-? Still 3 more chips connected to
> the data bus.
> Removing the whole chip was even simpler than disconnect a single pin
> that I was focused on :-)
> 
> Thx, for pointing me in right direction.
> 
> Adib.
> --
> 

Looks like a marginal timing issue or glitch on write to the flash. Some 
combination of address and data bits that are close to or outside device 
tolerance.

A logic analyser is probably the only way to debug this. You can write a 
test program to generate signals at or around the address where the 
error occurs and verify that there are no glitches and that timing is 
within data sheet values. In particular. check data setup and hold 
times. You could also try decoupling caps around the flash and 
associated devices to see if this makes any difference...

Chris



-- 

----------------------
Greenfield Designs Ltd
Electronic and Embedded System Design
Oxford, England
(44) 1865 750 681