Hey,
Ich werde nun mein erstes größeres (Schaltnetzteil) Projekt in Angriff
nehmen, bei dem ein uC (TI F28335) zum Einsatz kommt.
Die Aufgaben des uC sind entsprechend der Prioritäten gegliedert:
1. Implementierung einer Strom - und Spannungsregelung und PWM
Generierung
2. Überstromabschaltung
3. Messen und Abschalten bei zu hoher Kühlkörpertemperatur
Da ich aus dem Hardware Bereich komme und nur bedingt Erfahrungen mit
dem Coden habe, stelle ich mir nun die Frage, wir man geeignete
Testpunkte zum debuggen des Codes (im laufenden Betrieb) implementiert.
Mir fallen spontan zwei Möglichkeiten ein.
1. Die gemessenen Parameter (Strom, Spannung etc) über einen DAC
ausgeben und mit einem Oszilloskop messen. So kann man z.B. die
Messspannung mit der Referenz aufm Oszilloskop vergleichen, oder den
Ausgang des Reglers direkt ausgeben etc.
2. Einen GPIO des uC toggeln, wenn eine Bedingung innerhalb der ISR
wahr wird (z.B. wenn die Temperatur am Kühlkörper einen bestimmten Wert
überschreitet.
Meine Frage an die Erfahrenen unter euch:
Habt ihr noch weitere Hinweise und Tipps, wie man den Code debug
freundlicher machen kann?
Vielen Dank.
Gruß,
Carl D. schrieb:> Debug-Tip #1:> Fang mit was "kleinerem" an und sammle Erfahrung.
Gut, dann nehme ich einen 12V buck converter, der die Ausgangsspannung
auf 5V regeln soll.
Weitere Hilfe würde ich trotzdem sehr schätzen, da ich die Leiterplatte
selbst herstelle und entsprechend DAC etc. ohne große Probleme auf der
Leiterplatte verbauen kann. Wenn die Leiterplatte erstmal fertig ist,
stelle ich es mir schwieriger vor.
Hallo,
ich persönlich würde wohl selbst "bei einem so kleinen Projekt" eine
serielle Schnittstelle für das Debuggen vorsehen. Es gibt nämlich nichts
schöneres, als wenn der Code einem erzählt, was er macht (oder auch
nicht macht). Wo ich nämlich am PC einfach ein print einfüge fehlt die
Möglichkeit am µC ohne Schnittstelle komplett.
Gruß Kai
Ich weiß nicht was "größer" heißt, ich denke mal mehr als 1kW?
Aus eigener Erfahrung kann ich dir sagen, dass du mit Punkt 2 beginnen
solltest. Also deine Hardware bzw. auch die Software so gestalten, dass
diese den Wandler im Fehlerfall sofort abschalten. Wenn du
beispielsweise eine Strommessung hast, und diese einen Komparator für
die Überstromerkennung triggert, der wiederum die PWM abschaltet (=
MOSFETS abschalten, nicht floaten) solltest du genau solche Funktionen
zuerst implementieren und v.a. auch testen. Gleiches gilt für
Überspannung (v.a. bei Boostreglern).
Das ganze setzt natürlich voraus, dass du die Spannungen und Ströme
richtig misst, aber da sollte dir dein Debugger helfen.
Das spart dir Nerven, Bauteile, Zeit und Geld.
die Sicherheitsabschaltung würde ich mit einer eigenen Standardschaltung
machen. uCs haben leider die Eigenschaft im Fehlerfall abstürzen zu
können und das wars dann mit der Sicherheit.
Zumindest die wegen der Sicherheit kritischen Dinge wie Überstrom und
Übertemperatur sollten eigens gelöst sein, den Rest kann man dann über
den uC machen.
Das Buch „Linux Device Drivers“ (ISBN 0-596-00590-3, online z.B. unter
https://lwn.net/Kernel/LDD3/) enthält im Kapitel 4 eine ganz gute
Einführung in die Problematik. Vieles ist natürlich Linux-spezifisch,
aber die Prinzipien lassen sich durchaus übertragen.
Das Ding hat doch 3 Uarts. Was spricht dagegen, einen zu benutzen und
darauf Debugausgaben zu machen?
Ich hatte auch man einen ähnlichen 2810 programmiert. Den konnte man
über die TI-Entwicklungsumgebung auch im Einzelschritt-Modus betreiben.
Also den Jtag herausführen und Debugger einschalten.
@ Harry May (harry4516)
>die Sicherheitsabschaltung würde ich mit einer eigenen Standardschaltung>machen. uCs haben leider die Eigenschaft im Fehlerfall abstürzen zu>können und das wars dann mit der Sicherheit.
Nicht wirklich. Gerade diese Controller vonb TI (C2000 Familie, siehe
PICCOLO) sind EXAKT für sowas gemacht, incl. Sicherheitsabschaltung
durch HARDWARE im Controller.
>Zumindest die wegen der Sicherheit kritischen Dinge wie Überstrom und>Übertemperatur sollten eigens gelöst sein, den Rest kann man dann über>den uC machen.
Quark. Übertemperatur ist für den Controller eine schnachlangsame
Funktion, die kann im Sekundenbereich reagieren. Die muss nicht im xx
kHz Interrupt überwacht werden. Überstrom dagegen schon, der wird
sinnvollerweise mit einem Hardwarecomparator IM Controller überwacht.
Das alles kann der uC.
@ Alexander
>1. Die gemessenen Parameter (Strom, Spannung etc) über einen DAC>ausgeben und mit einem Oszilloskop messen. So kann man z.B. die>Messspannung mit der Referenz aufm Oszilloskop vergleichen, oder den>Ausgang des Reglers direkt ausgeben etc.
Kann man machen, aber nur, wenn der Controller einen echten DAC
integriert hat. Ansonsten wird es zu aufwändig und wenig brauchbar. Ich
hab mir für diverse Zwecke einen Mini-Logger eingebaut, der auf ein
Triggersignal hin diverse ADC-Werte in ein Array schreibt. Das kann man
dann Offline auswerten.
>2. Einen GPIO des uC toggeln, wenn eine Bedingung innerhalb der ISR>wahr wird
Ja. Ich hab das vor allem zur Messung der kritischen, weil
hochfrequenten (100kHz) ISRs genutzt, damit man weiß, wieviel CPU-Zeit
die brauchen.
> (z.B. wenn die Temperatur am Kühlkörper einen bestimmten Wert>überschreitet.
Das nun gerade nicht, denn das ist ein schnarchlangsames Ereignis, das
man mit jeder x-bliebigen, LAAAAAANGSAMEN Debugfunktion anzeigen kann
(LED, UART etc.).
>Habt ihr noch weitere Hinweise und Tipps, wie man den Code debug>freundlicher machen kann?
Bei so einem Controller ist es meist nicht ratsam, den Code anzuhalten,
dann dann kracht es. Aber diese Controller haben vorgesorgt, man kann
diverse Funktionen (PWMs etc.) beim Debugger-HALT weiterlaufen lassen
oder sofort auf den sicheren Zustand, meist LOW, schalten lassen.
Außerdem kann man kritische ISRs weiterlaufen lassen. Siehe Doku.
Das ist ein schöner Controller, viel Spaß und Erfolg damit!
> 1. Die gemessenen Parameter (Strom, Spannung etc) über einen DAC> ausgeben und mit einem Oszilloskop messen. So kann man z.B. die> Messspannung mit der Referenz aufm Oszilloskop vergleichen, oder den> Ausgang des Reglers direkt ausgeben etc.
Der Debugger vom Code Composer kann einen Real-Time-Mode.
(Eigentlich sogar zwei: Rude Real-Time und Polite Real-Time.)
Es ist in einem laufenden Programm kein Problem, auch
mehrere Variable im Debugger grafisch darzustellen.
> 2. Einen GPIO des uC toggeln, wenn eine Bedingung innerhalb der ISR> wahr wird (z.B. wenn die Temperatur am Kühlkörper einen bestimmten Wert> überschreitet.
Besser: Mit einem R2R-DAC an den GPIOs Aufrufe der ISRs visualisieren.
Statt Debug-Ausgaben ueber UART, die einfach zu lange brauchen:
Wichtige Ereignisse in ein Speicherarray loggen.
Auch dabei auf kurze Laufzeit achten. Also keine printf-Konsorten,
eher Binaer-/Integerwerte und die dann vom Debugger formatieren
lassen.
Das Erste ist die benoetigte Hardware Funktionalitaet zu testen, also
TimerTick, Kommunikationsschnittstellen, Debug Schnittstellen. Dann ADC,
DAC, Tasten, Display, Dann die Safe-State Modi, zB Endstufe abschalten.
Wichtig, beim Design :
Was geschieht, zB beim Powerup im Reset, wenn der Programmer dran ist ?
Dann sollte zB eine End-/Steuerstufe nicht schon Verbraucher
einschalten.
Was geschieht, wenn durch einen Programmfehler immer wieder ein Reset
kommt ? Dann sollte zB kein Relais zu klappern beginnen.
Was geschieht bei Unterspannung, wenn es fuer den Controller reicht,
fuer den Rest aber nicht ? Wenn ein Ansteuerfehler die Spannung
zusammenreisst.
Kann ein Steuerfehler einen Schaden verursachen, welche Auswirkungen hat
der, wie kann er vermieden werden ?
Welches ist/sind der Safe State ? In den/die man bei einem Fehler gehen
muss. Was geschieht dann ?
Vielen Dank euch allen.
Ich werde mich mal vermehrt mit den Debugger-Möglichkeiten vom Code
Composer Studio auseinandersetzen.
Ferner werde ich mich mit dem UART Betrieb vertraut machen. Das ist
sicherlich ein guter und wichtiger Schritt. Auf dem ersten Blick scheint
das keine schwarze Magie zu schein.
Ich danke euch für euren Input - ich werde bei Gelegenheit die
Ergebnisse meiner Arbeit posten.
Gruß,
Alexander
