An ill ATMega128 slipped through device testing at Atmel...

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... and landed on a board, which in turn ended up at my desk.

In production, it appeared to work OK and the device went through our testing procedure without any fault, until they attempted to reprogram the testing application with the final one. Hummm...

Closer insepction revealed that it is possible to reprogram it using ISP and if "empty" (erased, all FFs), also through the bootloader. However, reprogramming of already programmed FLASH through bootloader failed: bits which should've been changed from 1 to 0 were all changed; the other direction worked only here and there... An "all zeros" application could thus be programmed always, except that the usefulness of such application is questionable ;-)

Went to the "gems" box (a.k.a. thrash bin :-P )

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
bits which should've been changed from 1 to 0 were all changed; the other direction worked only here and there...

:?:

The other direction should work never.
You must first erase a page, so it contain 0xFF and never a 0-bit must be changed to 1.

If I remember right, the internal flash functions need, that the internal clock was calibrated.
Maybe you have changed the calibration byte to a wrong value.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The other direction should work never.
You must first erase a page,

It sounds to me like the "erase" isn't working fully.

JW, while it is certainly possible that the AVR itself came faulty, it is also certainly possible that it was damaged (e.g. static) during the board assembly process, or damaged during finished-board handling.

If you want me to suggest probabilities...

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of my students ATmega128 boards behaved like that too. I swapped it over for a working board and tried to resurrect the faulty board. In the end I was able to resurrect the board by using HV programming (using STK500), erasing it completely and after that restoring the bootloader. It worked OK after that!
I am not sure whether I would lay blame with ATMEL?

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:
wek wrote:
bits which should've been changed from 1 to 0 were all changed; the other direction worked only here and there...

The other direction should work never.
You must first erase a page, so it contain 0xFF and never a 0-bit must be changed to 1.


Of course there is a page erase before programming in the bootloader - this is a production bootloader with thousands of devices being updated now and then out in the wild. So, me investigating the symptoms, was in fact reading the FLASH after the combined erase/program cycle.

I think in the said bootloader there is no check after the page erase whether the page was really erased. I could modify the bootloader accordingly, but I believe the result would be that page erase does not erase everything it ought to (Lee writes the same above).

danni wrote:

If I remember right, the internal flash functions need, that the internal clock was calibrated.
Maybe you have changed the calibration byte to a wrong value.
Oh, interesting point. I consider pulling the chip from the garbage bin... :-)

theusch wrote:

JW, while it is certainly possible that the AVR itself came faulty, it is also certainly possible that it was damaged (e.g. static) during the board assembly process, or damaged during finished-board handling.
Yes, sure, I cannot exclude it. Although, I wonder what is the probability it damages only the circuits vital for page erase (while bulkerase during ISP is OK). I've seen zapped ICs before, even AVRs, and it was always a pin stuck or "weird", and IDD high.

Of course there are oh so many things... ;-)

But thanks for the ideas, to all.

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Datasheet 2467S–AVR–07/09, page 43:

"The calibrated Oscillator is used to time
EEPROM and Flash access. If EEPROM or Flash is written, do not calibrate to more than 10%
above the nominal frequency. Otherwise, the EEPROM or Flash write may fail."

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I dug up the thrash bin :-| but did not find the chip :-(

Thus the wisdom is lost forever... :-?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: Found it! (in the other thrash bin :-) ).

Soldered up onto a empty board, added crystal and a LED. Calibration bytes are 0xA8, 0xA7, 0xA0 and 0xA2; comparing to other Mega128s these seem fairly similar. Set for 1MHz internal RC and run a 12-cycle toggle-led loop, hooked up an LA - the loop runs at 12.15us (with considerable jitter compared to operation out of crystal - maybe around 0.2%).

What else should I try?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:

What else should I try?

Try to use a bootloader.
Maybe try erase at first and check per SPI, if it works.
If you detect problems, try to write a lower value into the calibration register.

Peter