linnix wrote:

> Yes, it does that.
> Chip erase, program and read-back for verification.
> But a separate verification failed.

That's an unusual failure mode.
If true, with that programmer, you should add an
extra verify pass, as it seems the first one is
capable of giving false positives ?

-jg

Jim Granville wrote:
> linnix wrote:
> >
> > Yes, there is an external 32KHz crystal.
> > Programmings are successful, but verifications are
> > wrong in one case and mismatch in another.
>
> That is somewhat flawed thinking: If verify fails, then
> programming was NOT succesful.
>
> Some software does not verify _during_ pgm,
> and so does not know until verify, that there
> was any problems.
>
> If there is a separate chip erase command on your SW,
> try that, and then verify you have a blank device.
> -jg

Yes, it does that.
Chip erase, program and read-back for verification.
But a separate verification failed.
Anyway, the chip seems death now.
I can't even jtag it.

I have done this process hundreds of time before.
But I am wondering if this part (atmega169V 1.6V)
is reliable enough in the field, especially for 
In System Programming.

linnix wrote:
> 
> Yes, there is an external 32KHz crystal.
> Programmings are successful, but verifications are
> wrong in one case and mismatch in another.

That is somewhat flawed thinking: If verify fails, then
programming was NOT succesful.

Some software does not verify _during_ pgm,
and so does not know until verify, that there
was any problems.

If there is a separate chip erase command on your SW,
try that, and then verify you have a blank device.
-jg

Mike Harrison wrote:
> On 28 Jan 2006 16:21:49 -0800, "linnix" <me@linnix.info-for.us> wrote:
>
> >How reliable are the AVR's flash?
> >I have two Atmega169 (in AVR butterfly) failing.
> >They are supposed to last 10,000 cycles.
> >And yet, one failed after hundreds of cycles
> >and the second failed exactly after one cycle.
> >
> >I can't program either one of them anymore.
> >The first one refuse to verify and the second
> >one verified but still contain the previous version.
> >
> >If it's so difficult to program them, perhap I should
> >switch to PLCC (44 pins) socket rather than MLF (64 pins).
>
> Do you have an oscillator (resonator/xtal) connected ?
> If not, and you are relying on the internal RC oscillator, it can happen that the config fuses get
> corrupted during programming and it ends up in an external osc configuration, so you then can't
> reprogram it.
> This can be recovered by applying an extarnal clock signal (e.g. 1MHz) to the oscin pin and
> reprogramming the fuses to the desired INTOSC setting.

Yes, there is an external 32KHz crystal.
Programmings are successful, but verifications are
wrong in one case and mismatch in another.

Jim Granville wrote:
> linnix wrote:
> > How reliable are the AVR's flash?
> > I have two Atmega169 (in AVR butterfly) failing.
> > They are supposed to last 10,000 cycles.
> > And yet, one failed after hundreds of cycles
> > and the second failed exactly after one cycle.
> >
> > I can't program either one of them anymore.
> > The first one refuse to verify and the second
> > one verified but still contain the previous version.
>
> The second sounds unlikely : ie How can it verify the wrong code ?
>
> If they are not secured, you should be able to read back the code, and
> then compare with the nearest HEX version - that can give an idea of
> failure modes.

That's what I did.  The read back file (using the same
programmer, avrdude) is different from the new file.
Although I don't have the old version to compare,
the AVR is still running the older code.

I know the bootloader first store it in SRAM (1K),
but it could not have stored the whole file (10K).
The only thing I can think of is that the flash has
a long term memory (old file) and a short term
memory (new file).

We might have to reconsider the bootloader in
general and atmega169 in specific.

> 
> -jg

larwe wrote:
> linnix wrote:
> > How reliable are the AVR's flash?
> > I have two Atmega169 (in AVR butterfly) failing.
>
> How are you reprogramming them? What's the power supply?

In self programming mode (boot loader),
both with the on-board 3V battery and external 5V supply.
We might need to switch to an external programmer.

> 
> I haven't had this problem, though I don't use that specific part.

On 28 Jan 2006 16:21:49 -0800, "linnix" <me@linnix.info-for.us> wrote:

>How reliable are the AVR's flash?
>I have two Atmega169 (in AVR butterfly) failing.
>They are supposed to last 10,000 cycles.
>And yet, one failed after hundreds of cycles
>and the second failed exactly after one cycle.
>
>I can't program either one of them anymore.
>The first one refuse to verify and the second
>one verified but still contain the previous version.
>
>If it's so difficult to program them, perhap I should
>switch to PLCC (44 pins) socket rather than MLF (64 pins).

Do you have an oscillator (resonator/xtal) connected ? 
If not, and you are relying on the internal RC oscillator, it can happen that the config fuses get
corrupted during programming and it ends up in an external osc configuration, so you then can't
reprogram it. 
This can be recovered by applying an extarnal clock signal (e.g. 1MHz) to the oscin pin and
reprogramming the fuses to the desired INTOSC setting. 

 

linnix wrote:
> How reliable are the AVR's flash?
> I have two Atmega169 (in AVR butterfly) failing.
> They are supposed to last 10,000 cycles.
> And yet, one failed after hundreds of cycles
> and the second failed exactly after one cycle.
> 
> I can't program either one of them anymore.
> The first one refuse to verify and the second
> one verified but still contain the previous version.

The second sounds unlikely : ie How can it verify the wrong code ?

If they are not secured, you should be able to read back the code, and 
then compare with the nearest HEX version - that can give an idea of
failure modes.

-jg

linnix wrote:
> How reliable are the AVR's flash?
> I have two Atmega169 (in AVR butterfly) failing.

How are you reprogramming them? What's the power supply?

I haven't had this problem, though I don't use that specific part.

How reliable are the AVR's flash?
I have two Atmega169 (in AVR butterfly) failing.
They are supposed to last 10,000 cycles.
And yet, one failed after hundreds of cycles
and the second failed exactly after one cycle.

I can't program either one of them anymore.
The first one refuse to verify and the second
one verified but still contain the previous version.

If it's so difficult to program them, perhap I should
switch to PLCC (44 pins) socket rather than MLF (64 pins).