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 ;-)
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.
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:> 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.
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.
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.
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.
