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 !
Brownout Fuse eingeschaltet? Bei Unterspannung kann der Flash Speicher u.U. gelöscht oder überschrieben werden.
ben, was hast Du gegen EMV Einstrahlung und Einstreuung unternommen ?
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.
Verwendest du das interne EEPROM? Wenn ja unbedingt Brownout nutzen.
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 ;-)
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.