usbasp firmware update

[flecralf]

Moin,
hab' gerade wieder mal einen ATtiny13a unbrauchbar gemacht in dem scheinbar einen falschen Parameter benutzt habe.
Nun schreiben einige, dass dies an den Fuses liegen könnte und ich die Geschwindigkeit mit der Option -B 600 mal runterdrehen sollte.

Dann bekomme ich allerdings die folgende Meldung:
avrdude: warning: cannot set sck period. please check for usbasp firmware update

Frage:
Was benötige ich zum flashen ?
Es gibt zwar gefühlt 1000 Artikel darüber, aber ich bleibe immer an einer Sache hängen.
Wie soll ich das Ding beschreiben...
Es handelt sich um einen ATMEGA8a und auf der Platine steht HEX c229860

Wen ich es richtig verstehe, benötigt man dafür doch ein weiteren Programmer, oder ?
Oder kann ich den Programmer selbst über den usb-Port flashen ?

Wegen dem Attiny13a: Zum Tiny kann ich keine Verbindung mehr aufbauen.
Der Programmer funktioniert aber noch an anderen Avrs.

Gruß
Ralf

 

[dino03]

Hallo Ralf,

Dann bekomme ich allerdings die folgende Meldung:
avrdude: warning: cannot set sck period. please check for usbasp firmware update

arbeitest du unter Linux oder Windows?

Also den Tiny13 wirst du wohl nur bei den Fuses verdreht haben. Entweder der Prozessortakt was sich einfach mit nem externen Oszillator beheben läßt oder schlimmer den ISP-Port oder Reset-Pin abgeschaltet. Das geht dann nur über HV-Programmierung (Dragon oder STK500/STK600).

Auf jeden Fall kannst du einen Mega8 nicht über USB direkt flashen. Du brauchst auf jeden Fall immer einen Progger dafür. Über USB oder eine andere Schnittstelle geht das nur wenn bereits jemand einen Bootloader reingeflasht hat. Dann benötigt man aber nicht ARVDUDE zum programmieren sondern ein Programm was den Bootloader mit dem zu flashenden Programm versorgt. Das kann zB eine extra Anwendung des Anbieters sein oder im einfachsten Fall einfach ein Terminalprogramm wie zB PuTTY, TeraTerm oder anderes.

Wenn du einen Atmel bekommst, dann ist das immer ein hirnloses Stück Silizium. Der macht von sich aus nix außer Strom verbrauchen. Wenn man also nicht irgendwas mit einem Progger reinflasht dann regt der sich für keine fünf Pfennig. Wenn man sich also wie in den ganzen Internetbeiträgen beschrieben mit nem Atmel einen eigenen Progger bauen will, dann hat man das Henne/Ei-Problem (oder das mit dem Hund der sich in den Schwanz beißt).

Gruß
Dino

 

[flecralf]

Hallo Dino,
Danke für die Info.
Hab' jetzt einen 8 Mhz Quarz zwischen PB3 und PB4 gelegt. Jeweils 27p gehen auf Masse.
Es regt sich mit avrdude nichts.
Ich müsste es ihm ja nun mitteilen, dass er nun auf Extern umschalten soll, oder ?
avrdude -c usbasp -p t13 -U lfuse:w:0x68:m -U hfuse:w:0xff:m
Korrektur:
Quarz von PB3 in Reihe mit 100p nach Masse.

Gruß
Ralf

 

[LotadaC]

Der externe Takt greift doch aber nur, wenn der Controller auch per Fuses (ggf unbeabsichtigt) auf eine externe Taktquelle eingestellt wurde. Wenn also ein interner Oscillator aktiv ist (und der Pin I/O oder sonstige Hardware), bringt das nichts. Problematisch kann das werden, wenn eine sehr langsame Taktquelle gewählt wurde (zb der 128kHz Oszillator - besonders wenn anschließend der SystemClockPrescaler noch weiter teilt), und dann die maximal erlaubte ISP-Frequenz durch den Programmer nicht mehr erreicht werden kann. Das paßt mMn zu "cannot set SCK period".

P.S.: streng genommen steht in jedem neuen AVR AVR ein lauffähiges Programm... es lautet:

NOP
NOP
NOP
NOP
...

es macht bloß nicht so viel sinniges

Nachtrag zu letzten Beitrag: Nein, kein Quarz - ein aktiver Takt<-nee...
Wozu wolltest Du jetzt an einen Mega8 einen Quarz hängen? reanimieren meinst Du nicht, Du kannst ja noch drauf zugreifen, oder?

 

[flecralf]

Der externe Takt greift doch aber nur, wenn der Controller auch per Fuses (ggf unbeabsichtigt) auf eine externe Taktquelle eingestellt wurde. Wenn also ein interner Oscillator aktiv ist (und der Pin I/O oder sonstige Hardware), bringt das nichts. Problematisch kann das werden, wenn eine sehr langsame Taktquelle gewählt wurde (zb der 128kHz Oszillator - besonders wenn anschließend der SystemClockPrescaler noch weiter teilt), und dann die maximal erlaubte ISP-Frequenz durch den Programmer nicht mehr erreicht werden kann. Das paßt mMn zu "cannot set SCK period".

P.S.: streng genommen steht in jedem neuen AVR AVR ein lauffähiges Programm... es lautet:

NOP
NOP
NOP
NOP
...

es macht bloß nicht so viel sinniges

Nachtrag zu letzten Beitrag: Nein, kein Quarz - ein aktiver Takt<-nee...
Wozu wolltest Du jetzt an einen ega8 einen Quarz hängen? reanimieren meinst Du nicht, Du kannst ja noch drauf zugreifen, oder?

Genau das habe ich befürchtet. Ja, er steht auf intern und Dank verdrehtem FuseBitMuster auf 128khz. ;-)
Außerdem ist meine Schaltung falsch, da er nur 1 ClkEingang hat.

Gruß
Ralf

 

[LotadaC]

Hmm... welche Frequenz kannst Du denn mit Deinem Programmer und der Programmierumgebung noch angeben?
Selbst mit 'nem durch 8 geteilten 128kHz-Takt, liegt man ja bei 16kHz MCU-Takt. wie war das nochmal mit der max. ISP-Frequenz? Ein viertel davon?

Kannst Du Dich an die eingestellten Fusebytes erinnern/hast Du sie notiert?

P.S.: hier hat ein User den AVRISP-MKII nach eigener Angabe auf 100 Hz runtergesetzt - der kann das also (scheinbar)

 

[dino03]

Hi Ralf,

Danke für die Info.
Hab' jetzt einen 8 Mhz Quarz zwischen PB3 und PB4 gelegt. Jeweils 27p gehen auf Masse.
Es regt sich mit avrdude nichts.

ich hab ja auch Oszillator geschrieben und nicht Quarz
Ein Oszillator erzeugt selber einen Takt (zB nen Funktionsgenerator oder diese Blechkisten mit Quarzoszillator drin).
Damit zwingt man der internen Taktschaltung den Oszillatortakt auf. Egal was du an den Takt-Fuses eingestellt hast. Entweder rennt er dann mit dem internen Takt (dann hätte er sowieso funktioniert) oder wird von außen zwangsversorgt.

Gruß
Dino

 

[LotadaC]

Notfalls (und wenn man etwas masochistisch veranlagt ist) kann man 'nen AVR auch zu Fuß programmieren.

Ohne Programmierumgebung.

Ohne Programmer.

Nur mir 2 Tastern (meinetwegen auch Drahtstückchen) und etwas Entprellung.

(fehlt eigentlich auch noch in Dinos Minimalbeschaltungs-FAQ-Thread)

 

[flecralf]

Hmm... welche Frequenz kannst Du denn mit Deinem Programmer und der Programmierumgebung noch angeben?
Selbst mit 'nem durch 8 geteilten 128kHz-Takt, liegt man ja bei 16kHz MCU-Takt. wie war das nochmal mit der max. ISP-Frequenz? Ein viertel davon?

Kannst Du Dich an die eingestellten Fusebytes erinnern/hast Du sie notiert?



P.S.: hier hat ein User den AVRISP-MKII nach eigener Angabe auf 100 Hz runtergesetzt - der kann das also (scheinbar)

Wenn ich die fehlerhaften avrdude Parameter rückwärts verfolge auf 128 k zu kommen.

 

[flecralf]

Hi Ralf,


ich hab ja auch Oszillator geschrieben und nicht Quarz
Ein Oszillator erzeugt selber einen Takt (zB nen Funktionsgenerator oder diese Blechkisten mit Quarzoszillator drin).
Damit zwingt man der internen Taktschaltung den Oszillatortakt auf. Egal was du an den Takt-Fuses eingestellt hast. Entweder rennt er dann mit dem internen Takt (dann hätte er sowieso funktioniert) oder wird von außen zwangsversorgt.

Gruß
Dino

Generator habe ich hier, schafft 200 kHz
Hab das Ding an Pin(2?) dem Clk-Eingang gelegt.
Hat aber nichts gebracht. Hab mir gerade 5 Stück im Dip-Gehäuse besorgt.
Der "verstimme" Attiny13a ist allerdings einer im Soic8 Gehäuse auf einem Experimentier-Board, ist halt zum Löten
ein wenig unbequem. Muß halt die LadyLötspitze an die Weller und sehe danach wieder 2h Stunden schlecht...
Gruß
Ralf
P.S
Das war der 4 AVR in 2 Wochen, 2x Überspannung auf'em ADC und 2x FuseBits -> Anfängerglück

 

[LotadaC]

Wie gesagt, der externe (aktive) Takt über den Generator bringt Dir nur was, wenn der Controller auf eine Externe Betaktung gefused ist - da allerdings ist egal welche. Wenn die Fuses auf intern stehen, ist das Bein nicht an den Takt (intern) gekoppelt. Allerdings läuft er ja dann mit dem (eingestellten) internen Takt. Du sagst, der 128kHz ist gewählt - zu den anderen Bits schreibst Du aber nichts. Dein Tiny besitzt ein I/O-Register welches den Vorteiler für den Systemtakt festlegt. Dieses kann durch dein Programm zur Laufzeit (ist ja ein I/O-Register) umgeschrieben werden (Du kannst damit also zur Laufzeit den effektiven Takt ändern). Dieses Register wird beim Reset mit 0 (Prescaler=1) oder 3 (Prescaler=8) initialisiert - je nachdem, ob die CKDIV8-Fuse programmiert ist, oder nicht. Beim Start kann der Takt also entweder nicht (bzw durch 1) oder durch 8 geteilt werden - deswegen der Name. Wenn also der 128kHz Oszi und die CKDIV8 zusammenkommen, landest Du bei einem internen Takt von 16kHz, und darfst nur noch mit 4kHz ISP-Frequenz programmieren. Höchstens. Weniger ist kein Thema (siehe meinen Link da oben).

Die SPIEN-Fuse kann man via ISP gar nicht manipulieren, hier kann man sich also so gar nicht aussperren.
Aber die RSTDISBL-Fuse ist gefährlich, da man hiermit den Reset-Pin von der Resetlogik abkoppeln kann, somit über keinen Pin mehr einen Reset erzwingen (und halten) kann, und folglich den Controller nicht in den (ISP-SPI) Programming-Mode schicken kann.

Kannst Du irgendwie die übertragenen (kompletten) Fusebytes rekonstruieren, und hier angeben?

 

[flecralf]

Hallo alle zusammen,
so heute wieder mal Zeit für'n AVR.
Der Tiny13 läuft wieder !
Mit dem usbasp-Programmer habe ich humorlos einfach eine neue Flashsoftware in einen ATmega8 geschossen, welcher sich
auf einem Experimentierboard befindet.
Dann nutzte ich dieses Board zum Verändern der FuseBit des Attiny13a.
Es hat ein wenig gedauert bis die Zeiten gestimmt haben.
Aber dann erinnerte ich mich an den Teiler von 8. (Dirk erwähnte es vor kurzem)
Nun stimmen auch die Zeiten wieder.

_delay_ms(1000) sind wirklich 1s auch bei F_cpu = 128 kHz !

Für batteriebetriebene Geräte wäre ja Stromsparen schon eine wichtige Option.
Also wäre es doch sinnvoll den Takt soweit wie möglich runter zubringen, oder ?
Für Temperaturmessungen benötigt man schließlich keine 4,8 MHz.



Gruß
Ralf

P.S
Leider habe ich es nicht geschafft den atmega8 auf dem "richtigen" Programmer zu flashen.
Da kommt die Meldung fuses = 1 o.ä.

 

[LotadaC]

Naja, ehrlich gesagt hab ich mich bei den Controllern mit dem Thema Stromsparen noch nicht wirklich beschäftigt - kA, wieviel ddie Taktreduktion da bringt.
Konsequenterweise sollte man dann aber auch den ganzen Rest mitdurchdenken:

• höhe der Versorgungsspannung
• Abschaltung von (gerade) nicht verwendeter Controller-Hardware (PRR oder so)
• Controller (und ggf auch externe ICs) wenn möglich zeitweise schlafen schicken (zB zwischen 2 Messungen)
• Berücksichtigung des Sparens auch bei der Schaltung (Ohmigkeit von Spannungsteilern/Pull-Widerständen, Helligkeit von LEDs etc)

Zum Mega8 auf dem "richtigen Programmer": hast Du mal versucht, da die Lockbits auszulesen? Wenn der von irgendjemandem "Original"-verkauft wurde, hat dieser sicher die Firmware auf dem Controller durch die Lockbits geschützt. Siehe dazu ins Datenblatt - man kann den Controller selbst meiner Meinung nach aber quasi Formatieren (komplett löschen). Dann ist er wieder programmierbar, und Du hast die Firmware trotzdem nicht auslesen können.

 

[TommyB]

Was Strom sparen angeht da hab ich mich mal etwas schlau gelesen.

Es gibt einige AVR Chips auch als stromsparende Version (ich meine die haben ein P im Namen). Die kann man nicht so schnell takten (z. B. 10 statt 20MHz) aber das wäre da ja egal.

Wichtig ist denn noch (wie LotadaC schon erwähnte) das PRR zu setzen, also nicht benötigte Komponenten abschalten. Da muss man aber erstmal in das Datenblatt schauen um zu sehen was alles deaktiviert werden kann, das ist je nach Chip unterschiedlich. (der ATtiny13 hat nur ADC und Timer0 was deaktiviert werden kann, was, wenn ich das richtig verstehe beides aber genutzt wird). Für die Leute die debugWire nutzen: SPI darf nicht deaktiviert werden, das schaltet möglicherweise auch debugWire aus und man hat n echtes Problem

Denn kann man noch den Analog Comperator deaktivieren (steht nicht im PRR drin).

Dann ist die Verwendung von Interrupts Pflicht. Wenn der Chip die ganze Zeit am arbeiten ist zieht der auch mehr Strom. Sind zwar nur ein paar mA, aber es läppert sich. Sprich du musst die Interrupts aktivieren, den für dich passenden Sleep Mode setzen und in der Haupt-Programmschleife SLEEP aufrufen (zumindest in Assembler, wie der Befehl unter C heißt kA). Bei dem SLEEP schläft der Controller denn bis zum nächstem Interrupt ein und wacht erst wieder durch einen Interrupt wieder auf. Während der Zeit wird fast kein Strom gebraucht. Genaue Werte finden sich im jeweiligem Datenblatt etwas weiter unten

Wenn man das alles bedenkt ist der Unterschied zwischen niedrigem Takt (aber dafür länger arbeiten) und schnellem Takt (dafür aber fix fertig und weniger ISP Probleme) nahezu gleich 0

Gemessen hab ich das aber nie, ich hab kein Messgerät was in den µA Bereich runter geht. Ich verlass mich da auf die Datenblätter. Klar, der Rest der Schaltung muss auch beachtet werden. Spannungsteiler, Pull-Up, Pull-Down, ...

 

[LotadaC]

Sofern ich mich erinnere, gabs 'ne zeitlang L-Varianten, die als Stromsparvariante verkauft wurden.
Meiner Meinung nach die gleichen ICs, nur entsprechend selektiert.

Bei den neueren P,A,PA-Varianten giebts das mMn nicht mehr, die Fertigungstoleranzen scheinen also enger zu sein.

Irgendwo hatte ich hier vor 'her Weile mal nach der Nomenklatur der Namen gefragt...

gefunden...

 

[flecralf]

Gut, das wußte ich noch nicht, dass man Teile bzw. Funktionen abschalten kann.
Wäre ja auch für portable Geräte interessant.

Aber, hurra der Programmer ist jetzt auch geflasht !
Irgendwie gab es beim Aufbau Störungen.

So, heute ist DHT11 Feuchtesensor gekommen.....
Gruß

 

[flecralf]

Und, jetzt liegt hier auch noch ein SD-Karten-Leser... da brauch' ich erstmal ein
Pegelwandler 3,3 V / 5 V, aber wie Programmieren ?
Gruß
Ralf

 

[LotadaC]

Für sowas gibts Levelshifter-ICs. Aber dazu werden Cassio und Dino mehr sagen können.
Prinzipiell kommen die AVR mit den 3,3V-Pegeln (Logik) auch klar - in der anderen Richtung mußt Du natürlich eingreifen. Ich habe bei einem GLCD (DogL) einfach mal einen Strombegrenzungswiderstand und 'ne Zenerdiode verwendet (je Leitung, klar).
Zur Stromversorgung dann einen entsprechenden LDO-Linearregler.

Alternativ könntest Du auch den Controller mit 3,3V laufen lassen

Was meinst Du mit programmieren? Was willst Du auf dem externen Speicher denn überhaupt ablegen? Wo soll das überhaupt lesbar sein? Welche Sprache?
(ich meine mich schwach an C zu erinnern... unter Bascom gabs wohl bereits 'ne vorbereiteteAnbindung/'n Dateisystem etc - hab mich damit allerdings nie beschäftigt, wies unter C aussieht, weiß ich nicht. Unter ASM müßte man das wohl eh selbst implementieren...)