M128 bad silicon!

Go To Last Post
78 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your M128 is manufactured prior dec-2003 it may contain the following bug.

By reading flash memory with 'lpm/elpm' att maximum clockrates
the read value may be invalid.

This for instance affects your system if you do a checksumming
of the code at start-up.
We have only experienced this at max clock (16MHz).

Don't know if this also affects reading of data/strings in flash nor the
other AVR's.

We have found this in about 3-5% of our M128's.

Atmel do since dec-03 additional test to sort bad chips out.

Yes, Atmel support has confirmed this.

/bengan

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

Thanks for the info.

admin's test signature
 

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

No problemo!

Also note that sorting this out by own test is easy, so is getting
new chips from your supplier.

The only real inconvenience in this is the extra testing prior soldering.
This may be done by STK500/501 combination.

/bengan

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

"We have only experienced this at max clock (16MHz)."

bobtransformer had a detailed thread on a similar situation with a Mega32 app. Any updates, bobbo?

Lee

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

CRC check works "fairly" well at catching these.
You may also want to heat up the parts some, (50 C or so)
and burn them in for 24 hours, or at least overnight and test them
again (heated up) to catch more of them...

Also, I found this on usenet newsgroup from about 9 months ago:
boB

http://groups.google.com/groups?...

Subject: AVR Mega32 at 16MHz
Newsgroups: comp.arch.embedded
Date: 2003-03-16 07:35:02 PST

Did anybody had any problems using Mega32 device running at 16MHz?
We had cca. 20% of devices that do not correctly read Flash memory as
data constants...(using LPM instruction). Ocasionally device do not read
the contents of Flash correctly, usually one bit fails...If clock frequency
is reduced, it starts to behave as supposed...???

Dejan

admin's test signature
 

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

A little misleading... When burning in the parts overnight, you do not necessarily need to heat them up while burning them in, only when checking the CRC.

They appear to get worse over time, but seems that after the first 8 to 24 hours or so of burn in, they should be OK after that if the checked OK after that burn in.
boB

admin's test signature
 

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

Thx boB, I guess we have to do that burn party too.

Hmm, 9 months, I've heard that time before...

Can't really understand why they (Atmel) waited that long to do the
excessive testing of the chips.

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

How do you tell the build date of the chip?

admin's test signature
 

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

If it were a can of Budweiser, you would look on the bottom for a "Born On" date. :)

That failing, chips (with markings big enough to red) traditionally had a yyww stamp on them near the part number. An AT90S2313 I'm looking at says "0032" which would give it a born-on of week 32, year 00.

When a hairy topic like this thread comes up, there is usually other coded info on the bottom of the chip that would be internal batch numbers, die revs, etc.

So the year-week usually helps, but it may need to be narrowed further by the manuf. coded info.

Lee

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

If you contact Atmel about any possibly defective chips they always ask for three things: full part number (inc package), the date code YYWW and the batch or lot codes on the bottom or on the back of the chip (usually two strings about six characters longs), plus sometimes a revision letter in the bottom corner (like A revision, b, c, etc)

If you use a lot of chips it's useful to get to know how to read the different manufacturers codes (all pretty similair) so you can spot old batches or work out what bug lists apply to each batch of components.

admin's test signature
 

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

Hi,

A while ago I asked atmel the same thing, this is what they said:

Hello

You need to look at the back of the chip. The device code are usually
printed there. It is 355xxy for the new parts where xx is the part
number and y the revision letter. Older parts have the number 196xxy,
same system.

For some of the small devices there is not room for the device code.
For
those you will have to contact support to get the revision

The date code is not reliable enough.

Best Regards
Asmund Saetre
Atmel AVR Technical Support

--------------------------------------------
AVR support mail mailto:avr@atmel.com
Atmel AVR page http://www.atmel.com/products/avr/
Info and software https://www.avrfreaks.net
Discussion forum https://www.avrfreaks.net/phorum/
Distributors http://www.atmel.com/dyn/general...

-Colin

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

Turns out that CRC checking does NOT always find the bad parts.
But most of the time it looks like. Some bad ones can still get through we've
found out.
Just test very carefuly after burn in and heat them up a bit if possible (hair dryer
or something)
boB

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

I am in the process of testing several ATmega128-16AI's (Industrial so rated to 85C) that fall over at temperature.

This only happens at 16MHz (at 8MHz - not a single problem)

Out of the 15 units that have been tested 4 fail at 85C one of them fails a room temperature (spray it with freezer spray and it works fine though).

Sample of code (once all the ports have been set up) and text1 and text2 are identical strings

unsigned long x;

while (1)
{

  //waste some time 
  //(yes I know I should use a timer but I want it to be as simple as possible)
  for(x=0;x<0xFFFF;x++)
  {
    #asm("nop")
  }


  //loop through the first 600 characters of the string
  for(x=0;x<600;x++) 
  {
    if(text1[x]!=text2[x]) // if character No. x in the 2 strings are different
    {
      PORTA.1=~PORTA.1;   // toggle LED2
    }	
  }

  PORTA.0=~PORTA.0;        // toggle LED3 (one next to power LED)
}; 

At low temperatures - only LED3 toggles. Once the units under test warm up, some of them start flashing LED2 :?

Let them cool back down (or freezer spray and LED3 stops flashing)

I have tried the test on several revisions of silicon (up to rev H - 0350) all have the same symptons (hot at 16MHz) . Also as we use Mega128s an several products we have swapped the processors and the problem follows the processor.

:idea: Sound familiar to anyone ???? :roll:

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

I've got exactly the same problem, however we have noticed that some of the silicon is flakey at 14.7Mhz as well. At present we've got something like a 15% failure rate. Symptons include failure to upgrade - gets stuck in bootloader due to checksum failure and code falls over during normal operation, both of which are rectified if you cool the units down.

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

bengan(bengt florin) wrote:
If your M128 is manufactured prior dec-2003 it may contain the following bug.

By reading flash memory with 'lpm/elpm' att maximum clockrates
the read value may be invalid.

This for instance affects your system if you do a checksumming
of the code at start-up.
We have only experienced this at max clock (16MHz).

Don't know if this also affects reading of data/strings in flash nor the
other AVR's.

We have found this in about 3-5% of our M128's.

Atmel do since dec-03 additional test to sort bad chips out.

Yes, Atmel support has confirmed this.

/bengan

I better start testing with some 0352's then to see if any on them have the same problem :roll:

Cheers Texman, nice to know we are not the only ones with this temperature problem.

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

I received an email from Carl in the UK. He said that he had "one" failure with 0352 date code mega128 at 85 degrees C. He says he has 0350 DC parts that fail at 105 degrees C. I don't know if those are Industrial or commercial grade parts.

We have not had a failure of any 0350 Date Code Mega32s here yet, but haven't used very many. Maybe a couple hundred of those.

Just yesterday, we had a Mega32 (date code 0349) fail. No CRC error, but our LCD was fixed at 12.288 MHz, but another failure in this part did not go away until I ran the part at 10 MHz. It appears to not always be a slight clock frequency reduction that fixes the failures. It will hopefuly, (I am praying), drastically reduce the failures though. It sure helps I know.

BTW, we have found the CRC checking does not always find bad parts.
I also have a feeling that the LPM instruction is not the only problem, judging by looking at some of our failures modes, but I cannot say for sure.

0350 Date Code, I understand, is the magic number for the "new" test that Atmel is doing. I was told that I was the first person in the US to have this problem. Our local Atmel FAE did start to listen to me a few months ago. He quit this week.
Aside from his "attention", I have NOT been impressed with Atmels response on this issue. It has cost us many thousands of dollars.
When I talk to Atmel, it is like they hardly ever see this problem. I believe they are in denial. We use these parts BTW to the max. All the peripherals are in use, and the flash is used into the 90% range.

There is supposedly a new silicon mask or something on these parts (128, 32, 64 and whatever else) but I do not know when they will be available or what date code they will be. We cannot seem to get that information.
Hopefuly, we will be able to try a hundred or two of those parts. I don't necessarily trust those to work either until we go through a bunch. We are forced to reduce our clock frequency, so we may not find out if they fixed the problem or not. Can't take a chance on that.
Atmel is very hush-hush on their Quality control, and how they test the parts. Other companys, such as Microchip and Motorola are proud to show off their quality control and test procedures. I think they are testing at 3.5 Volts and higher frequency or something like that. I'm sure they don't burn in the parts though, which I know brings out the failures even more. I sure hope this new test is the (short term) answer. They must be throwing away a LOT of parts.... Or turning them into (L) versions.

I love the architecture of these parts, and just want them to work, but I sure get upset at their way of handling things.

bob :shock:

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

Bob.

The Mega128's we use are are 16AI 's (Industrial so are spec'd -40C to 85C)

I Have Just finished a test on 80 Units.

26 units Failed when comparing strings of text from flash.

2 @ 20C (room temp for 5 seconds) :shock:
8 @ 60 C (for 1 hour)
16 @ 85 C (for 1 hour)

Out of the 26 that failed ALL have 0350 silicon :?

Arghhhhhhhhhhhhhhhhh..............

Please tell me 04xx silicon fixes the problem. :roll:

Alan

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

Unfortunately, it is looking like reducing the clock frequency is the only way to reduce errors. At least reducing the frequency to 12 or 13 MHz seems to make them work a whole lot better.. Maybe not 100 %, but much better. We're going to 12.228 MHz. Most the time, I've found 14.318 MHz does the job. We have switching power circuitry controlled by this part so we cannot reduce the frequency by a whole lot.
Just make sure you burn in the parts, say, overnight or 24 Hours to catch more bad parts, and do not rely on the memory test by itself... Yes, reject those parts, but look carefuly at the parts that make it through the burn in and memory test.

It will be interesting to see how the new rev parts do. Hopefuly that fixes the real problem. I don't know what rev those are though yet.

:D Keep us posted !

Thanks,
bob

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

One more thing to consider, if you are not in the US.
As I understand it, the parts we get are bing tested in San Diego, CA. USA. The testing they are doing has been revised and I also understand that 0350 and greater date codes have this latest test done on them and so catch more bad parts.

I do not know what tests are done for parts that are distributed into
the UK for instance. It appears that the latest testing they are doing is
much better than it was, at least here. This may be the problem for your UK parts.
I do not know for sure.

thanks,
bob

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

We still haven't heard anything from the analyze of the chips we sent
in in december.
Atmel support estimated this to take 3 weeks.
I'd love to work there if they do 3 weeks work in 3 months!

Anyhow, we went down to 11.0592MHz and haven't had any failures of
the last 180 batch.

I guess the only thing to get Atmels attention is to stop buying their cpu's.
We do not intend to put M128 in our new products.
This thing has cost us more than sweat, blood and money.

/bengan

bngn

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

Quote:
I'd love to work there if they do 3 weeks work in 3 months!

Just look at studio 4.08.... :roll:

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

We have found probably around 10% of failures at 14.7Mhz and at 85C. We have 0328 and 0320 so far. Atmel has done a Failure Analysis on them and found the devices faulty. We have the industrial grade parts. This whole thing is REALLY disconcerting. This just gives the PIC camp more ammunition. Lowering clock speed is a very poor option - especially when in order to be safe you have to half your speed and even then it only gives you a little wiggle room.

Has anyone found a pattern to the failures? For example - is it reads of high bits or low bits? is an 0xFF more likely to fail than a 0x55? Is it address dependent. If they appear to work at 85C when ramped up in temp but then fail on the CRC check next power up does that mean that the chip was ready to go berzerk at any minute? Are these things a ticking time bomb? We have had devices that appear to operate perfectly fine at 85C but then fail on the CRC check. This leads me to believe that the failure is occurring somewhere in unused space - pretty unlikely. Is it always the same locations that go bad? What are people doing with products that have already been released?

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

14.7 MHz wouldn't be ~quite~ slow enough I don't think. That is on the edge from what I heard from Atmel about our failed parts (mega32s).

This is (from what they tell me) a problem when using the LPM instruction.
I use a LOT of those. Around 30 LPMs and it really shows up. Another product we have, which uses the same part, but only around 12 LPM instructions fail once in a while, but fairly rarely.

Usually, we see a problem when reading ASCII strings in flash, or in reading table values. Of course, just having bad LCD display is not the only symptoms. We would have units reset all by themselves or not work at all... VERY strange symptoms. I never did quite figure out all the reasons why LPM instructions would cause the symptoms we would see.
Changing the code by just one byte would completely change the symptoms. However, we (and others I think) DID find something funny correlated with bit 5 I seem to remember.

The only thing I believe that can be done is to lower the clock speed.
Or change the processor. We've gone to 12.288 MHz. Make sure you burn in the processors though. The problem gets worse with longer running parts as well. AT least up to one month in service and maybe a bit more. We have found (so far) that if a unit runs for more than say, a month or more, it has a very good chance of staying running. This is at 16 MHz. We find quite a few failures after burning in at least overnight.

I don't quite trust the testing that Atmel is doing 100%, but believe it is better now. Don't know how the new silicon mask or change they are doing will help. Hopefully it fixed this huge problem.

bob

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

Here is some more interesting information. At 80C using our boot loader I was able to find certain addresses and bytes that were wrong. Check out the tidbits from the Intel Extended output. The top line is with heat the bottom is without heat applied. You can see certain patterns. For example it is always the 5th bit ( 0xDF ) that gets masked. The address also seems to run around in similar neighborhoods.

:101F80008001045D1E4F0E94223819C092E017C0E4 - Heat
:101F80008001045D1E4F0E94223819C0B2E017C0C4 - No Heat

:10268000942E8C859D85AE85BF850E94D608802EB0 - Heat
:10268000942E8C859D85AE85BF850E94F608802E90 - No Heat

:10328000089514D000913305002359F000915007A0 - Heat
:10328000089514D000913305002379F00091500780 - No Heat

:10368000F091BE0600811091AB040117D1F40181C5 - Heat
:10368000F091BE0600811091AB040117F1F40181A5 - No Heat

:1039800009F043C00091C7060F3F11F40091B8063B - Heat
:1039800009F043C00091C7060F3F31F40091B8061B - No Heat

:103B800081F4442311F412DC3AC1009199060770C4 - Heat
:103B800081F4442311F412DC3AC10091B9060770A4 - No Heat

:104680000E94524E0093EC041093CD041FC0009181 - Heat
:104680000E94524E0093EC041093ED041FC0009161 - No Heat

:1053900002E00E94CF4F0AEF10E01A930A9341E017 - Heat
:1053900002E00E94EF4F0AEF10E01A930A9341E0F7 - No Heat

:10728000002319F10091EC051091CD05D1D0402FCC - Heat
:10728000002319F10091EC051091ED05D1D0402FAC - No Heat

:108780000E81201705E50FB9C0F4579902C000000B - Heat
:108780000E81201705E50FB9C0F4779902C00000EB - No Heat

:10A0800004161506B8F3041A150AD4CF001F111FC1 - Heat
:10A0800004161506B8F3041A150AF4CF001F111FA1 - No Heat

Any more info.

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

Yes, there is an internal self timed propagation delay problem I understand, and bit 5 must be where the majority of that problem is.

bob

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

We are getting around a 50% failure rate. I am unable to speak for 0408 and higher but I would avoid any chip in the 0328 range like the plague. Real disappointed right now.

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

Yes, we had a terrible time with that date code range of parts. Anything below 0350 at least.

Never seen any year 2004 parts yet. Supposedly they were testing 0339 and higher Date Codes more rigorously but they still failed a lot.

0350 (and higher ?) are definately better I think, but I still don't trust them yet. Slower speed than, say, 14 MHz may ne required to significantly reduce failures.
boB

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

hello,
have anyone experienced any problems with the eeprom?
my application is checking the eeprom data all the time. the data is secured with a crc16. after some minutes the software detects a difference, next time everything is fine.

software is running on a atmega128, 16mhz crystal, bod is active.

regards
gerhard

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

Gerhard, I am curious what happens if you slow down your clock...

To, say, 10 or 12 MHz. Let us know what you find.
I have seem EEprom problems once in a whil too. I just hope
it is related to the LPM problem.
boB

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

hello bob,
i made some tests with 8MHz internal oscillator and then the reading of the eeprom's works all the time.

what do you mean with ther "LPM problem"?

regards
gerhard

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

what do you mean with ther "LPM problem"?

What I mean is that the problem is with the LPM instruction.

That is what I was lead to believe and it certainly made sense.
Some problems do not seem to be related to using this instruction
but I have not looked deep enough into my code to see why some of
those other problems occur. EEPROM included.

thanks,
bob

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

Does anybody out there know what date codes of mega128, mega64, mega32 have the new silicon revision ??

bob

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

Hi,

If you want to know what revision the chip is:

Quote:
Hello

You need to look at the back of the chip. The device code are usually
printed there. It is 355xxy for the new parts where xx is the part
number and y the revision letter. Older parts have the number 196xxy,
same system.

For some of the small devices there is not room for the device code.
For
those you will have to contact support to get the revision

The date code is not reliable enough.

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

>>The date code is not reliable enough

What Atmel has told us is that date code 0350 and up has the newer
testing being done. This is of course not the silicon but the date code
of packaging or testing in San Jose I guess.

What we get here at the company I am at may not be what
everyone else gets though... maybe they only test these packaged parts
to this extent for us only. It may be that what is gotten in Europe is not
tested the same. I do not know.

thanks,
bob

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

>>This is of course not the silicon but the date code
of packaging or testing in San Jose I guess.

I forgot... They are packaged in Asia... Not San Jose.
Just tested in San Jose.

bob

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

Has anyone posted details of this thread to any of the electronics press? From what I'm reading, Atmel aren't being terribly proactive about this. The threat of a little adverse publicity in the fiercely competitive 8 bit uC market might prove effective (Atmel, are you reading this?)

Regards,

Colin

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

Atmel is running devices through Failure Analysis to see what the problem is and to help run down the root cause. We will see what the results are. I have had good experience with these parts in the past - could heat them up to near destruction without missing a beat ( 460Kb comm protocol ). Will have to see where my testing goes.

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

>>I have had good experience with these parts in the past

Have you run a bunch of them at 16 MHz while heating them up ?

Atmel knows what the problem is now I'm pretty sure. At least they have
a new silicon rev. We will be checking those out soon. I believe they
are trying to make good now, maybe... I sure hope so. Time will tell.
(and $$$ will tell too unfortunately)

bob

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

I will have to admit I have not done a burn in on every unit prior to this most recent 03XX DC. We run at 14.7Mhz ( close enough to 16Mhz ). As far as my experience with them being good - I guess I was speaking of the whole AVR family. I have used the 90S8535, 90S8515, M161, M16, and the M128.

When you say new silicon rev do you mean the >0408 parts or do you mean something as of yet to be released?

bobtransformer wrote:

Have you run a bunch of them at 16 MHz while heating them up ?

Atmel knows what the problem is now I'm pretty sure. At least they have
a new silicon rev. We will be checking those out soon. I believe they
are trying to make good now, maybe... I sure hope so. Time will tell.
(and $$$ will tell too unfortunately)

bob

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

>>I will have to admit I have not done a burn in on every unit prior to this most recent 03XX DC. We run at 14.7Mhz ( close enough to 16Mhz ).

14.7 MHz is actually far enough away to keep a lot of bad parts from showing up. It's typically on the edge though. We've had some parts that did not get completely better until 10 MHz. This may be fine to keep failures down too. Like I have observed, most people do not run the parts at 16 MHz and that is why we dont' hear more about this.

>I have used the 90S8535, 90S8515, M161, M16, and the M128.

The M128 is the only part out of this group that I know has a problem.
M32 and M64 have the problem too as I understand it. Don't know about the M161.

>When you say new silicon rev do you mean the >0408 parts or do you mean something as of yet to be released?

I don't know what the date code might be of a part with new silicon. 0408 might be. We will know as soon as we get some of these new revs which might be not too long a time now.

thanks,
boB

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

We have received 0410 parts. They passed all of our burn in tests. It appears they have fixed the issues. I understand they fixed the problem with some fine tuning of internal fuses AND a better screening process.

Good news.

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

Hi Mark !

sounds promising. could you please tell us the revision number of 0410 devices ? Is it still 35567H or not ( I ? ) ?.

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

Is this problem changing with supply voltage?

I planed to use 4,5V vith 16MHz as the data sheets says is ok.

After reading the information here I reduced it to 12MHz.
Would an increase of the voltage to 5,2V reduce the problems?

(I have a number of 0408 chips that I want to use)

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

From what I am hearing, 0408 rev parts have the new silicon fix.
I also have heard that the new silicon actually works fine now, even at
16 MHz and hight temperatures. This would be great.

Please try some at 16 MHz and let us know how they work.
We have some 0408 parts now and are going to do a run of 100 parts at 16 MHz. These will be running at 5 Volts though. I think that reduced voltage makes the problem worse, so try them at lower voltage too if you need.
thanks,
bob

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

They are still 35567H.

raivo66 wrote:
Hi Mark !

sounds promising. could you please tell us the revision number of 0410 devices ? Is it still 35567H or not ( I ? ) ?.

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

Hi bob
We have been having problems with pre0408 M128 silicon for several months, and by testing each piece of silicon with test code that continually used the lpm instruction we could get 25% of silicon reading from flash with an error at 85°C. Drop the temperature an the failure rate drops.
Atmel have now replaced all of our silicon with 0408 and 0409 devices and we have succesfully tested (16MHz at 85°C) and shipped 500 units without a single failure.
Carl

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

>we have succesfully tested (16MHz at 85°C) and shipped 500 units without a single failure.

This is Great news !! :D
Thank you !
We are presently testing some 0408 Mega32s (200) and will
update on our success as well.

Thanks for the feedback. Looks like maybe they have finally
done something about the problem.
I am curious if you have tried the parts at HIGH temperature to
see where they stop working??

boB

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

cstocks wrote:
Has anyone posted details of this thread to any of the electronics press? From what I'm reading, Atmel aren't being terribly proactive about this. The threat of a little adverse publicity in the fiercely competitive 8 bit uC market might prove effective (Atmel, are you reading this?)

Atmel tends not to be terribly pro-active about any problems associated with the AVR. This problem is the third incidence we've had of bad silicon with AVRs (3 different parts) and each time Atmel has initially said "there is no problem." Only after we send them bad parts and explain exactly what the problem is do we get some explanation like "a very limited number of these parts have the problem you experienced." Yeah right.

In one case 500 Mega8's of 2 different early date codes ALL had the same problem. Each TQFP had to be cut off the board and replaced. The distributor provided new parts, but wouldn't pay for the labor to replace them--let alone all the engineering time, lost production, lost sales opportunities, etc. associated with having a new product dead in the water. The irony in that case is the even earlier date code parts we used for the prototypes did NOT have the problem!

Atmel is equally unresponsive with tool problems. It has taken them years to get their tools even somewhat stable. They rarely meet their promised dates and they act like nothing is wrong most of the time.

Our biggest complaint is the amount of time we've wasted troubleshooting AVR and Atmel tool problems rather than designing products. Engineering time and being late to market are both very expensive these days. Atmel seems to have no appreciation of all the time and expense that results from their shoddy engineering and broken promises.

We're no longer using AVRs in new designs because of all the problems we've had. There are better options out now from manufactures who provide better silicon, better tools and better support. The LPC2XXX ARM7 parts from Philips blow away the Mega32 - Mega128 in price, performance, power consumption and tool support. There are better options for smaller 8/16 bit MCUs as well. Unless Atmel really gets their act together, I think the AVR is going to become a hobby part and won't be used in many serious high volume products.

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

This looks like a VERY interesting part... (LPC2XXX ARM7)

My only concerns, at first, are if the PWM can generate 2, 180 degree
out of phase, high frequency (25kHz to 30 kHz range) outputs, and
also, the 3 volt operating range, whch can of course be dealt with.

Is there a good C compiler for these parts ? Being an general purpose (I think) ARM uP, I would think so. I have been using the CodeVision compiler
with great results.

boB

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

I can't seem to find the real data sheet on this LPC2105 ARM part.
I find a 32 page specification, but can't seem the find the complete
.PDF
They're code protectable too I presume ?
That's important. The AVR architecture has been perfect for the products
we have.

Thanks,

boB

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

bobtransformer wrote:
I can't seem to find the real data sheet on this LPC2105 ARM part.
I find a 32 page specification, but can't seem the find the complete
.PDF
They're code protectable too I presume ?
That's important. The AVR architecture has been perfect for the products
we have.

Thanks,

boB

For whatever reason, that doc you mentioned, Philips calls it "Data sheet". The real thing is here:

http://www.semiconductors.philip...

Philips calls this "User Manual"?!? Yeah, whatever. It looks exactly like Philip's standard datasheet for any other semiconductor.

Who knows, maybe for the LPC2xxx they got a new documentation manager, with fresh and confusing ideas.

I've looked into the LPC2xxx family, and I don't agree that they offer so much more "value for money". They're good, sure, but on value-per-money I don't think they're better than most ATMega's.

Pages