Hallo,
ich habe vor geraumer Zeit eine Platine hergestellt, mit welcher ich 2
Solenoide steuern möchte.
Dabei sollte der Microcontroller ATTiny2313 verwendet werden, welcher
per Software-USB (avr309) die Kommunikation mit dem PC ermöglicht.
Die Schaltung habe ich bereits auf einem Steckbrett umgesetzt und die
Firmware, Treiber und Anwendungssoftware geschrieben.
Nun habe ich die Platine per KiCad entworfen, geätzt und bestückt. Mit
meinen Möglichkeiten konnte ich nur eine einseitige Leiterplatte
herstellen, wodurch die roten Verbindungen lediglich per Klingeldraht
umgesetzt wurden. Leider funktioniert die Platine nicht wie gewollt:
-> Die LEDs, die die Ansteuerung der Gates der jeweiligen FETs
signalisieren, blinken nur sehr kurz auf, wodurch der µC direkt in
die Interrupt-Routine springt
In der Firmware wird eine über USB eintreffende Control-Msg über USB
ausgewertet und der jeweilige (Output-)Pin auf 1 gesetzt. Dabei wird
der 16Bit-Zähler gestartet und beim Erreichen eines Wertes (aus der
Nachricht) wird der Interrupt bearbeitet, in dem dieser Pin auf 0
gesetzt wird und den Timerausschaltet.
Um mögliche Fehler zu beheben ging ich wie folgt vor:
- Unterbrechung der Leitungen zu den beiden Gates der Solenoid-FETs
(nurnoch 4 ansteuerbare LEDs übrig)
- Verzinnen aller relevanter Leitungen (könnten beim Ätzvorgang
beschäditgt sein)
- Zusätzliche GND-Leitung zwischen den Masse-Pin des 7805 und USB
- Andere Kapazitäten für den Quartz ausprobiert und im Labor gemessen
-> Quartz:
http://www.conrad.de/ce/de/product/155256/QUARZ-12000MHZ-HC49-30504018PFATF/SHOP_AREA_29142&promotionareaSearchDetail=005
-> da ich weder 22pf noch 18pf habe, versuchte ich es mit 27pF und
15pF, in beiden Fällen konnten 12MHz erzeugt werden mit Pegeln
von etwa 1V, derzeit sind 15pF verbaut und sollten noch im
zulässigen Bereich des Datenblattes liegen
- Firmware reduzieren (Auszug weiter unten)
-> Beim Eintreffen einer beliebigen Control-Msg soll die STAT1LED
eingeschaltet, nach Ablauf ca. 1s ausgeschaltet und dabei
STAT2LED eingeschaltet werden
-> Nach dem Senden einer Nachricht blinkt die STAT1LED jedoch nur kurz
auf und springt umgehend in die Interrupt-Routine
-> Bei mehrmaligen Senden wiederholt sich dieser Vorgang, die neuen
Nachrichten werden also verarbeitet
-> auf externe Ereignisse sollte nicht eingegangen werden (manche Pins
sind nicht verbunden)
- µC aus Sockel entnommen und -bei selber Firmware- in die Schaltung des
Steckbrettes eingesetzt
-> auf dem Steckbrett funktioniert die identische Schaltung (nur
niedrigere Kapazitäten zur Stabilisierung, keine FETs gesteckt,
ansonsten ähnlich)
-> dadurch sollte der Fehler in der Platine stecken, jedoch fallen mir
dazu nur parasitäre Kapazitäten durch die Steckbrett-Klemmen ein...
Gibt es denn noch irgend etwas, dass ich bei der Schaltung so richtig
falsch gemacht habe, das diesen Fehler hervorruft?
Vielen Dank für jeden noch so kleinen Tipp :)
Anbei noch ein Code-Auszug aus der Firmware:
-Parasitäre Kopplungen würde ich hier eher für unwahrscheinlich halten.
-Vielleicht ist die Platine nicht vollständig geätzt und irgendwo
ist noch eine leitende Verbindung.
-Die Vorwiderstände der Leuchtdioden scheinen mir etwas wenig, aber dann
müsste ich schon den LEDstrom oder den Typ wissen um das berechnen
zu können. Häufig werden so 150Ohm genommen.
Halte ich als Fehlerursache für unwahrscheinlich sofern die
Werte stimmen.
-Die vertikale Leiterbahn die zwischen den Pin-Reihen v. P1
vertikal verlegt ist, könnten wahrscheinlich Kursschlüsse verursachen.
Sieht sehr eng aus. Alles andere macht einen guten Eindruck.
-Alternativ fällt mir höchstens noch Fehlbestückung mit falschen Werten
ein, was du mal durch Messungen nachprüfen solltest.
- Im Schaltplan ist ein Siebelko C3 mit einem höheren Wert als im Layout
angegeben. C9 ist unnötig und belastet den Regler kapazitiv und macht
die Spannungsregelung träge.
C2 reicht da völlig. Verdachtsweise würde ich im Betrieb mal die
Restwelligkeit der 5V mit einem Oszilloskop messen.
Die sollte so gering wie möglich sein.
-Mit der Software hab ich mich nicht beschäftigt, das ist was für die
Bitundbyte-Gurus.
Mehr Auffälligkeiten sah ich nicht.
Hallo, vielen Dank für die Hilfe!
- Nach dem Ätzbad sahen alle Leiterbahnen zumindest vollkommen fertig
aus. Das werde ich beim nächsten Mal direkt messen, nun kann ich nur
sagen, wie es auf der bestückten Platine aussieht:
- Auf der vertikalen Verbindung von P1 "scheint" per Multimeter
kein Kurzschluss feststellbar. Selbst die Verwendung des ISPs
darüber funktioniert.
- kritischer könnten die Verbindungen zwischen Pin 11&12 und 19&20
des µC sein. In der Schaltung kann ich am Pin 20 und der
Durchführung 10k messen (vom Widerstand des Reset-Pins) und
am Pin 12 und der Durchführung 6k17, was 1k56 (aus den beiden
Widerständen von D-) mehr als die überall zwischen VCC und GND
abnehmbaren 4k6 ist.
Diese 3 kritischen Stellen scheinen also in Ordnung zu sein,
wo auch immer der 4k6-Widerstand zwischen VCC und GND herkommen
mag (vom 7805?)
- Fehlbestückungen habe ich nochmal überprüft, bis auf die 1k der
LEDs bleiben nurnoch die 68er, 10k und 1M übrig, alles korrekt
verbaut, auch die 3 Folienkondensatoren. C9 habe ich entfernt und
anstelle von C3 verbaut, konnte heute die Restwelligkeit noch nicht
überprüfen, mache ich morgen im Labor. Ein ungewolltes Neustarten
bzw. USB-Verbindungsabbrüche zum PC traten aber auch nicht auf.
- Zu den LEDs kann ich leider nicht mehr viel sagen, sie stammen aus
dem "C.-Standardsortiment" und "funktionieren eben". Ich konnte
nurnoch folgenden Artikel ausfindig machen (als D5 verwendet):
http://www.conrad.de/ce/de/product/172206/LED-5MM-ROT-25ER-PACK_FIL
-> gleiches Fehlerbild :/
Die Angaben des Layouts/Schemas habe ich korrigiert und ein Foto der
kritischen Stellen angefügt (entschuldigt meine Lötkünste, durch
zu heftiges und mehrmaliges Rein-und-Rauslöten wurden dickere
Lötklumpen leider nötig :/ )
Thomas S. schrieb:> kritischer könnten die Verbindungen zwischen Pin 11&12 und 19&20> des µC sein.
Wie ist das zu verstehen? Die Pins sind so doch gar nicht beschaltet
Pin 11 führt zu R8 und dem Gate von Q1(sofern nicht getrennt),
Pin 12 führt an Pin 6 des µC und R2 zum USB,
Pin 19 führt an P1, Pin 20 ist VCC.
Ich denke mal, das es nicht an der Platine und dem ätzen liegt,
denn die Leiterplatte macht einen relativ positiven Eindruck.
Da hatten wir hier schon ganz andere Sachen gesehen.
Offene Eingänge die den Programmlauf unvorhersehbar machen wirds
wohl hoffentlich nicht geben?
Thomas S. schrieb:> Diese 3 kritischen Stellen scheinen also in Ordnung zu sein,> wo auch immer der 4k6-Widerstand zwischen VCC und GND herkommen> mag (vom 7805?)
Manchmal hilft die Messkabel zu vertauschen, also zu verpolen
um zu sehen ob sich der Messwert ändert. Besser wäre es Halbleiter
für Messungen von vermuteten Kurzschlüssen vorher zu entfernen.
Thomas S. schrieb:> C9 habe ich entfernt und> anstelle von C3 verbaut, konnte heute die Restwelligkeit noch nicht> überprüfen, mache ich morgen im Labor.
Gewöhnlich verbaut man für jedes mA an Versorgungsstrom 1µF an Siebelko-
kapazität, aber ich denke mal das der µC nicht so viel Strom zieht
und die LEDs haben ja große Vorwiderstände.
Bin gespannt ob sich messtechnisch noch was ergibt.
Hallo!
Vorhin habe ich die Restwelligkeit untersucht und ein Foto angehängt,
leider nur analoger Oszi und Handykamera, aber es sind nur grob
100mV feststellbar.
>Hab mir nicht alles durchgelesen aber schau dir mal die markierten>Stellen an.
Habe die Markierungen kommentiert, sollte nicht daran liegen
>Wie ist das zu verstehen? Die Pins sind so doch gar nicht beschaltet
Ich meinte die Durchführungen, welche zwischen den Pins sind, und
dass so nicht direkt ein Kurzschluss zwischen Pin und Durchführung
erkennbar ist.
Ob im Programm ein Fehler ist kann ich nicht genau sagen, da 80% des
Codes von Atmel stammt. Auf dem Steckbrett habe ich die Pins auch
nicht beschaltet und es funktioniert dennoch. Vor einigen Tagen habe
ich auch jeden unbeschalteten Pin mit 1k gegen Masse verbunden,
jedoch blieb das Problem bestehen (die Widerstände sind wieder ab).
Insofern sollte es mit ziemlicher Sicherheit nicht daran liegen,
~könnte~ es bei der Komplexität der Firmware aber trotzdem... und
wenn es wirklich nix weiteres an der Platine auszusetzen gibt
werde ich es mir wohl noch ein 10tes Mal genauer ansehen müssen..
Leider bestehen beim Attiny keine sonderlichen Möglichkeiten zum
Debuggen :/
Heute kam ich nichtmehr dazu die Halbleiter auszubauen, werde es aber
hoffentlich morgen umsetzen können.
Habe heute die Halbleiter entfernt und die fraglichen Stellen
vermessen, auch mit verpolten Messköpfen und jeden einzelnen Pin
vom µC-Sockel und der ISP-Schnittstelle untereinander, nix.
Ich werde mich wohl nochmals durch die Firmware mühen müssen,
auch wenn es bei ähnlicher Umgebung so läuft...
Insofern kann ich nur erstmal meinen Dank für die Hilfe aussprechen,
der Fehler ist wohl nicht so einfach auffindbar. (Sollte ich
erfolgreich sein werde ich es euch wissen lassen ;) )