AVR Fusebits

Jan Pietrusky schrieb:

Für Ponyprog kann ich nicht sprechen, mit AVRDUDE habe ich da nie Probleme gehabt.

Du kannst CKDIV8 auch lassen, wie sie ist, und das CLKPR-Register zur Laufzeit ändern.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Hallo!

Guck doch mal auf die Seite:

Da ich jetzt immer das AVRStudio und das STK500 zum programmieren nehme, habe ich keine Probleme. Früher hab ich auch Ponyprog benutzt und die Fusebits fand ich verwirrend. Ist im AVRStudio besser gemacht.

alsdenn, Jens

Moin!

Oder man setzt aus Versehen den Reset Disable oder löscht den SPI Enable, das bekommt man nichtmal mehr mit externem Takt wieder hin, nur noch mit nem HV-Parallel-Programmer.

Das Problem mit Ponyprog ist, daß man schnell die Übersicht verliert, da Ponyprog IIRC Häkchen für Fusebit=0 setzt.

Ich persönlich schreibe mir die Werte für die Fuses lieber in aller Ruhe aus dem Datenblatt zusammen und nehme dann AVRDUDE. Das arbeitet auch mit der Ponyprog-Hardware zusammen und geht dann so:

avrdude -p t2313 -c pony-stk200 -U hfuse:w:123:m -U lfuse:w:465:m (Natürlich mit Deinen eigenen Werten und bei Bedarf noch efuse)

Es gibt dafür auch diverse GUIs, bei denen Du nur noch sowas wie "Quarz >8MHz" auswählen brauchst und die AVRDUDE dann mit den korrekten Fusebits dafür aufrufen:

Gruß, Michael.

Wie gesagt, ich habe mir die Werte schon vorher angeschaut. Meine ersten AVR-Versuchen vor Jahren haben mich da schon sensibilisiert. Das Problem ist aber, ich habe ja nur die Flags nach dem Auslesen für den Takt geändert. Wenn ich jetzt die Bits auslese, kommen entweder beide Fehler (24 bzw. 25) oder der Ponyprog ließt schrott aus (3Versuche, 3Ergebnisse).

Der Tipp mit dem CKDIV im nachhinein ändern, ist gut (nur grad zu spät). AVR Dude werd ich mal testen.

Danke schon einmal, Jan

Michael Eggert wrote:

Hallo Jörg Teste grad den AVR Dude, allerdings nicht mit Erfolg. Ich habe einen einfachen ISP Adapter (aus dem Pollin AVR Board). Wenn ich da ein serielles ISP auswähle (Siprog, Ponyser) bekomme ich "can't set buffer for LPT1"

Viel falsch machen kann man eigentlich nicht, oder?

Zum ändern der Register, kann man auch während der Laufzeit die Taktquelle ändern? Ich glaub es zwar nicht, aber ne Frage ist es wert ;-) Im Datenblatt (ATtiny2313) hab ich allerdings nichts finden können.

Jan

Joerg Wunsch wrote:

Du hast es ja vermutlich auch nicht an LPT1 angeschlossen, oder? ;-)

Nimm -P com1.

Bein klassischen AVR lässt sich die Quelle zur Laufzeit nicht ändern (der Xmega kann es wohl), nur der Vorteiler.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Hallo Jörg, das mit -P com1 hab ich dann auch gefunden. Trotzdem danke. Hab mehr im avrdude.conf File nach der Lösung gesucht.

Jan

Joerg Wunsch wrote:

Also ich hab mich, nachdem nun der avrdude funktioniert, doch an die Fusebits gewagt. Prinzipiell bestätigt das meine Ahnung und deckt sich auch mit den Ponyprogausgaben.

avrdude -P com1 -p t2313 -c ponyser -U lfuse:w:0xEF:m

avrdude: Device signature = 0x1e9122 avrdude: Expected signature for ATtiny2313 is 1E 91 0A Double check chip, or use -F to override this check.

Diemal geht aber mein Programm, ich kann nur nicht mehr drauf zugreifen. Aus der seriellen Ausgabe und dem Wackeln meiner LED schließe ich daraus, das die richtigen Fusebits gesetzt wurden.

Ich werd mal Atmel zu dem Thema befragen.

Grüße, Jan

Jan Pietrusky wrote:

Jan Pietrusky schrieb:

Probier mal noch zusätzlich die Option -i10.

-- cheers, J"org .-.-. --... ...-- -.. . DL8DTL

NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

=20

Dass kenn ich. Ich hatte das bei meiner ersten Eigenentwicklung mit nem AT2313 auch. Die Massef=C3=BChrung auf der einlagigen Lochrasterplati= ne war so mies, dass er bei nicht durch acht geteiltem Takt prellen auf der SPI-Clock-Leitung gesehen hat. Da mir der Takt mit CLKDIV8 gereicht hat, habe ich dann CLKDIV8 dringelassen. Jetzt stecke ich AT2313er nur noch in IC-Sockel mit Abblockkondensator.

Oszilloskopier erst einmal den Pegel am GND-Pin gegen GND am Programmieranschluss. Ich hatte da Peaks >1V drauf.

Gru=C3=9F, Michael Karcher

Also ich geb ja zu, meine Abblockung hätte besser sein können, aber ändern tut sich nichts an den Auswirkungen. Werden die AVR aber nicht eh im Resetmodus programmiert?

So, hab nun ein wenig wenig mit dem Oszi Fehlergesucht. Das Problem ist die MOSI-Leitung. Hier werden die ersten 2 Byte irgendwie niedergehalten. Da scheint intern was gegeneinander zu treiben. Danach sind die Takte und MOSI Signale top (bin auf einen 200ns Glitch am Ende einer Taktflanke. Da hier zwischen dem MISO Signal und der Seriellen Schnittstelle nix ist, worauf ich Einfluss hätte und beide Programmer sonst gingen und das gleiche Ergebniss bringen, warte ich mal, was Atmel sagt.

Bei Interesse kann ich die Oszibilder auch mal zur Verfügung stellen, falls jemand Interesse hat.

Falls ich doch noch etwas übersehen hab, bin ich für jede Rückmeldung dankbar.

Danke aber schonmal für eure Hilfe, Jan

Michael Karcher wrote:

Das paßt allerdings überhaupt nicht zu einigen Aussagen, die du in deinen bisherigen Postings in diesem Thread getätigt hast. Z.B. die Sache mit den Signaturbytes. Da sind ja gerade die ersten zwei Bytes korrekt gelesen worden, erst das dritte war Müll.

Im übrigen habe ich hier zufällig gerade drei gleiche Module mit 2313 in der Mache, die sich mit der Primitivst-Schaltung vom Pollinboard als Hardware und Ponyprog als Software problemlos programmieren lassen. Die laufen allesamt ohne programmiertes CKDIV-Bit.

Ein grundsätzliches Problem beim 2313 würde ich also ausschließen. Natürlich wäre es denkbar, daß es defekte Chargen gibt. Aber doch einigermaßen unwahrscheinlich.

Tip: Mal das Resetsignal überprüfen und zwar direkt am ATtiny-Beinchen. Ich könnte fast wetten, daß das während des Programmierens nicht dauerhaft auf Low ist.

Genau. Das passt irgendwie zusammen. Ist vieleicht ein Kondensator an Reset der das Pin für die ersten 2 Byte inakiv hält?

Die Resetzeit sollte sich aber einstellen lassen. Bei avrdude und uisp geht das jedenfalls. Auch ein permanentes halten von Reset ist möglich.

--
MFG Gernot

Das Reset ist sauber,die Spannung auch. Wenn beide Unsauber wären, könnte ich das Ding dann evtl. gar nicht programmieren oder alle Signale würden unsauber aussehen. Das ist aber nicht der Fall.

In dem Fall, den ich weiter oben beschrieb, waren auch die ersten beiden Byten in Ordnung. Stellenweise wird aber auch eine komplett falsche ID rurückgelesen. Meist aber stimmt der Anfang. Wie gesagt, die ersten Bytes (die ich gemessen habe) sehen so aus, als ob da Treiber gegeneinander treiben. Danach sehen die top aus.

Ich würde Dir ja gern zustimmen, aber grad an der MISO Leitung liegt zwischen dem Ausgang 2313 und dem Eingang serieller Schnittstelle nix, was darauf Einfluss haben könnte. Das ist hart durchverdrahtet und ich nutze den Port für nichts anderes. Der Programmer ist der gleiche wie der vom Pollinboard und damit war ich auch immer zufrieden.

Intessanterweise habe ich im Oszibild von MISO noch einen Spike an einer Taktflanke H->L von exakt 2 Prozessortaktzyklen (~180ns Quarz

11,0592MHz). Der gehört mit Sicherheit auch nicht da hin und liegt in einem Bereich, wo die Signale sonst gut aussehen. Die ISP Takte sind im µs Bereich.

Wenn ich den Oszi hab, dann nehme ich nochmal die MOSI Signale auf. Das hab ich gestern vergessen.

Jan

Heiko Noc>

Unter

im Beispielordner habe ich mal die Oszibilder hinterlegt.

Nicht von den Namen verwirren lassen,

Gelb ist RESET, Grün ist MISO, Violett ist SCK

Jan

Heiko Noc>

Wie genau gemessen? Wo genau Signal abgegriffen?

Da würde ich nicht darauf wetten. Hast du dir schonmal die Eingangsbeschaltung PC-üblicher Pegelkonverter angesehen? Und mal abgesehen davon liegt sehr wohl etwas dazwischen, nämlich das Kabel. Auch hierin könnten Fehler entstehen.

Doch. Den sehe ich auch. Habe ich an jeder Bytegrenze. Übrigens nicht nur beim Programmieren, sondern auch bei der normalen Benutzung als SPI-Schnittstelle. Das sollte nicht stören, denn der SPI-Takt (und auch der Programmiertakt) liegen ja weit darunter. Der nächste Punkt für's Sampling ist frühestens zwei Takte später erreicht (bei Maximalfrequenz für den SPI), beim Programmieren noch viel später. Wenn du glaubst, daß es daran liegt, dann schalte einen 10n nach Masse, der schluckt den Spike weitgehend und sollte das Programmieren ebenfalls nicht stören.

Die kannst allenfalls du selbst dir ansehen. Und das auch nur, wenn du deinen Browser zwischenzeitlich nicht geschlossen hast...

Sorry, da ging da wohl was in die Hose (ich hab über GMX auch noch keine Bilder veröffentlicht)

Also nochmal, vom Kollegen getestet

Zu der Frage wegen der Kabel, da wären ja wohl alle Bytes betroffen, nicht nur zwei. Ein ähnliches Fehlerbild hatten wir derletzt in einem CPLD von Lattice. Da haben zwei Treiber gegeneinander gearbeitet. Nachdem das unterbunden wurde, gingen die Signale.

Jan

Heiko Noc>

Funktioniert.

Über die Bilder muß ich erstmal etwas grübeln (und mir aus den bisherigen Postings die Informationen zusammensuchen, welches Signal eigentlich was ist).

Aber was mir schon beim ersten Blick auffiel: Da sind auf allen Signalen mindestens 0.3, eher was bei 0.5V Ripple (hatte noch keine Zeit das richtig auszumessen, ist eine "frei Auge-Schätzung"). Viel zu viel für Quantifizierungsrauschen der AD-Wandler.

Also wo kommt der Scheiß her? Bei mir ist Low tatsächlich 0+-0.01V, d.h. selbst auf fast voller Oszischirm-Höhe für die 5V Hub des Nutzsignals muß ich mich sehr anstrengen, um überhaupt Ripple zu sehen.

Ich würde also nach diesem ersten Blick auf einen Defekt in der Stromversorgung tippen. Die Frage ist bloß, ob bei der Probe oder beim Meßgerät. Wenn nicht das, dann ist aber ganz sicher zumindest der Meßaufbau Scheiße (schlechte Masseverbindung oder sowas).