Hallo,
ich stelle eine Hardware her, die als Baugruppe in bestehende Geräte
eingebaut wird. Sie ersetzt einen bestehenden Prozessor.
Meine Hardware besteht hauptsächlich aus einem Mega16 wobei fast alle
Pins zum Gerät hin verbunden sind, auch die Reset Leitung wird vom Gerät
gesteuert.
Die Hardware wurde nun problemlos in ein Gerät vom typ A verbaut, ca.
150 Stück jeweils ohne irgendwelche Ausfälle.
Bei einem anderen Gerät B fallen etwa 10% der Baugruppen aus und zwar
auf folgende Weise:
Die Baugruppe funktioniert eine zeitlang, möglicherweise genau einmal.
Dann nach dem nächsten Anschalten reagiert der Mega16 nicht mehr.
Ersetzte ich nun die Fehlerhafte Baugruppe nun mit einer neuen tritt der
Fehler nicht mehr auf.
Ich habe natürlich auf versucht die defekten Baugruppen zu analysieren.
Sie lassen sich weiterhin über SPI ansprechen. Auslesen kann ich das
Flash nicht, da ich entsprechende Lockbits gesetzt habe. Die Baugruppen
lassen sich jedoch neu programmieren und funktieren dann. Setzte ich sie
jedoch in das Gerät laufen sie einmal und funktionieren dann nach dem
nächsten Anschalten nicht mehr.
Mir läge sehr viel daran dieses Problem zu beheben, bin aber
einigermaßen Ratlos. Hat jemand eine Idee, was hier das Problem sein
könnte? Gibt es vielleicht äußere Einflüsse, die unter bestimmten
Umständen zur korruption des Flashs führen können?
Danke !
ben schrieb:> Setzte ich sie> jedoch in das Gerät laufen sie einmal und funktionieren dann nach dem> nächsten Anschalten nicht mehr.
Das hört sich doch schon mal gut an, dass der Fehler reproduzierbar ist.
Ich kenne mich mit Atmel nicht aus, aber dies müsste dir doch
die Möglichkeit geben, die Lockbits für einen Test nicht zu aktivieren.
Dann Fehler reproduzieren, und Flash wieder auslesen/vergleichen.
Dann weißt du schon mal, ob es überhaupt am Flash liegt oder nicht.
Außerdem ob einzelne Bits, ganze Blöcke, alles gelöscht ist.
Vielleicht gibt dir der Ort des Fehlers einen Aufschluss?
Jim M. schrieb:> Brownout Fuse eingeschaltet? Bei Unterspannung kann der Flash> Speicher> u.U. gelöscht oder überschrieben werden.
War bei den ersten 50 tatsächlich nicht aktiviert und habe ich dann
aufgrund des gleichen Verdachtes aktiviert. Leider habe ich jetzt wieder
eine Benachrichtigung über den Fehler bekommen.
Karl M. schrieb:> was hast Du gegen EMV Einstrahlung und Einstreuung unternommen ?
Die Baugruppe sitzt wie gesagt in einem anderen Gerät. Dieses besitzt
ein geerdetes Metallgehäuse.
Martin M. schrieb:> Das hört sich doch schon mal gut an, dass der Fehler reproduzierbar ist.> Ich kenne mich mit Atmel nicht aus, aber dies müsste dir doch> die Möglichkeit geben, die Lockbits für einen Test nicht zu aktivieren.> Dann Fehler reproduzieren, und Flash wieder auslesen/vergleichen.> Dann weißt du schon mal, ob es überhaupt am Flash liegt oder nicht.> Außerdem ob einzelne Bits, ganze Blöcke, alles gelöscht ist.> Vielleicht gibt dir der Ort des Fehlers einen Aufschluss?
An sich ja, leider bin ich selbst nicht im Besitz eines Gerätes bei dem
der Fehler auftritt. (Scheint nur bei bestimmten Gerät <-> Baugruppen
Kombinationen zu passieren) Nur einmal hatte ich für einige Stunden
Zugriff auf eines und konnte den Defekt analysieren, wobei ich hier
leider die Fuse bits nicht getestet hatte. Die 'defekten' Baugruppen
habe ich hier, kann mit diesen aber den Fehler nicht reproduzieren.
VCC mal etwas Filtern so 100uH Drossel dann 10uF Elko und 100nF Kerko
alles möglichst na an die Versorgungspins, größte Resetverzögerung
wählen nicht das der MC schon losrennt wenn die Versorgungsspannung noch
nicht voll da ist.
ben schrieb:> Die Hardware wurde nun problemlos in ein Gerät vom typ A verbaut, ca.> 150 Stück jeweils ohne irgendwelche Ausfälle.>> Bei einem anderen Gerät B fallen etwa 10% der Baugruppen aus und zwar> auf folgende Weise:
Sind Gerät A und B vollkommen unterschiedliche Apparate, oder
unterscheiden sie sich elektrisch nur geringfügig?
Falls das so ist, dann kommt eigentlich nur der elektrische Unterschied
zwischen den beiden Biestern in Frage.
MfG Paul
Paul B. schrieb:> Sind Gerät A und B vollkommen unterschiedliche Apparate, oder> unterscheiden sie sich elektrisch nur geringfügig?
A und B sind vollkommen unterschiedliche Geräte. Der Fehler tritt jedoch
nur bei einem Teil von B auf und auch hier nur mit einem Teil der
Baugruppen. Es scheinen hier also mehere Faktoren unvorteilhaft
aufeinander zu treffen.
Generell würde ich gerne verstehen welche Äußeren Einflüsse, evtl. in
Verbindung mit Prozesstreuungen des Mega16 zu einem Fehler wie dem oben
beschriebenen führen können.
Hatte mir natürlich auch schon viele Gedanken hierzu gemacht bevor ich
gepostet habe.
- Versorgungsspannung zu hoch, zu niedrig?
- Gerät B löst unter best. Umständen Programmiermodus des Megas aus und
programmiert den Flash neu? (Reset Leitung wird wie gesagt auch vom
Gerät gesteuert)
- ??
Und dann interessiert mich natürlich was ich dagegen tun könnte..
ben schrieb:> Und dann interessiert mich natürlich was ich dagegen tun könnte..
Ein bekannt problematisches Gerät besorgen, Baugruppe einbauen und mit
Oszi und Logicanalyzer anrücken?! In hartnückigen Fällen zusätzlich zum
Debugger greifen.
Das nennt man üblicherweise systematische Fehlersuche!
Schreiber schrieb:> Ein bekannt problematisches Gerät besorgen, Baugruppe einbauen und mit> Oszi und Logicanalyzer anrücken?! In hartnückigen Fällen zusätzlich zum> Debugger greifen.>> Das nennt man üblicherweise systematische Fehlersuche!
Debugger bei einem AVR um seltene Fehler aufzuspüren?
Logikanalysator für interne Fehler?
Vergiss es!
@ben
Kannst Du testweise (oder gleich ganz) auf einen neueren Typen
umstellen? ATmega164 wäre dies.
m.n. schrieb:> Debugger bei einem AVR um seltene Fehler aufzuspüren?> Logikanalysator für interne Fehler?> Vergiss es!
Er soll schauen, ob da irgendwas an den Pins wackelt, das da nicht
wackeln sollte. Etwa um den µC ungeplant in den Programmiermodus zu
versetzen!
Hallo,
einen solchen effekt hatte ich auch schon einmal, es war aber eine
statische ESD Entladung am reset Pin oder am Programmierinterface.
Danach war dann der Flash gelöscht. Pins mit Pullup/Pulldown und ESD
Dioden array schützen.
Gruß Sascha
Resetpin mit üblichen 10kOhm und 100nF beschaltet evtl? Bis 4,7kOhm
runter gehen, je nachdem was der Programmer mit macht. Und das ganze
auch erst nach der Drosselspulen aagreifen damit Reset auch gefiltert
ist.
An den Eingangspins hilft meist schon ein RC Glied da der Kondensator
die Impulse belastet und die Spannung am Widerstand schon ausreichend
abfällt. ESD-Dioden sind nicht immer erforderlich.
Du solltest aber schon mal mit einem Speicheroszi an das Messobjekt in
der Realanwendung um nach solchen Spikes zu suchen.
Was macht dieses Gerät das den Fehler verursacht, welche Verbraucher
schaltet es? Natürlich sollte deine Schaltung dagegen unempfindlich
sein. Aber diese Störquelle sollte man auch besänftigen.
Schreiber schrieb:> Er soll schauen, ob da irgendwas an den Pins wackelt, das da nicht> wackeln sollte. Etwa um den µC ungeplant in den Programmiermodus zu> versetzen!
Auf Grund seiner Stückzahl gehe ich davon aus, daß er die
gründsätzlichen Dinge wie das Wackeln von Pins schon selber kontrolliert
hat. Ebenso wird er sicherlich den µC nicht mit internem Takt betreiben,
sofern er die UART nutzt.
Die älteren AVRs waren empfindlicher gegen alles Mögliche als die
neueren. Zwar muß die Fehlersuche im Kopf anfangen, aber wenn es nicht
hilft, sollte man manchmal auch den Fehler nicht bei sich selbst suchen.
Mit der Methode hatte ich die besten Erfolge ;-)
