Hallo! Am Freitag hatte ich einen Rückläufer von einem mehrmals gebautem Produkt. Der ganze Fehler bestand darin, dass der Atmega8515 komplett leer war (wie im Auslieferungszustand). Als die Software neu rauf, Fuses programmiert und das Teil läuft seitem wieder.. - Schlecht.. :( Habe nun schon sämtliche Fehlerursachen ausgeschlossen (Versorgungen überprüft auf Spikes, Ein-/Aus-Flanken, Brumm, ect.). Seit Freitag hat es schon einen 12Stündigem Stress-Betrieb neben einem HF-Störsender überlegt.. Habt ihr noch eine Idee was einem AVR dazu bewegen kann, alles zu vergessen? Gruß, Techniker PS: Kunde ist nicht der Verursacher, da das gerät noch versiegelt war..
bevor ich jetzt mit irgendwelchen Spekutlationen über Störquellen anfange, würde ich sagen, dass er in der Fertigung nie programmiert wurde :) Das ist sicher die einfachste und wahrscheinlichste Lösung.
..ach ja: Das Produkt lief fast 8 Monate ohne Probleme und der gl. Kunde hat noch weitere 12 gleiche Produkte im Einsatz.. :-(
ich glaub ihr solltet euren Controllern mehr bezahlen, dann laufen sie nicht zum Feind über :P Nee, aber jetzt mal im Ernst... das hört sich echt verrückt an, kann ich mir nicht erklären
..ich mir eben auch nicht. :( Hatte sowas noch nie in der Art. Wie gesagt, war das Gerät komplett tot, als ich es bekommen hatte. Als erstet überprüfte ich die Versorgungen -> Ok Reset beim einschalten vorhanden -> Ok Quarzoszillator -> Ok Wird Controller erkannt? -> Ok Fusebits -> Auslieferzustand?!? Flash -> leer?!? Software und Fusebits neu rauf bzw. einstellen -> Alles läuft seitdem wieder im Labor-Stressbetrieb.. :( Nun hab ich eben ein bischen Angst, ob nicht doch noch ein Entwicklungsfehler drauf ist (trotz zahlreicher, teurer Test) oder ob dies von Aussen irgendwie verursacht wurde oder schrottiger Controller oder was weiß ich.. :-/ seufz
Hat sich vielleicht ein Mitarbeiter von der anderen Firma einen Scherz erlaubt und den AVR gelöscht ? Ich hatte solch ein Problem aber auch schonmal. War glaube ich ein AT89C51. Der lief ein paar Monate und plötzlich ging nichts mehr. Software neu reingeladen und die Schaltung lief wieder. Ich kenne auch ähnliche Fälle mit EPROMs in TV Geräten nach einem Überspannungsschaden. Man kann EPROMs also nicht nur per UV Licht und Röntgenstrahlen löschen...
Oder jemand hat den originolen gemopst, um ihn zu kopieren ?
..wie gesagt: Das Gerät war noch original versiegelt mit einem Firmeneigenen Spezial-Etikett.. :-/ Überspannung? hmmm Es sind noch einige andere IC's drauf - und nur den Atmel solls genau so erwischt haben, dass die Software weg ist?!? :-/ Werd wohl zur Sicherheit eine neue Leiterplatte einbauen und die alte verschrotten.. :(
also ich kenne eine firma die geht auf die barrikaden wenn der name avr in verbindung mit sicherheitsrelevanten steuerungen fällt ;-) wohl gerade aus diesem misteriösen grunde
Wirklich sehr merkwürdig, daß selbst die Fuses rückgesetzt wurden. Wie sind denn der Reset und die SPI-Anschlüsse beschaltet, sind die von außen zugänglich ? Wenn ich Reset nicht brauche, knall ich ihn direkt an den VCC-Pin. Wenn das SPI längere Wege geht, nen Pullup an den SCK-Pin, damit der sich nicht was einfangen kann oder die SPI-Fuse disablen. Und immer wenn möglich, das Brownoutreset einschalten, das Poweronreset alleine ist Mist. Peter P.S.: Ich schalte auch immer ne Supressordiode (z.B. SMBJ5V0A) an VCC, damit da nicht hohe Pulse einkoppeln können.
Hallo Techniker, >Das Produkt lief fast 8 Monate ohne Probleme und der gl. Kunde >hat noch weitere 12 gleiche Produkte im Einsatz das spricht dafür, dass er sich eins als Ersatz auf Lager gelegt hat - und da war der Controller nicht programmiert.... Gruss Otto
@Otto: Schön wär's.. :-| Leider sind alle Teile im Einsatz (ist eine Speziallösung) und da ist nichts auf Lager gelegt worden.. :-/ @Peter D.: Am Reset sind 100n & 10k -> 1ms Der ISP-Anschluss sind über einen Ministecker (weiß den Typ gerade nicht auswendig) von Samtec direkt neben dem Controller zugänglich. BOD ist natürlich aktiv (auf 4V). Suppressordiode ist ebenfalls vorhanden.. :-/
-> siehe oben! => Gerät war noch einwandfrei versiegelt! <=
Solche Probleme hatte ich auch schon (Forumssuche) mehrfach mit nem 89S8252. Das ganze ist allerdings beim Basteln passiert, beim testweisen Umschalten von Netz- auf Batteriebetrieb. Da ist anscheinend der Schaltregler derart ausser Tritt gekommen, dass er den Flash mit Müll gefüllt hat, obwohl der µC korrekt angeschlossen war und mit den üblichen 100nF versorgt war... Jetzt läuft der µC allerdings schon seit über nem Jahr in der Schaltung ohne Probleme.
..aber die genaue Ursache hierfür kennt auch niemand - oder? ****** Gibt es noch andere, bekannte (realistische) Möglichkeiten AVR zu "nullen" ohne ihn zu zerstören? Evtl. starke Magnetfelder / Elektromagnetische Entladungen / ect.. :-/ ****** Im Umfeld (ca. 30cm) der Geräte sind Leitungen verlegt, in denen schonmal 50A bei 20V fließen können. Störungen hierdurch haben wir durch versch. Massnahmen alle eliminiert - hoffen wir zumindest. Nur dieses Phänomen macht mir ein bischen Bauchweh.. :-(
Die alten AT90er galten als eher empfindlich und der Mega8515 hat deren EMV-ungeeignetes Pinout geerbt. Ganz besonders in der DIP-Version sind ausgerechnet diejenigen Pinleitungen am längsten, die das am schlechtesten vertragen. Aber auch die anderen Gehäuseversionen sind da suboptimal.
Hi Wir haben Geräte, bei denen fliessen bis zu 150A bei 160V und 80KHz in ca. 15 cm von einem ATMega128. Das geht problemlos. In den fast 8 Jahren, in denen wir AVRs einsetzen ist mir ein derartiger Fall, wie der beschriebene, noch nicht untergekommen. Bis jetzt kann ich mich über die Zuverlässigkeit von AVRs nicht beklagen. Was mich stutzig macht ist die Tatsache,daß auch die Fuses in den Auslieferungszustand zurückversetzt wurden. Dazu müsste diese Belegung im AVR gespeichert sein und in die Fusebits übertragen werden. Bei den Programmierbefehlen gibt es auch keinen, der das bewerkstelligen kann. Evtl. mal bei Atmel nachfragen. MfG Spess
>> Am Reset sind 100n & 10k -> 1ms
Hier gehört ein vernünftiger Resetbaustein dran, und ja, das kann die
Ursache sein.
Dies gilt insbesondere für den AT89s8252.
seufz Ich werd auf jedenfall mal die komplette Leiterplatte tauschen und mich mit Atmel in Verbindung setzen. Evtl. wissen die ja, was dies verursacht haben könnte und was man dagegen machen kann.. Sowas habe ich bisher auch noch nicht erlebt (und erlebe ich hoffentlich auch nicht mehr). Danke an alle & einen schönen Sonntag noch..
> Vielleicht dachte der Kunde er könne das Gerät reparieren in dem er > einfach den AVR austauscht? Waere auch mein Tip gewesen. Durch Stoerquellen oder sonstwas kannst Du Deinen Speicher vllt. korrumpieren aber sicher nicht Nullen. Da muss irgendein Eingriff von aussen passiert sein. Michael
Das mit den Spezialetiketten kannste knicken, die sind so sicher wie "Betreten der Baustelle verboten" Schilder ....
http://www.kanda.com/files/isp_circuits.pdf Schau dir dieses Dokument mal an. Wenn ein ATMEL in einer prof. Schaltung verwendet wird dann sollte man immer einen RESET Baustein verwenden. Wenns schon nicht den PGM Flash zerreißt, der EEPROM Bereich ist auf jedenfall ungeschützt. Es gibt hierzu eine Menge an Informationen, bemühe mal Freund Google. Jedenfalls hab ich das schon selbst erlebt.
>>Das mit den Spezialetiketten kannste knicken, die sind so sicher wie >>"Betreten der Baustelle verboten" Schilder .... Also ich kann mir da auch nur einen Zugriff von außen vorstellen, aber hier noch 2 Fragen: Wurde der Mega definitiv nicht ausgetauscht, stimmt wenigstens der aufgedruckte Date-Code? Waren keine Lockbits programmiert und waren wirklich alle Bytes des Flashs gelöscht? Ansonsten wird es wirklich die beste Lösung sein, sich direkt an Atmel zu wenden.
http://www.mhl.tuc.gr/v2/OTHERSUBJECTS/data_books/Atmel/Avr/doc0935.pdf Seite 3, Position 2. Atmel kennt das Problem ;-))
@Der Hubert: Es gibt solche und solche Etiketten. Glaub mir aber, die Etiketten die wir verwenden lassen sich nicht zerstörungsfrei entfernen. Diese sind hauchdünn, superflexibel und mit unserem geschützten Logo versehen.. @Joe: Danke für den Tipp - werde ich gleich mal ansehen.. @Volker: Lötstellen sehen 1a aus, wie bei der maschinellen Bestückung. da müsste schon jemand supergut löten können.. (..oder auf deutsch: Er braucht viel Übung!) Zum Datecode kann ich nichts 100%iges sagen - könnte aber hinkommen: Jul 2006 Lockbits waren nicht aktiv, da die Software zusammen mit dem Kunden etwickelt wurde..
Joe wrote: > http://www.mhl.tuc.gr/v2/OTHERSUBJECTS/data_books/Atmel/Avr/doc0935.pdf > > Seite 3, Position 2. Atmel kennt das Problem ;-)) Schau mal aufs Datum, das Ding ist von 1997 ! Warum gräbst Du solche uralten Leichen aus ? Die neueren AVRs haben alle ein Brownoutreset, das ersetzt den externen Reset-IC. Peter
@Joe: Du tippst auf die RiseTime von der VCC? Das werd ich morgen gleich mal ausprobieren, ob sich der int. Reset mit der Risetime überschneidet.. (..sollte da aber nicht der BOD greifen??)
Ist der ISP-Connetor nur auf der Platine oder auch von außen zugreifbar ? Ich brate jetzt immer nen Bootloader rein. Den Kunden mit ISP spielen zu lassen, ist mir zu gefährlich. Peter
@Peter: Der ISP ist nur intern. Die Software und die Hardware ist von uns. Sämtliches KnowHow ist mit dem Kunden abgesprochen und beiden Seiten zugänglich. Der Kunde hat plumpt gesagt garkein Interesse am verändern der Software. Von seiner Seite aus heisst es immer nur: "Ich brauch das und das - jetzt mach.." Es läuft alles sehr human auf kurzem Dienstweg ab und ich möchte dieses Vertrauen eben nicht verspielen.. Darum schmeiß ich lieber eine Leiterplatte für 500EUR weg. Ich wüsste aber schon gern, wodurch dieses Phänomen verursacht wurde.. :-/ Werd mich kommende Woche mal mit Atmel in Verbindung setzten.
>> Die neueren AVRs haben alle ein Brownoutreset, das ersetzt den externen >> Reset-IC. Vielleicht mal etwas ausführlicher. @ Peter, das ist mir durchaus bekannt und man hat immer wieder an Verbesserungen gearbeitet. Ebenso wird in dem Dokument nicht auf Datenverlußt hingewiesen (das Vermeidet man lieber). Wie gesagt, hierzu gibt es noch erheblich mehr Dokumente. Google mal nach EEPROM Datenverlußt und ATMEL. Ne schöne Diskussion gibts auch auf 8052.com allerdings bin ich zu faul zum suchen ;-)) daher meine Gedächtnisleistung ;-) Die Ursache liegt aber dort und nun noch ein Tip. Laß dir nen App. Ing. von Atmel geben und spreche exakt das Thema RESET + Datenverlußt an. Spätestens ab dem Moment wo du ihn schriftlich dazu aufforderst dir zu versichern das der interne RESET sowie BROWNOUT ok ist, mach der einen Rückzieher. Wie gesagt, schriftlich. Was glaubst du warum es externe Käfer für diese Aufgaben gibt ? warum kosten die soviel ?
@Joe, naja, Atmel AVR und Atmel 8051 sitzen in völlig verschiedenen Elfenbeintürmchen. Die 8051 hatten noch nie nen Brownoutreset und da schließe ich immer nen MAX813L an. Ich habe nur ein Projekt, wo ein ATtiny26 ohne Reset-IC drinsitzt. Bisher gabts damit keine Probleme, obwohl im Gerät bis zu 15000V rumgeistern. Wir haben aber auch keine riesen Stückzahlen. Peter P.S.: Wir setzen aber auch seit neuestem ARM (LPC) ein und die haben sich schon manchmal trotz Reset-IC verhakt (selbst der Resetknopf half nicht mehr). Wenn die Softwerker 32Bit hören, werden sie ja ganz närrisch, ist wie Honig für nen Bären. Es gab schon Überlegungen, dem ARM einen AVR zur Seite zu stellen, der dann das System in nen sicheren Zustand bringt und versucht durch Abschalten der 1,8V/3,3V den ARM wieder zu beleben.
>> naja, Atmel AVR und Atmel 8051 sitzen in völlig verschiedenen >> Elfenbeintürmchen. Es wird auch explizit AVR erwähnt, lesen mußt du, ich kann dir nur die Richtung geben. Ich werde auch keine weitere Überzeugungsarbeit leisten, ich habe hier nur meine eigenen Erfahrungen anzubringen. Seinerzeit bin ich dann auf derartige Dinge gestoßen. Wie sagt Erik: Internal resets seem to be - let me be kind - problematic in most cases. This has, in many (most?) cases, been the cause of flash loss. Christoph: >> RC resets are for toys only. und Oliver: >> I had a similar problem with an Atmel AVR
@Joe: Die Sache mit dem korrumpierten EEPROM war ebenfalls bei den non-BOD Devices (90Sxx). Siehe hier: http://support.atmel.no/bin/customer?custSessionKey=&customerLang=en&noCookies=true&action=viewKbEntry&id=4 Das Problem war damals aktuell, aber mit dem BOD sollte sich das ebenfalls erledigt haben. PS: Sieht eher so aus, als würdest du hier gerade alte Kamellen ausgraben ;) (Wie schon gesagt)
Atmel beschreibt hier das Problem und die Lösung für solche Fälle beim EEPROM, also keine stabile Versorgung, Interrupts wärend des Programmiervorgangs... Beim Techniker scheint ja plötzlich der Flash leergewesen zu sein, ich würde vermuten das irgend eine Störung einen Chiperease ausgeführt hat, ob dann auch die Fuses davon betroffen sind müsste ich erst mal nachlesen. Vielleicht hilf es das Ding so zu fusen das man es nicht mehr per ISP programmieren kann oder Die ISP Pins mit Pullups oder Pulldowns zu beschalten das da kein Programmieren durch ne Störung auftreten kann. Teste doch mal wie das Ding auf einen Handyanruf reagiert wenn das angerufene Handy daneben liegt und das unter verschärften Bedingungen z.B. hoher takt niedrige Versorgungsspannung usw.
@ Der Techniker (techniker)
>PS: Kunde ist nicht der Verursacher, da das gerät noch versiegelt war..
Vielleicht hat man vergessen, ihn zu programmieren? ;-)
Mfg
Falk
Falk Brunner wrote: > Vielleicht hat man vergessen, ihn zu programmieren? ;-) Wer lesen kann ist klar im Vorteil: Beitrag "Re: Atmega8515 verlor plötzlich sein Programm?"
Hallo! Heute habe ich mit Atmel telefoniert (fast eine halbe Stunde lang). Ich wurde von "Pontius zu Pilatus" weiterverbunden, bis ich zum Schluß einen gebrochen deutsch sprechenden Entwickler an der Leitung hatte. Alles was er im Prinzip wissen wollte war der Typ, der Datecode und ob ich den Controller einschicken könnte..?!? Auf meine Frage, ob da evtl. schonwas bekannt ist, wich er mir immer aus.. Ausserdem riet er mir alle Controller gegen einen neuen mit dem Datecode 0107 oder neuer zu tauschen?!? :-( Ich fragte dann, ob ich dies schriftlich haben könnte -> wieder nur ausreden.. :( Meine persönliche Meinung nach dem Gespräch: Die wissen, dass da was im Busch ist.. Meine Begeisterung für AVR's hat heute jedenfalls einen richtigen Dämpfer bekommen. :-(
>> Meine persönliche Meinung nach dem Gespräch: Die wissen, dass da was im >> Busch ist.. Nicht nur die ;-)) Ich danke dir für die Bestätigung meiner gestern mitgeteilten Worte.
Betrifft das nur den Mega8515 oder auch andere Typen? Wisst Ihr was Genaues?
> Betrifft das nur den Mega8515 oder auch andere Typen? > Wisst Ihr was Genaues? Leider nein.. :-/
Ein Bekannter hat kürzlich etwas ähnliches von einem PIC erzählt. Kunde schickt ein Zeit zurück. Geht nicht. Überprüft, Speicher leer. Vielleicht ist mal eins beim Prüfen durchgerutscht? Kann passieren. Neu Programmiert, zum Kunden geschickt. Kam wieder zurück. HÄÄ? Nochmal programmiert, 12 Stunden liegen lassen, Flash leer. Kommt vor. Ab in die Tonne
Waren die Teile evtl. (Röntgen-) Strahlung (Flughafen!) ausgesetzt?
@EinGedanke: Normalerweise nein - kann ich jedoch nicht 100%ig ausschließen.. Warum? Sind die da so derartig empfindlich?
>Warum? Sind die da so derartig empfindlich?
Keine Ahnung!
Würde mich aber auch interessieren...
Hallo, bei einem Zulieferteil, einem ISM-Funkmodem mit AT90Sxxxx und externem Resetgenerator, hatten wir mal das Problem, dass sich das Teil reproduzierbar das EEROM überschrieben hatte. Der Hersteller konnte das Problem nicht nachvollziehen. Letztlich lag es am langsameren Vcc-Rise in unser Applikation, und dem buggy Reset-Controller: Bis zu irgendeiner Spannung (habe ich vergessen) hat der keinen Reset gemacht, dann Reset bis Vcc Normwert erreicht hat. Der µC lief aber anscheinend schon los mit Vcc weit unterhalb der Specs, und kriegte dann den Reset... hat ihn wohl das EEROM löschen lassen. Also auch mal den Reset-Controller langsam von Hand hochdrehen, die meisten brauchen erstmal etwas Spannung, um den Ausgangstransistor aktiv zu schalten, irgendwie verständlich. Mir ist da ein Resetkonzept lieber, wo ein Pulldown drin ist, der später aktiv gegen High geschaltet wird, ist narrensicher. Ob das was mit dem Flash zu tun hat... keine Ahnung. Eventuell tatsächlich Einzeldefekt, oder durch Röntgenstrahlung geplättet... Edit: Mal allgemein, wenn man nicht selber die Versorgung stellt, sollte man das mit dem slow Vcc-Rise nicht auf die leichte Schulter nehmen. Es gibt einiges Zeugs, das mag das überhaupt nicht... noch schlimmer, wenn der Vcc-Rise nicht monoton ist.
man kann ja auch bei den Fuses den BOD Level auswählen also 2,7V oder 4,5V bei manchen Typen sogar 1,8V habe ich aber im Studio noch nicht gesehen weil ich nur mit den älteren Typen arbeite ATM16 ATt26. Außerdem kann man auch die Verzögerung bis zum Start auf 64mSek setzen bis dahin sollte die VCC auch ihren Endwert erreicht haben.
"64ms"... sollte, muss aber nicht; kann man echt nicht sicher von ausgehen. Wenn das eine SMPS mit etwas Regelproblemen ist, die an der Kante belastet ist, und dann plötzlich beim Hochfahren eine stark nichtlineare Impedanz (und das sind die Schaltung ja) sieht... besser den Vcc-Rise mit dem DSO angucken.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.