Ich habe hier ein komisches Problem bei ein paar Kundenrückläufern. Ich muss dazu sagen, die Software hat der Kunde geschrieben, die HW ist von mir. Die Hardware läuft seit vielen Jahren problemlos, daran kann es nicht liegen. Problem in Kürze: 1) Spannung anlegen: µC (XMega) soll in einer Tabelle (im Flash Programmspeicher) liegende I2C Daten senden, er sendet jedoch falsche Daten. Evtl. stimmt da der Pointer nicht oder das Auslesen funktioniert nicht. Reset hilft nicht! 2) ABER: Spannung weg/neu anlegen: µC arbeitet nun IMMER korrekt 3) 1) ist nicht mehr zu reproduzieren - nur durch 2-stündiges spannungslos-machen. Nun im Detail: Bei einigen wenigen Boards (unter 3%) passiert folgendes: a) Board wird an Spannung angeschlossen. Der Xmega384c fährt hoch, das Programm soll aus einer Tabelle heraus (diese steht im Flash-Programmspeicher) ein paar Daten lesen und diese per I2C senden (nur Senden, kein Empfang). b) Diese gesendeten Daten sind dann jedoch teilweise falsch. Es gibt daher irgendwann vom Empfänger kein ACK. µC hängt, weil er drauf wartet und das System startet wg. Watchdog neu und das ganze wiederholt sich. c) Interessant: ein Reset über die Resetleitung nützt nichts, das Verhalten bleibt gleich (fehlerhaft). d) ABER: Ein kurzes Wegnehmen der Spannung führt dazu, dass das System ab dann korrekt läuft - auch wenn ich es 100x aus/einschalte: es klappt immer! e) Erst wenn ich die Spannung für rund 2 Stunden entferne, startet das System wieder fehlerhaft, dann nützt auch wieder kein Reset. f) Restladungen in den Kondensatoren gibt es nicht - ich habe sie schon alle kurzgeschlossen: keine Änderung - ich muss 2 Stunden warten. g) Zeitlich stimmt alles, die PLL wird also immer korrekt gestartet h) Die Spannungsversorgung generell ist einwandfrei, Anschluss geschieht über ein hochwertiges Labornetzteil. Irgendeine Idee, was hier falsch laufen könnte bzw. was man mal versuchen könnte? Blöd ist, dass man immer erstmal 2 Stunden warten muss, bis das Problem wieder auftritt. Wie gesagt: ist nicht mein Code, der liegt mir auch nur in Auszügen vor. Daher hoffe ich nun so auf hilfreiche Fingerzeige. Danke
:
Verschoben durch Moderator
Ich denke mal, du hast bei einem betroffenen Board auch schon alle supplies gecheckt, auch den ripple etc. Da ein Reset nicht hilft, wuerde ich auch eine Fehlfunktion der Hardware erst mal als unwahrscheinlich ansehen. Klingt fuer mich danach, als wuerde irgendwo eine Variable verwendet, bevor sie initialisiert wurde. Es steht daher ein zufaelliger Inhalt darin, der auch durch Reset nicht weg geht. Erst ein kurzer power cycle erloest ihn davon, weil dann ein besserer Wert drin steht. Vorstellen koennte ich mir Folgendes: Fehler tritt auf, wenn eine 0 in der Speicherstelle steht. Das ist z.B. nach langem Ausschalten so. Reset belaesst die null wo sie ist --> Fehler bleibt. kurzer powercycle wuerfelt aufgrund des kurzen brown-out die Speicherstelle ordentlich durch, so dass nun ein Wert != 0 drin steht --> Fehler ist weg. Sehr langer power cycle sorgt dafuer, dass alle Speicherstellen irgendwann wieder auf 0 sind --> Fehler kommt wieder.
W.P. K. schrieb: > Irgendeine Idee, was hier falsch laufen könnte bzw. was man mal > versuchen könnte? Blöd ist, dass man immer erstmal 2 Stunden warten > muss, bis das Problem wieder auftritt. Probiers mal mit Kondensatoren entladen und abkühlen. Dann wird der Zyklus vielleicht kürzer. Und wie sieht's mit den Werten im Flash aus. Verliert der die über die 2 Stunden oder bleiben die erhalten, werden dann aber falsch gesendet. > Wie gesagt: ist nicht mein Code, der liegt mir auch nur in Auszügen vor. Dann schreib Dir halt ein Stück eigenen Code, das genau das macht, was der Originalcode machen sollte und teste das Verhalten der Boards auf Deinen Code.
W.P. K. schrieb: > Die Hardware läuft seit vielen Jahren problemlos, daran kann es > nicht liegen. Doch, natürlich kann es an der Hardware liegen. Es ist ja möglich, dass sich ein bestimmter Hardwarefehler nur mit bestimmter, neuerdings geänderter Software zeigt.
Sendet er immer das gleiche "falsche"?
Du könntest auch mal mit Kältespray drauf pusten. Vielleicht ist der Effekt temperaturabhängig.
Andi M. schrieb: > Klingt fuer mich danach, als wuerde irgendwo eine Variable verwendet, > bevor sie initialisiert wurde Gut möglich. Es gibt aber außer Variableninhalten auch Informationen in I/O-Registern und Peripheriebausteinen, da kann es auch zufällige Initialisierungen geben Als wir früher noch in Assembler geschrieben haben, habe ich beim Start immer als Erstes den kompletten vorhandenen RAM gelöscht (also sogar den Stack) und alle I/O-Register o. Ä. auf "ungefährliche" Werte initialisiert. Egal, was benutzt/gebraucht wurde und was nicht. Nennt sich "defensives codieren", man hat dann nach jedem Start garantiert dieselben Bedingungen. Heute verlässt sich mancher auf das, was ein Compiler, ein OS oder eine Lib initialisiert.
Beitrag #7832560 wurde vom Autor gelöscht.
Klingt interessant. Es ist sicherlich eine (ungewollte) Interaktion zwischen Soft- und Hardware. Seltsam, dass von dir eine Problemlösung erwartet wird, ohne dir die Software zur Verfügung zu stellen. Wie sollst du da den Fehler finden? An deiner Stelle würde ich eine Testsoftware schreiben, die alle Register und Speicher über eine Schnittstelle ausgibt und dann mal schauen, ob zwischen den verschiedenen Reset-Arten ein nachvollziehbarer, konsistenter Unterschied besteht.
W.P. K. schrieb: > Hardware läuft seit vielen Jahren problemlos, daran kann es nicht liegen Genau an DER liegt es! Gruss Chregu
W.P. K. schrieb: > Bei einigen wenigen Boards (unter 3%) passiert folgendes... Die restlichen 97% laufen mit derselben Software normal? Dann liegt es an der Hardware.
Jonny O. schrieb: > Du könntest auch mal mit Kältespray drauf pusten. Würde eher erwärmen, was den Verfall der Speicherinhalte beschleunigen sollte, und somit den Fehler schneller reproduzieren.
W.P. K. schrieb: > Ich habe hier ein komisches Problem bei ein paar Kundenrückläufern. [...] > Daher hoffe ich nun so auf hilfreiche Fingerzeige. 1) Du bist in diesem Subforum absolut und komplett falsch. In jeder Hinsicht. 2) Dass dir nicht einmal dieser höchst triviale Sachverhalt selber klar ist, läßt stark daran zweifeln, dass du in der Lage bist, dein Problem zu lösen. 3) Wir können es auch nicht. Wir haben ja nicht mal andeutungsweise deine Möglichkeiten zur Problemanalyse. Weder die Hardware noch die Software.
Um zu klären ob die zwei Stunden thermisch (Abkühlung nach Lauf) oder elektrisch (Kondensatorentladung) bedingt sind, würde ich den Versuch ein paar Mal bei verschiedenen Temperaturen wiederholen. Mein Tipp wäre nicht initialisiertes RAM. Vielleicht mal die Daten auf dem I2C mitloggen und schaun, ob die etwas verraten über ihre Herkunft. Edit: Für die Kollegen, die Zugriff auf die Software haben, wären meine Tips: - Codereview mit Fokus nicht initialisierte Variablen und Überschreiber durch andere Funktionalitäten - Debugausgaben einbauen, um einzugrenzen, wo die falschen Daten herkommen - Polyspace-Analyse
:
Bearbeitet durch User
Andi M. schrieb: > Vorstellen koennte ich mir Folgendes: > Fehler tritt auf, wenn eine 0 in der Speicherstelle steht. Das ist z.B. > nach langem Ausschalten so. > Reset belaesst die null wo sie ist --> Fehler bleibt. > kurzer powercycle wuerfelt aufgrund des kurzen brown-out die > Speicherstelle ordentlich durch, so dass nun ein Wert != 0 drin steht > --> Fehler ist weg. > Sehr langer power cycle sorgt dafuer, dass alle Speicherstellen > irgendwann wieder auf 0 sind --> Fehler kommt wieder. Die meisten on-chip SRAMs (6 Transistor-Zelle) haben keine Vorzugsrichtung und fahren "Random" hoch bezogen auf das ganze Array. Einzelne Zellen haben idR eine minimale Vorzugsrichtung. Software-Bug mit read-before-write Fehler wäre auch eine meiner heißen Vermutungen. Kann man halt schlecht prüfen, wenn man die SW selbst nicht hat. Da sollte der SW-Entwickler mal alle seine Warnings durchschauen und die SW mal gegen einen statischen Code-Checker werfen. Was du tun kannst: - Wie die anderen beschrieben haben: Mal mit den Umgebungsbedingungen spielen. Temperatur rauf-runter etc. Wichtig: Beide Temperaturextreme. Wenn die Temperatur höher wird, nimmt in der Regel die Leckage der Zellen zu und das ganze sollte sich beschleunigen. Jedoch akzentuiert Hitze die Differenzen verschiedener Transistoren, sodass bspw RAM-Zellen bei Hochtemperatur bevorzugt in eine oder andere richtung flippen und du dir den fehler dadurch wieder verschleiern könntest. - Schaue dir die slewrate deiner Versorgung beim Start an. Ist diese in Spec? Manchmal kann es sein, dass sich der Power-on Reset dann verhaspelt und irgendwas sporadisch kaputtgeht. - Tritt das Problem mit selber SW aber neuer HW auch auf? wenn du die HW noch umprogrammieren kannst (nicht totgefused etc.): - Schreib dir ein kleines Testprogramm, das zyklisch einen RAM-Test macht. Also wechselnde Patterns reinschreiben (0x55, 0xAA, 0x00, 0xFF usw.) und gegenchecken. - Füll dir den flash mit zufälligen Daten und checke den während der Runtime. Am einfachsten, man schreibt was rein und berechnet eine CRC32 über alles und prüft, ob die sich verändert. Das kannst du dann in der Ecke, oder noch besser in der Klimakammer mal nen Nachmittag laufen lassen. Glaube nicht, dass es daran liegt. Aber dann wäre die Konfidenz höher, dass zumindest nichts im Halbleiter gestorben ist. RAMs und Flash können durchaus mal über Lebensdauer kaputtgehen. Zellen gammeln weg, Sens-Verstärker driften weg, precharge Logik versagt.... Das sind ansich ja empfindliche Analog-Schaltungen.
:
Bearbeitet durch User
W.P. K. schrieb: > b) Diese gesendeten Daten sind dann jedoch teilweise falsch. Es gibt > daher irgendwann vom Empfänger kein ACK. µC hängt, weil er drauf wartet > und das System startet wg. Watchdog neu und das ganze wiederholt sich. Ein I2C-Master kann nicht auf das ACK warten. Er taktet das 9. Bit rein und prüft, ob es ACK oder NACK ist. Gewartet wird nirgends. Wie groß sind denn die beiden Pullups? Wenn das I2C eh nur Master sein soll, dann kann man das auch komplett in Software schreiben (Pin setzen, löschen, einlesen). Dann kann sich schonmal der interne I2C Controller nicht verklemmen. Manchmal gibt es auch Probleme, wenn der Quarz nicht sauber anschwingt. Mit dem Wechsel des Quarzes liefen dann die Platinen wieder. In späteren Designs habe ich daher nur noch Quarzozillatoren verwendet, die sind ja auch nicht mehr teuer. Neuere AVRs haben oft keine Quarzoption mehr, sondern nur noch einen Takteingang.
Erstmal Danke für den Input. Meine Hoffnung war ja, dass jemand sagt "ja kenn ich, das war bei mir XXX". Wie schon erwähnt, der Rest der HW ist es definitiv nicht und Ein paar Kommentare / Infos dazu von mir: 1) Nicht initialisierter Speicher / Variablen etc.: ja, das dachte ich mir natürlich auch schon, das ist das einzige was bei diesem Fehlerbild Sinn macht. Aber eigentlich dürfte der Compiler das ja gar nicht zulassen. 2) Kälte/Wärmebehandlung: Kälte hatte ich vorher schon versucht, aber Wärme macht natürlich in diesem Zusammenhang mehr Sinn. Guter Tipp. Ich habe also den µC mal für 2 Minuten per Heißluft auf 200°C erwärmt (nur den µC, der Rest der HW blieb kühl) und dann diesmal nur 30 Min abgewartet: normalerweise reichen 30 Min nicht, aber nun startete er wieder fehlerhaft. Ein weiteres Indiz für die Theorie der Restladung bei Speicherzellen. 3) Die Frage ob das System immer gleich fehlerhaft startet, kann ich bejahen: die falsch gelesenen (per I2C ausgegebenen) Daten sind also immer identisch. 4) Zugriff auf die SW bekomme ich sicher noch, dann kann ich mehr sagen. 5) Pullups sind 10K, die Signale sind auch einwandfrei 6) Das Oszi zeigte da ACK Fehler an. Aber vermutlich wird da wirklich nicht auf ACK 'gewartet' sondern der Watchdog springt da rein und resettet. Ich habe vorhin nochmal neue Daten aufgezeichnet und das sieht verdächtig danach aus. Ich sehe hier somit zwei unterschiedliche Probleme: falsche I2C Daten werden aus der Tabelle gelesen (bzw. gesendet) und gleichzeitig schlägt der Watchdog zu früh zu. Ich habe da heute noch ein Gespräch mit dem Programmierer. Mal sehen, ob ich Neuigkeiten erhalte. Evtl. hat er zuletzt abweichende/falsche Compilereinstellungen genutzt oder an anderen Einstellungen etwas geändert. Ich melde mich da nochmal, sobald ich mehr Infos habe.
:
Bearbeitet durch User
W.P. K. schrieb: > eigentlich dürfte der Compiler das ja gar nicht Finde den Fehler... Oder war's Häkchen?
Irgendwas auf Kante genähtes oder nicht initialisiertes ist schwer zu finden. Da die "falschen" Daten immer gleich sind, versuche die im Speicher zu finden (externer Programmspeicher? Ein oberes Adressbit falsch?). Oder haben sie ein Muster? (wie Original, nur das dritte Bit invertiert/0, high-byte/low-byte vertauscht ...). Dazu den Programmspeicher stumpf auslesen und binär suchen. Ein vergessenes Register meckert kein Compiler an. Als Workaround den Programmierer einen Reset nach ein paar Sekunden machen lassen. Wenn das klappt, den Programmierer ein Register-Abbild rauspusten lassen (alle Register stumpf rauspusten nach der Initialisierung und vor der eigentlichen Arbeit (sollte gleich sein, wird aber vielleicht unterschiedlich sein). Dazu natürlich den Reset wieder rausnehmen! Im Datenblatt alle Register untersuchen, die ein 'u' oder sowas beim Reset haben, die also nicht auf 0 oder 1 oder sonstwie gesetzt werden.
:
Bearbeitet durch User
Hardware ist ok Software hat Bugs "Irgendjemand" ohne Zugriff auf den Code sucht den Fehler in der Hardware ????? Was läuft falsch bei euch? Der einzige der den Fehler sinnvoll suchen und dann auch beheben kann ist der Programmierer der Firmware. Und nach dem Verhalten würde ich sagen das eine Variable nicht uninitialisiert ist, aber vor dem Init benutzt wird.
:
Bearbeitet durch User
Die Taktfrequenz stimmt ?
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.