Liebe Mikrocontroller.net Forianer, in der letzten Zeit habe ich schon oft auesserst nuetzliche Informationen aus diesem Forum gezogen, und brauchte dafuer nichts weiter als die Suchfunktion. Leider stehe ich jetzt vor einem Problem, das sich so nicht loesen laesst. Ich habe schon bei vielen AVRs erfolgreich den Flash per ISP programmiert und hatte bisher nie Probleme damit. Dann bin ich zum Attiny841 gekommen, da die Features des Controllers sehr ueberzeugend fuer mich waren. Hier aber schlaegt das Programmieren und - wie es aussieht - sogar jegliche ISP-Kommunikation fehl. Ich nutze den USBProg 3 Programmierer dafuer. Angeschlossen sind die MISO,MOSI und SCK lines an den Anschluessen des Attiny, die als "default SPI" vom Datenblatt gekennzeichnet sind. Restliche Hardware ist bisher nicht verloetet, weil ich zunaechst den neuen AVR alleine testen wollte. Bisher habe ich folgende Dinge schon probiert: - SPI Geschwindigkeit auf ein paar kHz - 2 unterschiedliche, neue Tiny841 - 5V Betriebsspannung (urspruenglich 3.3V) - externe Clock an XTAL1 - AVR-Studio 6.2/5.1 - avrdude (mit Erweiterungen in der avrdude.conf Datei) - Bis 200nF zwischen VCC und GND - MISO und MOSI getauscht (Ausgaenge des Programmers sind mit 120 Ohm abgesichert) Mit all diesen Konfigurationen habe ich versucht die Device-ID auszulesen und den MISO Ausgang am AVR mit einem Oszilloskop beobachtet. Dort tat sich nichts. Beim Tauschen von MISO und MOSI zeigte am anliegenden Pegel, dass der "Ausgang" offensichtlich nicht mal als Ausgang geschaltet war, da er brav dem Programmer Pegel folgte, obwohl Reset auf low war. Daher spreche ich auch davon, dass offensichtlich die komplette Kommunikation fehlschlaegt. (Ich will aber nicht ausschliessen, dass es auch ein sehr "dummer" Fehler sein kann) Es koennte auch an dem Programmer liegen und ich haette kein Problem damit, mir einen original AVRisp mkII oder aehnliches zuzulegen (oder einen zu bauen, der nachweislich funktioniert), wenn es das Problem behebt. Denn ich werde viele der Tiny841 verbauen, weil sie fuer mein Projekt wie gemacht sind. Viele Gruesse und Dank im Voraus! Jan
Sicher dass du die richtigen Pins benutzt? Ich sehe im Datasheet 2 mal MISO, MOSI u d SCK.
Sende bitte deine deine genauen Anschlussbelegungen! Habe mehrere von den Attinys und noch keine Probleme mit gehabt.
Hallo, meine genaue Anschlussbelegung ist: Pin7: MOSI Pin8: MISO Pin9: SCK Pin4: RESET
:
Bearbeitet durch User
Jan K. schrieb: > Pin7: MOSI > Pin8: MISO > Pin9: SCK > Pin4: RESET Das ist erstmal korrekt. Aaaber: Ich würde mal darauf tippen, daß du das Teil einfach um 180° verdreht eingelötet hast, also in der Realität ganz andere Pins angeschlosen hast. Die Kennung für Pin1 ist nämlich nicht unbedingt trivial zu erkennen, denn leider hat längst nicht jede SOIC8-Charge die im Datenblatt versprochene eindeutige Orientierungsmarkierung am Package. Haben deine Exemplare diese Markierung?
den Punkt bei Pin1? War nicht besonders leicht zu erkennen, aber ich meine zumindest, das richtig gemacht zu haben. Ich werde es spaeter mal ansehen, es waere zumindest eine einfache Loesung...
So, es sieht so aus als waeren sie nicht verdreht. Dafuer spricht auch, dass der Reset Pin ohne weitere Beschaltung auf VCC liegt, der interne Pull-up funktioniert, also aller Wahrscheinlichkeit nach GND und VCC richtig angeschlossen sind. Ich hoffe, ich finde die Tage Zeit fuer mehr Tests.
Jan K. schrieb: > den Punkt bei Pin1? Nein. Ein Kerbe an der Schmalseite bei Pin1. Siehe Datenblatt Seite 2. Wenn diese Kerbe nicht vorhanden ist, gibt es garkeine mechanische Markierung. Die etwas größeren Punkte (eher Kreise) auf der Fläche, die manchmal zu sehen sind, sind keine Markierung, sondern Reste aus dem Fertigungsprozeß und sie liegen i.d.R. genau an der falschen Stelle. Wenn die eindeutige Markierung mit Kerbe nicht vorhanden ist, dann stellt allein der Aufdruck die gültige Orientierungsmarkierung dar. Wenn du den so ausrichtest, daß der Text lesbar ist, dann liegt Pin1 unten links.
> meine genaue Anschlussbelegung ist: > Pin7: MOSI > Pin8: MISO > Pin9: SCK > Pin4: RESET Gnd und VCC müssen auch angeschlossen werden. Gnd weil dies das gemeinsame Bezugspotential für alle Signale ist. Vcc deswegen, weil die Treiber des Programmers ihre Versorgungsspannung darüber beziehen (nicht vom PC USB port) (zumindest ist das beim Atmel ISP mkII so). Das war schon klar, oder? Hast du eventuell den Fehler begangen, den Reset Pin per Fuse zu deaktivieren? Ohne Reset funktioniert ISP nicht.
Hi, GND und VCC sind selbstverstaendlich angeschlossen - auch wenn der USBProg keine Verbindung zu VCC benoetigt, der Controller also auch extern betrieben werden kann (bei mir der Fall und Versorgungsspannung stabil, mache ich genauso bei vielen weiteren Boards, wo alles funktioniert). Der Reset Pin ist auch nicht (von mir) deaktiviert. Ich waere ja froh, wenn ich ueberhaupt irgendeine Kommunikation herstellen - geschweigedenn Fuses programmieren koennte. Was die Markierung betrifft, war ich von Datenblatt Seite 355 ausgegangen, wo eben jener Punkt erwaehnt wird. Allgemein war ich bisher davon sowieso ausgegangen, dass Punkte, Dreiecke, Einkerbungen immer Pin1 oder dessen Seite beschreiben. Aaaaber: Dein Kommentar mit der Schrift hat mich stutzig gemacht. Ich finde zwar keinen Aufdruck im Datenblatt, aber wenn die Schrift entsprechend der Zeichnung auf S. 355 aufgedruckt ist, dann waere Pin 1 oben rechts in der Zeichnung und ich haette den Controller tatsaechlich gedreht. Im Moment habe ich ihn so eingebaut dass Pin1 der Schrift nach zu urteilen unten links waere. Ich habe noch weiter geschaut und mein Aufbau sieht sehr aehnlich zu diesem hier aus, wo man das "ATMEL" erahnen und den Punkt klar sehen kann: https://d3s5r33r268y59.cloudfront.net/6183/products/thumbs/2014-03-18T21:30:27.383Z-IMG_9950.JPG.2560x2560_q85.jpg Dennoch, sollte sich keine andere Loesung finden, werde ich im Zweifel den Chip (genauer: einen neuen) also einmal anders herum einbauen. Koennte man ein "verbraten" beim falschen Anschliessen dabei verhindern? zB. durch einen Widerstand vor dem VCC Pin (O(100Ohm)) und dazu einen groesseren Abblockkondensator direkt am VCC Pin? Danke fuer die Hilfe bis jetzt
Hi >Dein Kommentar mit der Schrift hat mich stutzig gemacht. Ich finde zwar >keinen Aufdruck im Datenblatt, aber wenn die Schrift entsprechend der >Zeichnung auf S. 355 aufgedruckt ist, dann waere Pin 1 oben rechts in >der Zeichnung und ich haette den Controller tatsaechlich gedreht. Die Schrift ist kein Kriterum. SO-Gehäuse haben entweder einen Punkt oder/und eine stärker abgeschrägte Längskante. In der Zeichnung aus dem Datenblatt ist PIN1 rechts oben. MfG Spess
c-hater schrieb: > Nein. Ein Kerbe an der Schmalseite bei Pin1. Siehe Datenblatt Seite 2. Diese Darstellung sehe ich als eher symbolisch an - solche Kerben waren typisch für DIL. Interessanter ist die Darstellung auf Seite 355.
A. K. schrieb: > Diese Darstellung sehe ich als eher symbolisch an - solche Kerben waren > typisch für DIL. Interessanter ist die Darstellung auf Seite 355. Es mag gut sein, daß es auch die Variante von Seite 355 gibt, aber sehr häufig ist sie wohl nicht. Wir haben jedenfalls bisher etwa 1000 Stück verarbeitet, davon waren ca. 2% mit einer Kerbe gekennzeichnet, wie sie auf Seite 2 zu sehen ist. Die sieht tatsächlich aus, wie man das von DIL kennt, ist aber natürlich viel kleiner und auch weniger tief als bei DIL, die Proportionen bzgl. des Gesamtgehäuses entsprechen aber ziemlich exakt der Zeichnung auf Seite 2. Diese ist also ganz sicher nicht nur symbolisch gemeint. Der ganze große Rest aber hatte gar keine mechanische Markierung, weder die Mulde (man beachte die Schnittdarstellung, ebenfalls auf S.355 zu finden!), noch die ebenfalls oft bei SOIC verwendete Phase an der Längsseite. Aber bei allen Exemplaren war durchgängig die Schrift so ausgerichtet, daß Pin 1 unten links ist. Und das scheint auch durchaus eine übliche Variante zu sein, jedenfalls lassen sich zahllose Verweise darauf ergoogeln.
Jan K. schrieb: > Der Reset Pin ist auch nicht (von mir) deaktiviert. Ich waere ja froh, > wenn ich ueberhaupt irgendeine Kommunikation herstellen - geschweigedenn > Fuses programmieren koennte. Kannst du bei deinem Programmer die SPI Clockrate einstellen? Die muss ja bekanntlich kleiner sein als der Clock vom Controller. Ist der Controller von Auslieferungszustand auf einen (langsamen) internen Clock eingestellt dann gibt es da eine Stolperfalle ....
Der Controller sollte auf 1MHz laufen im Auslieferungszustand, daher habe ich mit den Standard 125kHz angefangen. Dennoch habe ich (so ziemlich als erstes) auch deutlich langsamere Frequenzen probiert bis hinunter zu ein paar kHz und diese dann fuer weitere Tests auch beibehalten.
Ist denn der Attiny841 auf der Liste der von deinem Programmer unterstützten Controller ?
Vielen Dank fuer die Vorschlaege bis jetzt. Die "Liste" der unterstuetzen AVRs ist etwas problematisch zu bekommen. An sich hatte ich gehofft, der USBProg3 als AVRISP mk II Clone konfiguriert sollte mit dem Tiny arbeiten koennen. Ich habe auch mal kurz in die Note von AVR zum ISP Protokoll hereingeschaut und zumindest die Device-ID Abfrage scheint recht standardisiert zu sein. Was mich daher wundert ist, dass ich absolut ueberhaupt keine Reaktion von dem Tiny bekomme (ob der Programmer damit etwas anfangen koennte sei dahingestellt). Aber wie gesagt - wenn es klar durch einen anderen Programmer behoben werden kann, beschaffe ich mir einen. Ich waere nur gern sicher. Eine Idee: Wenn jemand die paar (Ich glaube 4) Bytes Sequenz, die ein erwiesenermassen kompatibler Programmer an den Tiny841 gibt zur ID Abfrage kennt oder schnell mitschneiden koennte, wuerde ich die einfach mal per "Hand" mit heruntergezogenen Reset und geclockter SCK an den Tiny geben und auf die Reaktion an MISO schauen.
Jan K. schrieb: > Aber wie gesagt - wenn es klar durch einen anderen Programmer behoben > werden kann, beschaffe ich mir einen. Ich waere nur gern sicher. Aus den Symptomen und deiner Beschreibungen ergibt sich für mich ein Gesamtbild dass der Programmer nicht mit dem Tiny funktioniert. Vermutlich hat dein Tiny eine neuere StateMachine für die ISP Programmierung die nicht mit den alten Mechanismen kompatibel ist. Für ca 39.80 Euro bekommst du einen Atmel ISP Adapter MKII mit dem eigentlich wirklich alles an AVR geht was denkbar ist. Und das lohnt sich wirklich!
isidor schrieb: > Aus den Symptomen und deiner Beschreibungen ergibt sich für mich > ein Gesamtbild dass der Programmer nicht mit dem Tiny funktioniert. > Vermutlich hat dein Tiny eine neuere StateMachine für die ISP > Programmierung die nicht mit den alten Mechanismen kompatibel ist. Nö. Aus den Symptomen ergibt sich daß der Tiny überhaupt nicht reagiert, nicht auf subtile Art falsch wie Du vermutest sondern gar nicht. @Jan: * Hast Du nur ein einziges Exemplar, ist es vielleicht schon zu einem früheren Zeitpunkt verstorben? * Reduziert der Programmer tatsächlich die Taktrate oder gibt er nur vor das zu tun in einem verzweifelten Versuch kompatibel zu wirken? Von einem AvrISP2 rate ich übrigens ab, das ist rausgeworfenes Geld, da würde ich eher in der selben Preisklasse einen Diamex-ALL empfehlen, der ist 100% kompatibel, außerdem anscheinend unzerstörbar (selbst nicht durch meine weithin bekannte Schusseligkeit und das will was heißen), und er kann ein Target direkt mit 5V oder 3.3V versorgen und (das ist der Killer) führt nicht wie der Avrisp2 jedesmal 1 Sekunde nach(!) dem Einschalten von VCC einen Reset durch (sehr nervig wenn man In(!)-System-Programming macht und für viel mehr kann man ihn ja nicht vernünftig verwenden mangels eigener Versorgung eines Targets. Der Avrisp liegt hier in der Ecke und ist arbeitslos seit Monaten, der Diamex-ALL arbeitet jeden Tag und wird nicht müde. Die nächste Stufe wenn Du wirklich Geld in die Hand nehmen willst (also wenn schon dann richtig) wäre ein JtagICE, dann kannst Du auch die Debugfunktionen verwenden, das wäre ein gültiges Argument (das einzige) für ein Orginal-Atmelteil.
:
Bearbeitet durch User
Hallo, ich werde noch mal einen weiteren ausprobieren.. Ein paar Stueck habe ich noch herumliegen. Vielleicht habe ich auch zwei Montagsmodelle erwischt oder ich hab einen/zwei beim Einloeten verbraten. Das waere zwar das erste mal, aber man weiss ja nie. Die Taktrate ist sicher heruntergeregelt, ich messe meist SCK und MISO mit nem Oszi durch (manchmal einen MOSI check), weil ich verzweifelt auf ein Lebenszeichen des Tiny warte. Die Clock liegt ganz klar im kHz-Bereich. Falls ich mir einen anderen Programmer zulegen sollte, denke ich gerade ueber den Atmel ICE basic nach, der hat dann entsprechende debug-Funktionen auch gleich drin. Vielleicht finde ich morgen noch mal Zeit der Sache weiter nachzugehen, ich werde es wohl noch mit einem dritten Chip probieren. Verflixte Sache… Viele Gruesse
Bernd K. schrieb: > Nö. > > Aus den Symptomen ergibt sich daß der Tiny überhaupt nicht reagiert, > nicht auf subtile Art falsch wie Du vermutest sondern gar nicht. Ich habe geschrieben "...ergibt sich für mich" und nicht was du geschrieben hast. Was sich für mich ergibt kannst du weder wissen noch entscheiden. Daher ist dein "Nö" in diesem Zusammenhang sinnlos.
Wie sieht denn dein Aufbau aus? Ich hab mich mit dem ATtiny841 mal super ausgetrickst. Hatte nur ein 16-Pad-SO-nach-16-Pin-DIL-Adapterboard zur Hand. Also bleiben beim Auflöten an einem Ende Pads/Pins unbenutzt. Beim Breadboard-Aufbau hab ich die Pins 7, 8 und 9 einfach vom Ende des 16-Pin-Adapters gezählt, schließlich hat man doch im Kopf, wo beim 14-Pinner die Pins 7 und 8 liegen. Hat eine Weile gedauert, irgendwann ist dann der Groschen gefallen.
Hallo Konrad, meine Platine hat genau Platz fuer die Tiny841 Pins. Nicht mehr und nicht weniger. Welchen Programmer benutzt du?
Jan K. schrieb: > Welchen Programmer benutzt du? AVRISP mkII. Ich glaube aber nicht, dass da das Problem liegt.
Ich habe es nicht lassen koennen… und noch einen dritten Chip ausprobiert. Leider wieder ohne Erfolg. Dafuer habe ich aber sehr genau den Punkt bei Pin1 sehen koennen, die abgeflachte/angefaste Seite bei Pin1 und sogar ein kleines Dreieck bei Pin1. Somit schliesse ich mittlerweile ein Verdrehen als Ursache aus. Die sonstige Testkonfiguration: AVR Studio 6.2 SPI Speed: 2.1 kHz VCC: 5V C direkt zwischen VCC udn GND Pins: 470nF ->Wieder null Reaktion an MISO. Aufgefallen ist mir aber etwas neues: Beim Untersuchen des Reset-Signals ist mir aufgefallen, dass der Programmer von high kommend einmal ein low-high-low Signal ausgibt (auch im kHz Bereich). Das selbe tut er auch, wenn er denkt, er habe zB einen Attiny84 (ohne 1) vor sich. Ich weiss nicht inwieweit das von Belang ist, aber koennte sich der 841 davon irgendwie gestoert fuehlen? Auch wenn es vllt nicht der Grund ist, werde ich mir wohl mal einen ICE debugger zulegen. Zumindest liesse sich dann eine moegliche Fehlerquelle mehr einschraenken. Unabhaengig davon finde ich den fuer den Preis sowieso ansprechend. Vielen Dank bis jetzt
c-hater schrieb: > Es mag gut sein, daß es auch die Variante von Seite 355 gibt, aber sehr > häufig ist sie wohl nicht. Meine Exemplare haben das Loch jedenfalls.
Bernd K. schrieb: > Von einem AvrISP2 rate ich übrigens ab, das ist rausgeworfenes Geld, da > würde ich eher in der selben Preisklasse einen Diamex-ALL empfehlen, der > ist 100% kompatibel Kennt der den Tiny841? Die Herstellerinfo erwähnt ihn nicht und mit dem STK500 geht es zumindest mit Atmels Werkzeugen nicht.
Hallo, mittlerweile hatte ich ein wenig Zeit dem ganzen weiter auf den Grund zu gehen. Zunaechst habe ich mir den Atmel ICE zugelegt. Auch wenn es nicht am Adapter zu liegen schien, habe ich schon lange mit dem Gedanken gespielt, mir einen debugger zu besorgen und jetzt einfach die Gelegenheit genutzt. Nun habe ich noch mal von null angefangen, neuen Tiny inkl. Stromversorgung usw eingeloetet, mit dem Atmel ICE verbunden. Und: Es klappt. Mit den "alten" funktioniert aber auch der Atmel ICE nicht und zeigt das selbe Verhalten. Entweder waren die also alle defekt, sie wurden von mir kaputt gebraten, oder sonstige Probleme beim Loeten sind aufgetreten, und das gleich bei 3 Stueck. Das waeren dann die ersten 3 SMD Bauteile von sehr vielen, die ich verbraten haette - ich untersuche das aber spaeter. Also: Danke fuer die Hilfe und hoffentlich hilft der Thread hier in Zukunft mal irgendjemandem. Gruss
Hallo Jan, gibt es etwas neues zu diesem Thema? Hast du das vom ICE erzeugte Reset Signal mit dem des USBProg3 verglichen? Kannst du nach erfolgreichem Programmieren mit dem ICE wieder den USBProg3 verwenden? Ich habe hier zwei ATtiny441 welche nach einem Programmierversuch mit dem USBProg3 in allen Einzelheiten das von dir beschriebene Verhalten zeigen. Viele Grüße
Den Effekt eines floatenden MISO Signals konnte ich auch beobachten, nachdem die Fuses auf externen Quarz gesetzt waren. Dann war Schluss mit dem avrdude und das DSO zeigte ein ziemlich floatendes MISO Signal. Als ich mit dem Dragon die Fuses wieder auf R/C-Oszillator setzte, war er wieder durch avrdude ansprechbar. Vermutung: Der 841 hat eine etwas von den Vorgängern abweichende Taktversorgung, weil er seine Taktquelle selber setzen kann. Das könnte das ISP-Verhalten unmittelbar nach fallender Reset-Flanke ändern und manche Programmer in die Röhre gucken lassen, beispielsweise weil der Oszillator neu startet oder erst nach einer Totzeit freigegeben wird. Und ohne Takt funktioniert ISP bekanntlich nicht. Der avrdude liess sich durch Einbau einer entsprechenden Wartezeit anpassen: Beitrag "ATtiny841 per AVRDUDE auf Rasberry Pi programmieren"
:
Bearbeitet durch User
Jan K. schrieb: > Aufgefallen ist mir aber etwas neues: Beim Untersuchen des Reset-Signals > ist mir aufgefallen, dass der Programmer von high kommend einmal ein > low-high-low Signal ausgibt (auch im kHz Bereich). So steht das im Datasheet auch drin. Siehe 23.3.2 Seite 227.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.