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.
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...
..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.. :-/
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
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.
@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
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
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.
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
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.
