Hi, ich hab hier mal wieder einen Fehler der mich wahnsinnig macht. Ich habe eine Relaissteuerung und RS232-Anbindung mit ATtiny2313 aufgebaut, Schaltplan im Anhang. An SV4 hängen nur Taster und LEDs dran aber auch unbeschaltet tritt das Problem auf. Mein ISP-Adapter ist der mySmartUSB light unter AVRstudio 4. Die ISP-Leitungen sind separat angelötet (VCC vom ISP aber nicht). Wenn ich einen neuen ATtiny einsetze geht die ISP-Kommunikation eine Weile problemlos, doch nach wenigen malen Flashen fängt es an: Beim Starten irgendeiner ISP-Aktivität (flashen, signature..fuses auslesen) fängt das Programm in immer langsamer werdenden Abständen an loszulaufen und die Relais klackern (da sie bei Programmstart aktiviert werden) in entsprechendem Takt. Abhilfe schafft manchmal, wenn ich die Relais vorher ausschalte UND die Resetleitung manuell dauerhaft auf GND ziehe. Seitdem ich die Aktivierung der Relais zu Programmbeginn aus dem Code rausgenommen habe hilft auch das nicht mehr. Was teilweise auch funktioniert ist, die Spannungsversorgung komplett abzustellen. Dann wird der AVR nur über die ISP-Datenleitungen gespeist beim Flashen aber irgendwie funktioniert das manchmal. Auf jeden Fall kann das nicht angehen.. mir gehen langsam die Tricks aus wie ich das Programm noch auf den AVR drauf kriege. Ich dachte mir dann, ob der ISP es vll aus irgendwelchen gründen nicht schafft, Reset auf Masse zu ziehen aber mein DSO verrät mir, dass er das durchaus sauber durchschalten kann. Vorhin, als ich meine Arbeit am Projekt wieder aufgenommen habe ließ sich der Controller dann ohne Probleme ein paar mal ganz normal und ohne Tricks Flashen und dann finden die genannten Probleme wieder an. Was ist hier los? Tiny kaputt? Zu hohe Luftfeuchtigkeit? Ich komm nicht drauf. Und die unbeherrschbarkeit dieses Phänomens macht mich wahnsinnig. Danke für jeden Tipp! lg
Angehängte Dateien:
-
relaissteuerung.png
25 KB
Nachtrag: Mein Labornetzteil hat die Eigenschaft, die Spannung relativ langsam hochzufahren wenn man es aus dem Standby in den Betrieb schaltet. Trotz aktivierter Brown-Out Detection bei 4,3V bleibt der ATtiny2313 dann manchmal hängen und startet sein Programm nicht.
Hallo, wie ist den dein Reseteingang beschaltet ? Ist der offen am langen Kabel? Lege mal ein Pullup mit 1kΩ - 10kΩ an Vcc und 1nF Reset nach Masse. Filtere die Versorgungsspannung deines attiny bitte über ein C-L-C Glied: 100nF-100µH-100nF.
Der Reset ist offen am ISP-Kabel. Das allerdings hat nur 30cm Länge, das hat in der Konfiguration bisher auch noch nie probleme Bereitet auf diversen Breadboard-Aufbauten. Ohne deine Tipps jetzt mal umgesetzt zu haben habe ich den Tiny aus der Schaltung rausgenommen, auf ein kleines Breadboard drauf an dem nichts weiter angeschlossen ist als VCC/GND vom Labornetzteil, ISP und der Quarz. Hier kriege ich auch überhaupt keine ISP-Verbindung, egal wie. Wenn ich aber einen frischen Tiny einsetze klappt alles auf Anhieb problemlos, wie gewohnt. Auch wenn ich die Fuse-bits genau so konfiguriere, d.h. ext. Quarz und Brown-Out detection. Worin liegt der Fehler wenn ich jetzt davon ausgehe, dass die genannten Entstörmaßnahmen (in allen Ehren!) zwar nett aber nicht notwendig sind und irgendwas dafür verantwortlich ist, dass meine Tinys ständig partiell geschädigt werden?
Auch interessant: Ich habe noch einen AVR Dragon aber der schafft es offenbar zuverlässig, den problematischen ATtiny2312 zu erkennen und zu flashen wohingegen der mySmartUSB light an diesem nicht oder nur ganz sporadisch funktioniert. Den neuen ATtiny2313 jedoch schlucken beide erst mal problemlos. Was ist hier los??
:
Bearbeitet durch User
Nuja Paul, Atmel hat für die Hardwarebeschaltung 2-3 Application Notes verfasst, wenn man diese alle nicht umsetzen möchte, dann musst Du weiter mit deinen Problemen leben. Erst wenn Du dich erschöpfend mit EMV (HF) beschäftigt hast, wirst Du meinen Vorschlag erst nehmen.
Ich werde deine Vorschläge morgen umsetzen. Einfach um mögliche Fehlerquellen auszuschließen. Schlüssig wirkt es auf mich aber aus genannten Gründen nicht.
Was soll das mit R4 an 12V? Das finde ich nicht gut. Ein Spannungsteiler ist dort sicherlich die bessere Wahl.
blubber schrieb: > Was soll das mit R4 an 12V? > Das finde ich nicht gut. > Ein Spannungsteiler ist dort sicherlich die bessere Wahl. Ist derzeit nicht beschaltet. Kriegt in der realen Anwendung dann auch nur 5V ab anstatt der im Schaltplan vermerkten 12V :) sry
:
Bearbeitet durch User
ich nehme immer 10 kOhm Pullup und 100nF Kerko als Resetbeschaltung, so hinkt die Resetspannung der Versorgungsspannung beim Einschalten 1 mSek hinterher und außerdem schaft es dann auch jeder Progger Reset runterzuziehen. Hatte letztens einen TQFP-AVR auf einer Adapterplatine mal ohne den Kerko an VCC und Reset getestet und prompt bliebt er auch im Brown-Out hängen.
So. Es hat mir keine Ruhe gelassen und ich habe die von dir vorgeschlagenen Maßnahmen umgesetzt. Versorgungsspannung mit CLC-Filter und am Reset 10k nach VCC und 10n nach GND. Das ganze verändert am beschriebenen Verhalten des problematischen ATtinys leider überhaupt nichts :-( Hätte mich ehrlich gesagt aber auch gewundert, denn bisher hat das Programmieren eines nackten AVR auf Breadboard immer funktioniert, und mit einem nagelneuen Tiny klappts ja auch. Irgendetwas zerstört meine ATtinys so dass der mySmartUSB light nicht mehr damit klarkommt. Evtl ist es sogar der Programmer selbst. Jemand noch Ideen? Ich will nicht einen Tiny nach dem anderen schrotten. Ich leg mich jetzt frustriert ins Bett.
:
Bearbeitet durch User
Einige neue Versuche, gleiches Phänomen. Was ich nun probiert habe: Mal eine neue Firmware auf den mySmartUSB light aufgeflasht und das USB-Verlängerunskabel ausgetauscht bzw. einen anderen USB-Port verwendet. Leider keine Verbesserung, er erkennt den fragwürdigen Tiny immer noch nicht. Einen frischen Tiny erkennt er anstandslos, auch wenn ich das aktuelle Programm draufflashe. Der AVR Dragon erkennt nach wie vor alle. Da kommen jetzt genau drei Fragen auf: Warum funktionieren frische Tinys? Warum funktionieren sie nach einigen Malen nicht mehr? Warum macht nur der mySmartUSB light und nicht der Dragon Probleme?
:
Bearbeitet durch User
Gestern bin ich mal in die Gelegenheit gekommen, einen zweiten mySmartUSB light auszuprobieren. Der zeigt genau das gleiche Verhalten am problematischen ATtiny2313. Das deutet darauf hin, dass mein Adapter nicht etwa defekt ist. Interessanterweise hat das Programmieren des µCs noch problemlos funktioniert als der interne RC-Oszillator aktiviert war. Mit dem 7,3827 MHz Quarz jedoch funktioniert es nicht mehr. Mein AVR Dragon schafft aber weiterhin problemlos den ISP-Zugriff. Scheinbar ist die Kombination ATtiny2313 + 7,3872MHz Quarz + mySmartUSB light ziemlich empfindlich. Eventuell gibt es hier Timingprobleme? Ich stehe mittlerweile auch mit dem Hersteller des Programmieradapters in Kontakt. Bin mal Gespannt ob sich hier irgendwann eine Lösung ergibt.
Ich führe meine one-man Show hier mal weiter: Spoiler: Es liegt irgendwie am µC-Programm!? Ich habe mich heute dem Problem noch mal angenommen und konnte das Verhalten folgendermaßen bei drei verschiedenen ATtiny2313 reproduzieren. Einer davon war noch vollkommen unbenutzt, quasi fabrikfrisch. Der ausschlaggebende Punkt scheint mein hex-File zu sein, das ich auf den tiny flashe. Sobald dieses draufgeflasht ist funktioniert die ISP-Kommunikation mit dem mySmartUSB light nicht mehr. Zumindest nicht mit den eingestellten Fuses unter verwendung eines externen Quarzes. Auch andere Quarze als 7,3728MHz wie 4MHz oder 8Mhz funktionieren nicht. Das Programm läuft aber wie es soll, es gibt keine Bugs. Der AVR Dragon bringt die ISP-Kommunikation nach wie vor zustande. Wenn ich den tiny mit dem AVR Dragon erase dann erkennt der mySmartUSB light ihn auch wieder. Das erklärt auch, warum während des Programmierens der tiny irgendwann immer sporadisch ausgefallen ist. Eventuell gab es einen Zusammenhang zwischen meines Programmierfortschritts bzw. des damit resultierenden hex-Files und den Ausfällen der ISP-Kommunikation. Im Errata des Datenblatt für den ATtiny2313 sind keine Probleme mit dem ISP aufgeführt. Eben habe ich mal per Dragon die Fuses auf den internen 8MHz RC-Oszillator (ohne CLKDIV8) zurückgeschaltet. Auch so funktioniert die ISP-Kommunikation mit dem mySmartUSB light nicht. Mittlerweile kann ich den Fehler wohl ziemlich gut auf das programmierte hex-File eingrenzen. Nur verstehe ich nicht wieso. Das Programm ist für den ATtiny2313 entworfen und läuft auch einwandfrei. Abgesehen davon dürfte es gar keinen Einfluss auf das ISP-Interface haben. Was geht hier schief? Die Tinys scheinen sogar aus unterschiedlichen chargen zu stammen. Manche haben einen gelaserten, kaum leserlichen Aufdruck, manche einen inteniv weißen. Alle zeigen das gleiche Verhalten. Parallel hierzu bin ich ja im Gespräch mit dem Hersteller des mySmartUSB light. Dieser Thread dient nurmehr als Informationsquelle für Leute, die evtl. mal auf das gleiche Problem stoßen. Oder vielleicht hat noch einer einen Geistesblitz und kann uns damit alle erleuchten ;-)
:
Bearbeitet durch User
Ist nicht mehr von Relevanz, da wer Fehler, wie schon erwähnt, taktquellenunabhängig auftritt.
Hast du ein 2 Kanal Oszi. Es könnte sein das die Spannung am Resetpin schneller ansteigt als an VCC, verzögere das ganze mal indem du 10µF an den Resetpin hängst?
Wie groß ist das Startup Delay in den Fuses gewählt?
Wie groß ist deine ISP Clock? Schon mal versucht die abzusenken?
Thomas O. schrieb: > Hast du ein 2 Kanal Oszi. Es könnte sein das die Spannung am Resetpin > schneller ansteigt als an VCC, verzögere das ganze mal indem du 10µF an > den Resetpin hängst? Reset hab ich schon mit nem 10k/10µF RC-Glied beschaltet. Bringt auch nix. Zum Programmieren muss aber der Reset ohnehin auf GND liegen also hilft hier eine Reset-Schaltung prinzipbedingt nicht weiter. Ich schrieb: > Wie groß ist das Startup Delay in den Fuses gewählt? Alles ausprobiert. Nichts hilft. Ich schrieb: > Wie groß ist deine ISP Clock? Schon mal versucht die abzusenken? Kann man nicht einstellen beim mySmartUSB light, denn der probiert am Anfang automatisch alle ISP Clocks durch und nimmt dann die höchstmögliche. Das ist auch der Moment an dem der Fehler offenbar auftritt. Der Programmer beginnt mit der höchstmöglichen und tastet sich weiter vor zu langsamsten. Zwischendurch startet das µC-Programm halt immer mal wieder in kürzer werdenden Abständen. Bis der Programmiervorgang abbricht weil er den geeigneten ISP Clock nicht findet. Das ganze ist abhängig davon, welches Programm auf den µC geflasht ist. Ein gelöschter Tiny oder einer mit einem anderen Programm geht.
:
Bearbeitet durch User
Hm, 1. Also 22n ist murks. Es gibt Referenzbeschaltungen. Deine Lastkapazität ist viel zu hoch: https://blog.adafruit.com/2012/01/24/choosing-the-right-crystal-and-caps-for-your-design/ 2. Was ist das für eine ISP Beschaltung? MyUSB gibt etwas anderes vor. 3. Reset hast du ebenfalls nachgerüstet? 4. Die 12V über 100k sind ebenso murks, hast du aber ebenso geändert? 5. Ist Deine Zelle korrekt? 6. Klackern die Relais beim Proggen? GGf. bricht Deine Spannung ein, wenn die 3 Relais gleichzeitig klacken? Welchen Strom ziehen die Relais im Schatltmoment? (DB) 7. Wo kommen die 5V und 12V her? Was leitet sich hier von wem ab? Aufgabe: * Designempfehlungen + Standardbeschaltungen nehmen * Alle Änderungen einpflegen und neues Schaltbild bitte posten. bis bald.
Wühlt man sich etwas durch die Welt der AVR-Programmer und -Bootloader, findet man eine ganze Reihe Exemplare, die es mit der Spezifikation nicht besonders genau nehmen, um schneller zu sein. Es kann also durchaus sein, dass dieser mySmartUSB zwar meldet, den Flash zu löschen, das aber nicht tatsächlich tut. Paul H. schrieb: > Kann man nicht einstellen beim mySmartUSB light, denn der probiert am > Anfang automatisch alle ISP Clocks durch und nimmt dann die > höchstmögliche. So ungefähr legt man es darauf an, Fehler zu produzieren. Wenn ein paar Testbytes korrekt zurück kommen heisst das noch lange nicht, dass das dann auch unter allen Umständen funktioniert.
Paul H. schrieb: > Kann man nicht einstellen beim mySmartUSB light, denn der probiert am > Anfang automatisch alle ISP Clocks durch und nimmt dann die > höchstmögliche. Dann versucht mySmartUSB da wohl, zu smart zu sein und ist es dann eben gar nicht mehr. Wenn du schon im Kontakt zum Hersteller bist, kann der ja vielleicht eine Firmware bereitstellen, bei der man die Geschwindigkeit manuell angeben kann.
Danke für jede Hilfestellung bisher! Falls ich es noch nicht erwähnt hatte: Ich habe auch schon eine Test"schaltung" mit einem nackten ATtiny2313 aufgebaut. Ohne jede Beschaltung außer dem ISP. Ich konnte da einige hex-files mit dem mySmartUSBlight draufflashen. Sobald ich jedoch das hex-file aus dem aktuellen Projekt draufflashe funktioniert das ISP nicht mehr. Zumindest nicht mehr mit dem mySmartUSBlight. Ich konnte das Verhalten mit mehreren Tinys und wiederholtem löschen/flashen wunderbar reproduzieren. Es liegt wohl am Programmer. Diese automatische Clock-Erkennung funktioniert nicht mehr, sobald ein gewisses hex-file im Tiny ist. In wie fern das aktuell geflashte Programm dafür relevant ist kann ich nicht beurteilen. Kanns mir auch schlecht vorstellen aber es scheint wohl so zu sein. Ich hake beim Hersteller noch mal nach. (Ach es sind übrigens natürlich 22p, nicht 22n. Hatte mich da wohl vertippt im Plan! Die 12V über 100k am AVR sind nun auch weg.)
stell mach mal die Startverzögerung auf den größten Wert ein, und Brownout abschalten oder sehr niedrig einstellen. Erst VCC anschließen und dann erst Reset aber den 100µF Elko am Resetpin parallel zu dem 100nF Kerko dieses nicht weglassen.
Danke aber.. Nein, ich sehs jetzt auch nicht ein, mir irgendwas um den ATtiny drum rum zu basteln, nur damit der mySmartUSB light auf Teufel komm raus damit funktioniert :D Entweder er tut es von sich aus, oder nicht. Mit der nackten ISP-Beschaltung hatte ich noch nie Probleme. Eine Reset-Beschaltung existiert auch in keiner meiner Schaltungen und alle laufen bisher problemlos. Ich warte mal ab ob der Hersteller des mySmartUSB light etwas an seiner Firmware ändern wird.
Thomas O. schrieb: > Brownout abschalten Keine gute Idee. Nicht selten fängt er dann bei Versorgungsspannungsverlust an, selbstständig den Flash zu überschreiben.
das sollte keine dauerhafte Lösung sein, sondern um den Fehler zu finden.
Paul H. schrieb: > Nein, ich sehs jetzt auch nicht ein, mir irgendwas um den > ATtiny drum rum zu basteln, nur damit der mySmartUSB light auf Teufel > komm raus damit funktioniert Spann das Ding in den Schraubstock und drehe langsam zu. Das ist das Beste, was man mit diesem Rotzding anstellen kann. Bau Dir dann einen AVRDOPER https://www.obdev.at/products/vusb/avrdoper.html und solche Quälereien gehören der Vergangenheit an. MfG Paul
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.