Hallo zusammen! Ich hab da ein seltsames Problem. Problemkind ist ein ATXmega64A1. Dieser wird über Schleifkohlen mit Strom versorgt, über welche gleichzeitig auch der Strom für einen BLDC-Antrieb geht. Hier lässt sich absolut nix dran ändern! Also extreme Betriebsbedingungen! Das ding hat einen Bootloader, der gegen Schreiben und Lesen geschützt ist, sowie einen Watchdog der fest durch Fuses definiert ist. Die App ist verständlicherweise nur gegen Lesen geschützt. Nun ist es vorgekommen, dass mal die App und neuerdings sogar der Bootloader scheinbar verschwunden ist. Bemerkt hab ich dies, da das Gerät nicht mehr funktioniert hat und bei genauerem Hinschauen, der externe Quarz nicht mehr geschwungen hat. Dieser wird beim BL sowie der App verwendet. Zunächst dachte ich, dieser hätte durch die starken vibrationen im Betrieb abgedankt, jedoch war nach Tausch dessen, das Problem nicht weg. Erst nach erneuter Programmierung lief das ding wieder. Was noch seltsam war, dass der Watchdog per Fuses auf 4Sek. gesetzt war, aber dieser beim ersten Programmierversuch nach diesem Chrash scheinbar auf 8Sek. gesetzt war. Alle 8 Sekunden wurde ein Signalmuster bei bestimmten IOs erzeugt, das nur nach dem Reset so auftritt. Also App hatte ein Problem und der WDT auch. Bin ratlos! Hat hier irgendwer was dazu zu sagen?
Hallo peda, ist relativ einfach gehalten: Aus 24V mach 15V per LM2940 und dann 3,3V mittels NCP5501DT33G. Dazwischen vor und hinter den Reglern diverse C's zum glätten und Filtern der höherfrequenten Störungen des Bürstenfeuers. Mittlerweile auch Filter ergänzt mit FKP1-C's wegen der hochfrequenten Störungen durch das Bürstenfeuer. Die Spannung am Proz ist für einige 100ms nach Abschalten der Spannung noch stabil - Am Proz direkt keinerlei Störimpulse auf 3,3V zu messen. Wie bereits beschrieben: Gerät war im aktiven betrieb - also BLDC-Motor lief mit einigen Ampere, welche über die schleifenden Schleifkohlen gezogen wurden und Spannung zappelte um die 24V - und plötzlich war die Programmierung einfach weg trotz gesetzter Fuses zum Schutz. Bootloader vorhanden, muss aber über einen speziellen Befehl aus der App gestartet werden. Zwar nicht unmöglich aber aufgrund diverser Hürden wie Checksumme etc. unwahrscheinlich. Welchen Einfluss kann die Schaltung auf die Löschung des Flash haben? Worauf ist zu achten? Gruss Sigi PS: Schaltplan posten etwas schwierig - Chef muss zustimmen ;-)
Interessant wäre der Anschluß des Motors an den MC und auch die Leitungsführung (Platine, Verkabelung).
Ich denke, dass es am Layout liegt. Habe gerade eine Bewässerungsanlage mit XMEGA und Pumpen gebaut, die mit DC-Motoren laufen. Die Motoren ziehen 2 Ampere, die per PWM auf 1A effektiv gebändigt werden. Die Stromspitzen an den FETs sind schon recht "nett" anzusehen. Der Controller hängt über L/C-Filter an der Versorgung, die durch einen 3.3V-LDO stabilisiert wird. Hohe Ströme fließen somit nur über die FETs und die Motoren, die Strompfade sind kurz und breit angelegt. Das Massepolygon und das 3.3V-Polygon um den Controller sind absolut frei von Spannungsrauschen. Funktioniert problemlos. Du solltest Deinen Controller in eigene Versorgungspolygone einbetten und die hohen Ströme räumlich davon absetzen. Die Versorgungsleitungen zum Controller solltest Du L/C-filtern und die Leitungen vom Controller zu den Steuerstufen sollten über Masseflächen laufen. Das Feuer an den Schleifkohlen solltest Du mit Ferriten, stromkompensierten Drosseln und Kondensatorkaskaden von der Steuerschaltung fernhalten.
:
Bearbeitet durch User
Ohje, alles schon gemacht. Direkt an den Halbbrücken schnelle Folien-Cs. Leistungsteil und Steuerteil auf dem PCB getrennt etc. pp.... Schleifkohlen haben so ihr ganz eigenes Eigenleben, das man nicht einfach so in jedem Fachbuch findet. Das wurde mir erst im Laufe dieses Projektes richtig klar. Da greift voll der multiplikative Charakter aufgrund des negativ differentiellen Widerstandes des Lichtbogens. Ein DC-Motor erzeugt ein ganz anderes Abbrandbild als ein BLDC. Nur.... warum ist das Flash plötzlich im aktiven leer bzw. das Programm beschädigt? Was kann hierfür der Auslöser sein - wie könnte dieser Mechanismus innerhalb des Atmel ablaufen? Kann ich einen Atmel durch leitungsgebundene Störsignale das Programm "aus dem Kopf schlagen"? Gruß Sigi
mattkeag schrieb: > PS: Schaltplan posten etwas schwierig - Chef muss zustimmen ;-) Möchtet ihr eine Lösung? Oder wollt ihr weiter im Nebel stochern?
Wie geschrieben, was ist der Grund, dass ein Atmel sein Flash maltretiert? Welche Mechanismen greifen hier?
mattkeag schrieb: > was ist der Grund, dass ein Atmel sein Flash maltretiert? > Welche Mechanismen greifen hier? Nur der Flash-Controller im XMEGA kann das Flash löschen. Dazu müsste er falsche Befehle erhalten oder Befehle als falsch interpretieren. Das könnte beispielsweise passieren, wenn die CPU aufgrund einer massiven elektrischen Störung Befehle falsch ausführt. Deshalb ist ein Betrieb der CPU in einem stabilen elektrischen Umfeld essentiell. Das gilt aber grundsätzlich für alle elektronischen Bauteile.
:
Bearbeitet durch User
mattkeag schrieb: > was ist der Grund, dass ein Atmel sein Flash maltretiert? - Überspannung an VCC - Überspannung >VCC, Unterspannung <GND an IO-Pins Z.B. wenn man Outputs direkt an Leistungs-FETs legt, kann da rückwärts was reinsauen. Wenn alles nichts hilft, Optokoppler zwischen MC und Leistungsteil. VCC sollte man mit ner 3,9V Z-Diode begrenzen. BOR hast Du gesetzt? Der Watchdog hilft gegen Hardwareprobleme überhaupt nicht. Auch wenn viele es versuchen.
:
Bearbeitet durch User
Stimmt, die Z-Diode fehlt! Bräuchte man wenn ne Schutzdiode im Proz aktiv wird. Wird bisher nur über mehrere 100nF "abgesaugt". Sowas konnte ich bisher jedoch noch nicht messtechnisch erfassen. Proz ist über Serienwiderstände, Filter-Cs, Schottkys nach Vcc und Motortreiber von den Fets getrennt. Leiterbahnen von Klemmen zu Fets und Motor sehr dicht und kurz ausgelegt. Bauteilplatzierung auch getrennt in Leistungs- und Steuerteil, so dass (theoretisch) keine Lastströme in die Steuerung weder kapazitiv noch induktiv stören können - ausser durch die gemeinsame Stromzuführung über die Schleifkohlen, was absolut unumgänglich ist. Bzgl. Layout: Es gibt kein richtiges Layout, sondern nur bessere und schlechtere. Beim BOD such ich den Wert für tBOD im Datenblatt. Wie lang ist diese Zeit? Ich vermute, dass wenn ich einen extrem scharfen und kurzen Puls bekomme und der interne Reset noch nicht aktiv ist, es Register zerdeppert. Hab eben eine FFT von den 3,3V im Leerlauf gemacht - Leistungsaufnahme Motor um die 30Watt - bei Volllast sind locker 10...15A möglich. Ergebnis: Max. 1,5mV bei 35MHz, alles andere quasi nicht mehr messbar. Durch Beschleunigungs- und Bremsmanöver kann die Spannung auch unter 15V zusammbrechen oder über 30V hochsausen. Beides wurde per Software weitgehend unter Kontrolle gebracht, sodass von Controller bis Treiber alles noch arbeitet. Werde Tests mit kleineren C's mit höheren Grenzfrequenzen machen. Stellt sich jedoch meisst erst nach Tagen und Langzeittests heraus ob's was gebracht hat. Problem ist zusätzlich, dass die oben beschriebene Störung nur sporadisch, teils erst nach Tagen oder Wochen auftritt.
Siegfried Hoch schrieb: > Wird bisher nur > über mehrere 100nF "abgesaugt". Der 3,3V VCC würde ich wenigstens noch nen 470µF Elko spendieren. Der kann schon einige Transienten vernichten, ohne das die VCC gleich durch die Decke geht.
Wobei Elko nicht Elko ist. Also auf niedrigen ESR (105°C-Typen) achten.
Mercy... bin diesbezüglich am Testen. Reihenfolge wie folgt: 24V -> 2000µF -> LM2940/15V -> 470µF -> NCP5501DT33G/3,3V -> 10µF + n*100nF (direkt an VCC-Pins des µC) Aus Erfahrung kriegt man aber diese Transienten nur mit kleineren MLCCs unter 10nF raus - siehe Impedanzkennlinien! Die 100er wechseln bereits unter 30MHz das Ufer zur Spule. Zu Beginn des Projektes dachte ich auch, es wäre relativ einfach mit ein paar C's etc, aber das Projekt hat es in sich. 24V - kein Problem, aber wer denkt schon dran, dass diese zum Einen erheblichen Lastschwankungen (locker +/-10V) unterliegt (Durch die Schleifkohlen + deren Verschleiss) und zudem mit HF-Rauschen im Volt-Bereich verseucht sein kann, was wie Kriechöl überall zu finden ist. Frage: Was passiert beim ATXmega vom Abfall der VCC unter Vbod bevor der interne Reset greift? Siehe XMEGA-Manual Kapitel 9.4.2 Figure 9-4. Brown-out Detection reset. Arbeitet da der Oszillator noch und werden da noch Befehle ausgeführt? Angenommen dem ist so und die Vcc geht unter die 1,6V oder so... was passiert da? Ich gehe davon aus, dass die Vcc per Transient schneller als ein Taktzyklus von 32MHz runter geht und mir hier ggf. Register versaut werden. Dies messtechnisch zu erfassen ist extrem schwierig - es sind derzeit Vermutungen aufgrund des Verhaltens des gesamten Systems. Was kann ich da ggf. machen? Weiteres Problem: Hardware steht nahezu unveränderbar - ausser den Werten von Bauteilen.
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.