AVROspII: ATTiny2313 zu langsam?

[Ludwig (Gast)]

Ein ATTiny2313-Programm setzt den Takt auf 4 MHz/64. Mein Problem ist 
nun, dass die AVROspII-Software (AVR910 Hardware)den ATTiny nicht mehr 
erreichen kann, weil dieser vermutlich zu langsam ist.

Einen USBASP/USBISP habe ich mit bereits bestellt. Der kommt aber erst 
zum Wochenende.

Was kann ich bis dahin tun?

[(prx) A. K. (prx)]

ISP findet bei aktivem Reset statt und da ist nicht wichtig, was das 
Controller-Programm selbst als Prescaler definiert. Die Div8 Fuse 
hingegen ist relevant. Ist die aktiv, darf der ISP-Takt dank 
4MHz/8=500kHz Takt nicht über 125kHz liegen.

Wo kommen die 4MHz her und mit welcher ISP-Frequenz arbeitet der 
Programmer? Bei RC-Oszillator geht nur ein entsprechend langsam 
einstellbarer ISP-Programmer, oder ein HVP-Programmer.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Ludwig schrieb:
> Ein ATTiny2313-Programm setzt den Takt auf 4 MHz/64

Das interessiert den Programmer normalerweise nicht, denn er hält den MC 
ja im Reset, so das die Software keine Chance hat, den Prescaler zu 
aktivieren. Wenns trotzdem nicht geht, könntest du versehentlich eine 
andere Taktquelle gewählt haben (per Fuse).

[Paul B. (paul_baumann)]

Ludwig schrieb:
> Einen USBASP/USBISP habe ich mit bereits bestellt. Der kommt aber erst
> zum Wochenende.
>
> Was kann ich bis dahin tun?

Auf ihn warten?
nicht hauen
;-)

MfG Paul

[Ludwig (Gast)]

Ihr habt natürlich recht, das Programm des ATiny startet bei aktivem 
Reset erst gar nicht. Da muss ich wohl einen Fehler gemacht und eine 
falsche Fuse gesetzt/gelöscht haben.

Danke für den Hinweis.

[S. Landolt (Gast)]

Matthias S. schrieb:
> Ludwig schrieb:
>> Ein ATTiny2313-Programm setzt den Takt auf 4 MHz/64
>
> Das interessiert den Programmer normalerweise nicht...

D.h., Sie können ein Programm laden, in welchem gleich zu Programmanfang 
der 'System Clock Prescaler' auf /256 gesetzt wird, und kommen 
anschließend mit Ihrem Programmer problemlos noch an den uC dran? - Mit 
welchem ISP-Takt läuft das dann?

[Uwe (de0508)]

Hallo,

ich weise mal auf diesen Thread hin:
Beitrag "Problem: Attiny45 mit 16MHz PLL Takt"
in dem wir Problem CPU-Takt mit gesetztem Prescaler durch das Programm 
betrachtet haben.

Es ist halt beim ATtiny45/tn85 nicht so, dass bei einem Reset der 
CPU-Takt ein gesetzter Prescaler zurückgesetzt wird und der Vorteiler 
über das zugehörige Fusebit verwendet wird.

Darauf bin ich auch per Zufall gestoßen.

A. K. schrieb:
> ISP findet bei aktivem Reset statt und da ist nicht wichtig, was das
> Controller-Programm selbst als Prescaler definiert. Die Div8 Fuse
> hingegen ist relevant. Ist die aktiv, darf der ISP-Takt dank
> 4MHz/8=500kHz Takt nicht über 125kHz liegen.
>
> Wo kommen die 4MHz her und mit welcher ISP-Frequenz arbeitet der
> Programmer? Bei RC-Oszillator geht nur ein entsprechend langsam
> einstellbarer ISP-Programmer, oder ein HVP-Programmer.

Matthias S. schrieb:
> Ludwig schrieb:
>> Ein ATTiny2313-Programm setzt den Takt auf 4 MHz/64
>
> Das interessiert den Programmer normalerweise nicht, denn er hält den MC
> ja im Reset, so das die Software keine Chance hat, den Prescaler zu
> aktivieren. Wenns trotzdem nicht geht, könntest du versehentlich eine
> andere Taktquelle gewählt haben (per Fuse).

[S. Landolt (Gast)]

Ganz recht, Uwe S., den hatte ich gesucht, aber nicht mehr gefunden. 
Danke.

[Ludwig (Gast)]

Auf einem Galep4 habe ich nur das Programm gelöscht und keine Fuse 
verändert und siehe, der ATiny2313 wird vom AVROspII wieder erkannt.

Hier die Fuses: Ext: 0xFF, High: 0xDF, Low: 0x62

Mit anderen ATTiny2313 zeigt sich das gleiche Verhalten: wird das 
Programm geflasht, hat AVROspII keinen Zugriff mehr, löschen des 
Programms mit dem Galep4 und es geht wieder.

Bin ratlos.

[S. Landolt (Gast)]

> Bin ratlos.
Warum? Steht doch z.T. hier, vor allem aber auch in dem von Uwe S. 
zitierten Link.

[S. Landolt (Gast)]

Ich kenne den AVROspII nicht, aber vielleicht hilft es, wenn gleich zu 
Programmbeginn, also noch vor dem Setzen des Vorteilers, eine 
Warteschleife von 1..2 Sekunden eingefügt wird.

[Ludwig (Gast)]

S. Landolt schrieb:
> Ich kenne den AVROspII nicht, aber vielleicht hilft es, wenn
> gleich zu
> Programmbeginn, also noch vor dem Setzen des Vorteilers, eine
> Warteschleife von 1..2 Sekunden eingefügt wird.

Kann nicht sein, da das Programm nicht startet, die Kommunikation mit 
dem Chip erfolgt während Reset Low ist.

>> Bin ratlos.
> Warum? Steht doch z.T. hier, vor allem aber auch in dem von Uwe S.
> zitierten Link.

Wie erklärt der Link mein Problem?

[S. Landolt (Gast)]

> Kann nicht sein...
Haben Sie es ausprobiert? Evtl. gibt das Programmiergerät, so wie es im 
Datenblatt steht, einen positiven Impuls auf /RESET.

> Wie erklärt der Link mein Problem?
Es gibt Programmiergeräte, die sich wie Ihres verhalten, also nur noch 
mit sehr langsamem ISP-Takt an den uC kommen. Andere schaffen es 
angeblich, vielleicht meldet sich mal ein Besitzer, um welche es sich 
handelt.

[S. Landolt (Gast)]

Noch eine letzte Idee: unmittelbar nach Programmstart den Vorteiler auf 
/1 setzen, dann die 2 Sekunden warten, dann /64.

[Uwe (Gast)]

Hi,
Sollte es nicht gehen wenn man beim einschalten der Betriebssp. den 
Reset schon gesetzt hat? Der µC springt doch meistens gleich an bevor 
auf Prog.
umgeschaltet wird, da wird das Register ja schon gesetzt und Reset 
verändert es nicht mehr. Es sei denn ich irre mich gerade gewaltig.

Viel Erfolg, Uwe

[Ludwig (Gast)]

Nehme ich diese Zeilen aus meinem Programm, die den Teiler (64) setzen 
heraus, dann funktioniert der Zugriff einwandfrei:

[/C]
    CLKPR = (1 << CLKPCE);
    CLKPR = (1 << CLKPS2) | (1 << CLKPS1);
[C]

Ausschnitt aus dem Programmercode des verwendeten Programmers:

        ... 
clr_LED       ; LED on
catch_ports   ; catch ports
clr_SCK       ; clear SCK
pas_RESET     ; set RESET passive
ldi temp1,50  ; delay 50mS;
rcall delay
act_RESET     ; set RESET active
ldi emp1,50   ; delay 50mS;
rcall delay  
        ...

Der komplette Code ist hier:

http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/avr910_2313_v38b.hex

[M. K. (sylaina)]

Ludwig schrieb:
> Nehme ich diese Zeilen aus meinem Programm, die den Teiler (64) setzen
> heraus, dann funktioniert der Zugriff einwandfrei:

Das klingt dann doch sehr danach, dass der ISP-Takt nicht passt bzw zu 
schnell ist.

[Ludwig (Gast)]

Michael K. schrieb:
> Ludwig schrieb:
>> Nehme ich diese Zeilen aus meinem Programm, die den Teiler (64) setzen
>> heraus, dann funktioniert der Zugriff einwandfrei:
>
> Das klingt dann doch sehr danach, dass der ISP-Takt nicht passt bzw zu
> schnell ist.

Nach einem Reset werden alle Register des ATTiny2313 zurückgesetzt. D. 
h. der Teiler auch.

[Ludwig (Gast)]

Auch wenn ich den den Resetpin - vor dem Einschalten des Programmers - 
auf Low lege, das gleiche Ergebnis: kein Zugriff auf den Chip.

Es reicht, dass diese Zeilen im Code stehen:

    CLKPR = (1 << CLKPCE);
    CLKPR = (1 << CLKPS2) | (1 << CLKPS1);

[Peter D. (peda)]

Ist auch meine Erfahrung, die Prescalerbits überstehen einen Sprung in 
den ISP-Mode unverändert.
Ich konnte dann nur noch im HV-Mode (STK500) vernünftig programmieren.

Die Programmer gehen ja auch erstmal in tristate und werden nur bei 
einer Programmieraktion aktiv.
D.h. nach jedem Power-On wird auf alle Fälle erstmal die Applikation 
gestartet.

[Thomas H. (Firma: CIA) (apostel13)]

Ludwig schrieb:
> Was kann ich bis dahin tun?

Du könntest die Zeit zum Lesen nutzen, oder dich aktiv in der 
Flüchtlingskriese engagieren. Oder einfach den Tiny der nicht erreichbar 
ist irgendwo unterklemmen wo ein Tisch oder ähnliches wackelt und einen 
neuen nehmen.

[Ludwig (Gast)]

Thomas H. schrieb:
> Ludwig schrieb:
>> Was kann ich bis dahin tun?
>
> Du könntest die Zeit zum Lesen nutzen, oder dich aktiv in der
> Flüchtlingskriese engagieren. Oder einfach den Tiny der nicht erreichbar
> ist irgendwo unterklemmen wo ein Tisch oder ähnliches wackelt und einen
> neuen nehmen.

Bitte nur sachliche Antworten. Ein Mindestmaß an fachlicher Kompetenz 
ist schon erforderlich. Einfach nur dumm sein reicht hier nicht, Thomas. 
Du musst also draußen bleiben.