attiny2313 schläft und lässt sich nicht mehr programmieren

das hat bestimmt nichts mit deine Programmierung zu tun. Dann wenn der 
µC Programmiert wird ist er im Reset status - da läuft kein Programm.

Ich hatte schon mal das Programm mit !Sleep am laufen. Es ist auch 
gelaufen und wieder aufgewacht. Was ich daran geändert habe weis ich 
dummerweise nicht mehr. Seither kann ich einen neuen 2313 programmieren. 
Ich habe viele der Befehle getestet und er lies sich immer wieder 
programmieren. Erst als ich den Befehl !Sleep einfügte war es 
anschliesend aus. Das Programm läuft bis zu diesem Bfehl, bleibt stehen 
und nichts geht mehr.

Karl Heinz Buchegger schrieb:
> Und nein: dagegen kann er
> sich auch nicht wehren.

doch, Reset Disable (gut das geht nicht per Software)

Karl Heinz Buchegger schrieb:
> Nochmal: Das alles hat nichts mit der Programmierung über ISP zu tun!

Alles schön und gut, aber was kann ich tun um die 2313 wieder 
programmieren zu könne? Sie sind ja nicht kaputt, das Programm läuft ja 
nach einem Reset wider bis zum !Sleep

Also Karl-Heinz, ich bewundere Deinen Umgang mit bornierten 
Fragestellern.

Hätte der TO seinen Code eingestellt, hätte ihm längst jemand sagen 
können, wo's hakt. Denn genau das wird's sein, solange er nicht an den 
Fuses rumpfuscht und den µC damit himmelt, ist einfach nur der Quellcode 
fehlerhaft.

Karl Heinz Buchegger schrieb:
> Das andere ist, was dann dieses Programm macht. Da kommt dann dein Sleep
> ins Spiel. Wenn das dein Problem ist, dann hast du einfach nur einen
> Programmfehler, den du beheben musst.
> Dieser Fall hat aber wiederrum nichts mit deinem Programmiergerät zu
> tun.

Mein Programmiergerät ist in Ordnung, ich kann damit ein neues IC 
programmieren. Wenn ein Programm ohne diesen Befehl geladen ist, lasst 
es sich auch wieder neu programmieren. Nur wenn dieser !Sleep-Befehl 
drin ist, geht nichts mehr. Ich habe nichts mit den Fsebits gemacht. 
Aber bei all den Versuchen "schlafen" jetzt schon 6 ATTiny2313 bis ich 
heraus gefunden habe wann sie das machen.

Läubi .. schrieb:
> Versuchsweise kannst du den ResetPin mal dauerhaft auf GND legen und
> schauen ob dann der Programmer wieder darauf zugreifen kann.

Das mit dem Dauerreset kann ich mal probieren. Vielen Dank für Eure 
Anteilname. Ich muss jetzt weg, arbeiten. Bin morgen Abend wieder im 
Netz.

Karl Heinz Buchegger schrieb:
> Du suchst an der falschen Stelle. Selbst mit dem größten Unsinn kannst
> du deinen 2313 nicht so programmieren, dass du mit dem Programmer nicht
> mehr rann kannst.

Es tät' noch die Möglichkeit des Setzens der Fuses über ein .elf-File 
geben, und damit sozusagen die Himmelung bei jedem Programmiervorgang.

Nur statt mit Info's rauszurücken, Typ und SW des Programmierers, 
Umgebung, Board usw., muss man wieder alles aus der Nase des geschätzten 
Fragenden ziehen.

MWS schrieb:
> Nur statt mit Info's rauszurücken, Typ und SW des Programmierers,
> Umgebung, Board usw., muss man wieder alles aus der Nase des geschätzten
> Fragenden ziehen.

Infos:
Programmiergerät:BASCOM USB ISP Programmer, mit dem ich schon die 
unterschiedlichsten ATMEL ohne Probleme geladen habe. Sowohl auf dem 
Testboard von Roland Walter als auch auf meinem Eigenbau.
Testboard:Eigenbau, auf dem ich schon verschiedene ATiny2313 
programmiert habe und die alle ohne Probleme laufen und sich auch wieder 
neu laden lassen.
Programm:Im Anhang

Welcher fehler wird den angezeigt ????

wenn der fehler angezeigt wird dann haste warscheinlich einen von den 
ISP pinnen an deinen attiny2313 falsch beschaltet oder noch was 
angschlossen was zu niederohming ist.

Mfg Kannnix

Neueste Erkenntnisse: Die Nummer mit dem Dauaerreset beim Starten hat 
funktioniert, aber nur einmal. Nachdem ich ein weiteres Mal das 
Sleep-Programm geladen hatte kam die Meldung:Difference at000003.
Ein weiterer Versuch brachte die Meldung:
could not identify chip with ID:ffffff.
Es lies sich nicht mehr löschen. Jetzt geht mit diesem "2313 gar nichts 
mehr. Ich etwas vorsichtiger geworden, ich hab es nur noch mit zwei IC's 
versucht, mit dem gleichen Ergebnis.

Kannnix schrieb:
> wenn der fehler angezeigt wird dann haste warscheinlich einen von den
> ISP pinnen an deinen attiny2313 falsch beschaltet oder noch was
> angschlossen was zu niederohming ist.

Außer dem Ziel-IC ist nichts angeschlossen. Und alle anderen Programme 
die ich lade laufen wie auch das gepostete ohne !Sleep. Wenn ich das 
lade, läuft es bis zum Befehl !Sleep und bleibt stehen. Wenn ich mit 
INT0 "Stellen" auslöse kommen erst einige Hiroglyphen und dann läuft das 
Programm weiter bis zum nächsten !Sleep. Aber neu laden lässt es sich 
dann nicht mehr.
Noch was zu den Printbefehlen: Damit kann ich im Terminalprogramm von 
Bascom verfolgen was passiert, oder wo er hängen bleibt. Die fallen dann 
im Original weg.
Für die mangelhafte Information am Anfang bitte ich um Verzeihung, ich 
bin nicht sehr erfahren im Umgang mit Foren. Bis jetzt haben mir 
einschlägige Literatur und die Datenblätter weiter geholfen.

Klaus-Peter schrieb:
> Außer dem Ziel-IC ist nichts angeschlossen. Und alle anderen Programme
> die ich lade laufen wie auch das gepostete ohne !Sleep. Wenn ich das
> lade, läuft es bis zum Befehl !Sleep und bleibt stehen.

Du hast, jedenfalls was vom Screenshot zu sehen ist, keine Stackwerte 
definiert. Das ist einer der Fehler-Klassiker. Es ist auf dem Bild auch 
kein Sleep zu sehen, deshalb wie schon geraten, als Datei anhängen.

Nur - das Programm kann so falsch sein wie es nur will, deswegen 
funktioniert die Programmierung immer wieder, außer:

- Kontaktprobleme
- störende Bauteile an den Programmierpins
- falsches Setzen der Fuses
- in extremen Fällen Verfusen des µCs wegen Punkt 1 oder 2

MWS schrieb:
> Du hast, jedenfalls was vom Screenshot zu sehen ist, keine Stackwerte
> definiert. Das ist einer der Fehler-Klassiker. Es ist auf dem Bild auch
> kein Sleep zu sehen, deshalb wie schon geraten, als Datei anhängen.

Sorry, ich hab gar nicht gemerkt, dass da noch einiges fehlt. So wie es 
dargestellt ist, läuft das Programm einwandfrei und das IC lässt sich 
auch immer wieder neu laden. Nur wenn der !Sleep-Befehl freigeschaltet 
ist kann ich das Programm laden und es läuft bis zum !Sleep. Mit einem 
Hardwarerest startet das Programm auch wieder. Mit dem INT0 zeigt das 
Terminalprogramm etwa 10 Hiroglyphen und dann wider "schlafen".
ImScreenshot Sleep_test4 ist der Terminalausdruck des Programms mit 
!Sleep, gestartet mit INT0.

noch ein screenshot

noch einer

HI

>noch ein screenshot

>noch einer

Das ist keine Salami, die man scheibchenweise serviert. Ist es so 
schwer, dein Programm anzuhängen?

MfG Spess

spess53 schrieb:
> Das ist keine Salami, die man scheibchenweise serviert. Ist es so
> schwer, dein Programm anzuhängen?

Leute ich bin 70 und froh, dass ich da überhaupt durchblicke. Meine 
Versuche, alle auf einmal anzuhängen haben nichts gebracht. 
Wahrscheinlich habe ich nicht lange genug gewartet bis das Bild 
angehängt war und ein Wartesignal habe ich auch nicht entdeckt, sorry!

Hannes Lux schrieb:
> Will hier keiner... - Denn wie soll man damit das Programm in Bascom
> laden und debuggen? Du sollst den Quelltext als Textdatei anhängen.

Ich versuchs mal in WORD.

HI

Nimm einfach deine 'Sleep_Test.bas' als Anhang.

MfG spess

und jetzt noch mit dem Editor

Klaus-Peter schrieb:
> Nur wenn der !Sleep-Befehl freigeschaltet
> ist kann ich das Programm laden und es läuft bis zum !Sleep. Mit einem
> Hardwarerest startet das Programm auch wieder.

Das ist aber jetzt was anderes als "schläft und lässt sich nicht mehr 
programmieren"
Dein Programm ist einfach falsch, nix weiter. Nur wenn Du weiter die 
ignorierst, die Dir helfen sollen, dann wirst Du das wohl selbst 
austüfteln dürfen.

Kein Mensch will Screenshots, wenn's eine Textdatei verfügbar ist.

Hannes Lux schrieb:
> Peter, bitte hänge die Datei mit dem Namen "Sleep_Test.bas" an, die sich
> im Ordner "C:\Users\Peter\1-Minutentakt" befindet.

ok, das war mal ein guter Rat,danke

MWS schrieb:
> Das ist aber jetzt was anderes als "schläft und lässt sich nicht mehr
> programmieren"
> Dein Programm ist einfach falsch, nix weiter. Nur wenn Du weiter die
> ignorierst, die Dir helfen sollen, dann wirst Du das wohl selbst
> austüfteln dürfen.

Toll!

Simon K. schrieb:
> ... Code und Fehlermeldungen braucht man auch nicht als Bild anzuhängen.

gelesen ?

Klaus-Peter schrieb:
> Toll!

War nur 'n Hinweis, wie's hier so läuft. Aber wie ich seh' gab's ja 
jetzt endlich 'ne positive Reaktion :D

Du hast das Datenblatt gelesen ?
"Standby mode is only recommended for use with external crystals or 
resonators."
Und wenn Du PCInts nutzen willst, musst Du das PCMSK-Register setzen. 
Ohne wacht da nix auf. Wenn's denn über den PCInt aufwachen soll.
Ansonsten etwas durcheinander das Ganze.

Hannes Lux schrieb:
> Du hast Int0 und PCI aktiviert, aber nur für Int0 einen Int-Handler
> On Timer1 Ontimer1 'Timer1-Overflow-Interrupt-Routine
> On Int0 Stellen    'Zum Überbrücken der Zeitschleife
>
> Deine Warteschleifen gefallen mir auch nicht.

Die Warteschleifen und die Printbefehle sind nur zum beobachten. Wen 
alles richtig läuft fallen die alle raus.
Das mit dem Timer1 zum Aufwecken hab ich so gemacht, weil der länger 
zählt bis er überläuft. Ob und wie das funktioniert wollte ich ja 
testen. Dazu aber muss ich ihn ja erst mal Schlafen legen. Und das ist 
die Krux, weil danach nichts mehr geht.

MWS schrieb:
> Du hast das Datenblatt gelesen ?
> "Standby mode is only recommended for use with external crystals or
> resonators."

ich hab den Idlemode gewählt.Mcucr = &B01100000

Klaus-Peter schrieb:
> ich hab den Idlemode gewählt.Mcucr = &B01100000

Nein, das ist Standby und beiläufig ist die Binär-Schreibweise ein 
Graus.
Das geht besser.

MWS schrieb:
> Nein, das ist Standby und beiläufig ist die Binär-Schreibweise ein
> Graus.
> Das geht besser.

ok,Dum hast recht, aber das ändert nichts an der Tatsache, dass egal wie 
ich MCUCR einstelle, nach dem Laden mit !Sleep keine weiteren Ladungen 
möglich sind.
Für mich ist der Binärcode übersichtlicher.

MWS schrieb:
> Und wenn Du PCInts nutzen willst, musst Du das PCMSK-Register setzen.

Ich dachte, wenn ich Pcmsk = &B00000001 setze, dann wird PB0 
(PCINT0)angesprochen. Was fehlt da noch?

Klaus-Peter schrieb:
> Für mich ist der Binärcode übersichtlicher.

Wäre es das, hättest Du den Fehler nicht gemacht.
Es gibt für Deinen Zweck den Befehl: POWER IDLE

Klaus-Peter schrieb:
> Ich dachte, wenn ich Pcmsk = &B00000001 setze, dann wird PB0
> (PCINT0)angesprochen. Was fehlt da noch?

Ja, musst es aber auch in Deinen Code reinschreiben.
Stacks und Frame fehlt immer noch.

Hannes Lux schrieb:
>>und beiläufig ist die Binär-Schreibweise ein
>> Graus.
>> Das geht besser.
>
> Stimmt:
>
> Mcucr = Bits(sm1,se)  'Sleep im Mode Power-Down voreinstellen

Ich seh schon, da muss ich noch einiges dazu lernen. Allerdings habe ich 
für meine Brennwertterme von Herrmann (vielleicht kennt die ja einer und 
auch den Murks) eine neue Steuerung gebaut mit einem ATMEGA8 und einen 
Tempomat für meinen VW Bus auch mit dem MEGA8. Beide funktioniren 
einwandfrei. Auch das leidige Sleepprogramm läuft auf einem MEGA88 
anstandslos. Erst als ich versuchte es auf den 2313 umzuschreiben 
klemmte es.

Hannes Lux schrieb:
> Aber auch Dein ganzes Konzept ist sehr diffus. So richtig verstehe ich
> nicht, was das werden soll.

Ich hab eine Slaveuhr oder wie man das nennt. Die braucht alle Minute 
einen Impuls von 12V, allerdings jedesmal mit anderer Polung. Sie soll 
mit Batterie laufen und das tut sie auch. Aber ich wollte Strom sparen. 
Die Ausgänge PB2,PB3 schalten die Polung um umd dann bringt PB4 die 
Spannung, alles über Relais. Die Zeiten sind freilich viel zu lang. Sie 
sind es nur zum besseren Beobachten.

Hannes Lux schrieb:
> MWS schrieb:
> Nimmt dann nicht der Compiler die voreingestellten Werte?

Ja, aber die Voreinstellung ist recht klein, wenn ISRs drin sind, dann 
ist das zuwenig

MWS schrieb:
> Es gibt für Deinen Zweck den Befehl: POWER IDLE

In meinem ersten Bascomprogramm (Demo) hatte ich eine komplette Liste 
aller Befehle.Um nicht durcheinander zu kommen habe ich es entfernt, als 
ich mir die Vollversion gekauft hatte. Abgesehen davon, dass ich mich 
erst wieder darin zurecht finden musste fand ich diese Liste nicht mehr.

Hannes Lux schrieb:
> Stimmt:
>
> Mcucr = Bits(sm1,se)  'Sleep im Mode Power-Down voreinstellen

Also bei meinem Tiny2313 Datenblatt  entspricht SM1=1 SM0=0 dem Standby 
Mode, was verwendest Du für ein DB ?

MWS schrieb:
> Ja, aber die Voreinstellung ist recht klein, wenn ISRs drin sind, dann
> ist das zuwenig

HW Stack = 40; Softstack = 16; Framesize = 32. Wie erkenne ich wie groß 
die Werte mindestens sein müssen?

Hannes Lux schrieb:
> Jaaaa, stimmt ja, diese riesigen Push/Pop-Orgien...
>
> Also geht's jetzt nicht nur um die Einträge, sondern vor allem auch um
> die richtige Anpassung der Einträge (viel HW-Stack wegen der
> Registersicherung, wenig SW-Stack wegen geringer Parameterübergabe und
> wenig Framesize, da keine Funktionen rechnen müssen...).

Und das alles nur wegen des !Sleep? Denn ohne läuft das Programm ja.
Übrigens, der Interupt, der jetzt noch mit dem TIMER1 ausgelöst werden 
soll wird nachher von einem DTF-Modul gesendet. Das ist dann das nächste 
Problem.

Klaus-Peter schrieb:
> HW Stack = 40; Softstack = 16; Framesize = 32. Wie erkenne ich wie groß
> die Werte mindestens sein müssen?

Sollte reichen. Wie erkennen ? Teils Erfahrung, gibt auch ANs dazu im 
MCS- Forum. Eine ISR benötigt 26 der 40 Bytes HW-Stack.

Wie weit ist denn das Problem der Nichtmehrneuprogrammierbarkeit 
gediehen ?

Hannes Lux schrieb:
> Warum sollte sich da inzwischen etwas geändert haben?

Weis auch nicht...
Aber schau das hier an:
http://www.atmel.com/dyn/resources/prod_documents/doc2543.pdf

Hannes Lux schrieb:
> Danke, ist ersetzt... - Aber etwas dreist ist das schon, oder?

Macht das Programmieren interessanter und abwechslungsreicher ;D

MWS schrieb:
> Wie weit ist denn das Problem der Nichtmehrneuprogrammierbarkeit
> gediehen ?

Genau und nur um das geht es mir eigentlich. Auch wenn Ihr es nicht 
glaubt, meine Programme laufen, alle. Nur jetzt komme ich nicht weiter, 
weil jeder Versuch mit "!Sleep" zu arbeiten meine IC's himmelt. Ob das 
Programm nun der Norm von Profis entspricht weis ich nicht. BASCOM hab 
ich zufällig gefunden und ich war neugierig ob ich damit was anfangen 
kann. Und da die Atmels wirklich preiswert sind fing ich vor etwa 2 
Jahren an, es auszuprobieren. Sicher könnte ich das Problem auch anders 
lösen und werde es wohl auch tun müssen. Nur wenn etwas nicht so 
funktioniert wie es soll, lässt es mir keine Ruhe, und daher meine 
Anfrage. Es hätte ja sein können, dass einer von Euch da schon mal was 
ähnliches erlebt hat. Oder vielleicht, dass jemand weis, wie man so 
einen verriegelten 2313 wieder ansprechen kann. Trotzdem vielen Dank für 
Eure Mithilfe. Ich habe doch einige gute Ratschläge bekommen.

Klaus-Peter schrieb:
> Genau und nur um das geht es mir eigentlich. Auch wenn Ihr es nicht
> glaubt, meine Programme laufen, alle. Nur jetzt komme ich nicht weiter,
> weil jeder Versuch mit "!Sleep" zu arbeiten meine IC's himmelt.

Also ist das ein "Ja, Problem existiert noch" ?
Oder ein "Hab's noch nicht wieder probiert"

> Ob das
> Programm nun der Norm von Profis entspricht weis ich nicht. BASCOM hab
> ich zufällig gefunden und ich war neugierig ob ich damit was anfangen
> kann. Und da die Atmels wirklich preiswert sind fing ich vor etwa 2
> Jahren an, es auszuprobieren. Sicher könnte ich das Problem auch anders
> lösen und werde es wohl auch tun müssen.

Niemand stört wie Du das für Dich hältst.

Es gibt da die Regel, dass Du jederzeit so programmieren kannst, wie Du 
möchtest, und der µC kann dann jederzeit die Mitarbeit verweigern, so 
wie er möchte :D

> Oder vielleicht, dass jemand weis, wie man so
> einen verriegelten 2313 wieder ansprechen kann.

High Voltage Programmierung wäre hier das Stichwort, das kann Dein 
Programmer aber nicht, da bräuchtest Du 'nen STK500.

Klaus-Peter schrieb:
> Nur jetzt komme ich nicht weiter,
> weil jeder Versuch mit "!Sleep" zu arbeiten meine IC's himmelt.

Wie schon erwähnt, das ist eher unwahrscheinlich. Bevor ich wirklich so 
etwas annehmen würde, würd' ich eher den Fehler beim Programmer und beim 
Benutzer suchen.

Wir wollten Deinen Programmcode sehen, um einschätzen zu können, ob da 
etwas drinsteht, was Du für den Fehler interpretieren könntest. Nach 
meiner Einschätzung hast Du Anfängerlevel, was jetzt nicht abwertend 
gemeint ist. Bei Anfängern werden manche Ursachen für gänzlich andere 
gehalten und ab und zu lösen sich die bei weiterer Beschäftigung mit der 
Materie von selbst.

Klaus-Peter schrieb:
> Außer dem Ziel-IC ist nichts angeschlossen.

Hast Du denn wenigstens den 100nF Abblockkondensator dran ? Der kann den 
Unterschied ausmachen. Wie ist der genaue Aufbau beim Programmieren ?

Mein Rat wäre, je nach Budget und Verfügbarkeit einer seriellen 
Schnittstelle an Deinem PC, einen STK500 zu besorgen und AVR-Studio 4 zu 
installieren. Oder auch das 5er-Studio, wobei mir das zu aufgeblasen 
ist.

Nachtrag:

Was steht denn auf den ATTinys drauf, ATTiny2313 oder ATTiny2313A ?

MWS schrieb:
> Was steht denn auf den ATTinys drauf, ATTiny2313 oder ATTiny2313A ?

An Alle,
danke für die vielen guten Ratschläge. Ich war bisher Einzelkämpfer und 
Seiteneinsteiger, daher ist mein Fachjargon wahrscheinlich sehr 
mangelhaft. Was aber nicht darüber hinwegtäuschen soll, dass ich mehrere 
auch kompliziertere Programme zum Laufen gebracht habe. Auch mag 
vielleicht die Kontrolle des Progammverlaufs mit Printbefehlen und dem 
Terminalprogramm sehr Laienhaft sein, aber ich kann Euch versichern, 
dass ich sehe ob meine Programme laufen oder nicht.
Also nochmal, das gepostete Programm läuft ohne "!Sleep" genau wie es 
soll. Ich habe es nur um es zu beweisen 10 Mal gelöscht und neu geladen, 
immer im gleichen IC. Also kann es weder am Programm, noch am 
Programmierer, noch am Benutzer, noch am Netzteil (Schaltnetzteil 2,5A) 
auf dem Testboard mit 100µF,100nF abgeblockt, sondern nur an dem 
"!Sleep" Befehl liegen. Das wars. Auch wenn es so aussieht als würde ich 
die guten Ratschläge von Euch ignorieren. Ich werde diesen Befehl aus 
meinem Befehssatz für den Tiny 2313 (ohne A!) streichen, denn sonst sehe 
ich ihn, weil kleiner als der Mega8, als für mich brauchbare Ergänzung 
zu Letzterem.
Der Tiny hat 2,35€ gekostet. Ich hab damals 10 Stück gekauft und werde 
mir noch mal welche besorgen. Bis jetzt lohnt es sich also nicht, sie 
zur Überprüfung (danke Hannes) wegzuschicken, noch dafür einen 
HV-Programmer zu kaufen (danke MWS).
Klaus-Peter

Versuche es mal mit:
$ASM
 Sleep
$End ASM

Print "MfG Paul"
;-)

Im Register MCUCR ist doch das oberste Bit PUD mit drin.
(Pull up Disable)
Wenn das gesetzt wird, dann werden die internen Ziehwiderstände
abgeschaltet, auch wenn sie vorher eingeschaltet hatte.

Ich denke, daß man dann mit dem ISP-Programmiergerät nicht mehr dran
kommt, weil der Reset-Eingang keinen H-Pegel mehr bekommt.

MfG Paul

Winfried J. schrieb im Beitrag #2452815:
> enthält dieses aber auch die Pinchange bits und damit schießt du dir
> den Resetpin  ab! er wird ungewollt zu PA2 und bleibt es!
> deshalb kannst du nicht neu brennen

Das ist doch jetzt wirklich der komplette Blödsinn.
MCUCR kann die internen Pullups abschalten, Sleep-Modi konfigurieren und 
die Modi für ext. Int0/1 einstellen. Aber keinen Reset disablen. Hoffen 
wir mal, dass nicht Deine Aufzüge nach diesem System funktionieren.

Paul Baumann schrieb:
> Ich denke, daß man dann mit dem ISP-Programmiergerät nicht mehr dran
> kommt, weil der Reset-Eingang keinen H-Pegel mehr bekommt.

Sobald der Programmer auf Low zieht, egal ob mit oder ohne Pullup, ist 
kein Programm mehr aktiv und die Default-Einstellungen des µC sind 
gültig. Per Default ist PUD ausgeschaltet, selbst wenn die Pullups für 
den Resetpin überhaupt gelten sollten.

Klaus-Peter schrieb:
> An Alle,
> danke für die vielen guten Ratschläge. Ich war bisher Einzelkämpfer und
> Seiteneinsteiger,

Statt dessen Du mir die gewünschte Antwort gibst, wird's um den Brei 
rumreden und das Thema "Beleidigte Leberwurst".

Ganz deutlich: es ist uns absolut egal, wie Du programmierst, wie Du das 
gelernt hast, wofür's sein soll, usw.

Aber 1) fragst Du um Hilfe und stellst Dich dabei eher als 
verständnisresistent dar und 2) sagst Du "Sleep im ATTiny2313 ist 
kaputt"

Klaus-Peter schrieb:
> Also kann es weder am Programm, noch am
> Programmierer, noch am Benutzer, noch am Netzteil (Schaltnetzteil 2,5A)
> auf dem Testboard mit 100µF,100nF abgeblockt, sondern nur an dem
> "!Sleep" Befehl liegen. Das wars.

Und das ist entweder ein Schmarrn oder es gibt bei diesem µC tatsächlich 
einen Defekt. Wenn Letzteres der Fall ist, dann interessiert es alle 
hier.

Um das Leiden abzukürzen hab' ich Dein Programm hier auf einen 
ATTiny2313-20PU geflasht.

Steckbrettaufbau
Bascom Version 2.0.7.3, aktuell
Programmer Diamex ISP STK500 Nachbau
Programmeroberfläche Bascom, STK500 native driver
µC-Versorgung 5V über VTG des Programmers
mC ATTiny2313-20PU, 8MHz CKDIV8 Fuse ein, Takt 1MHz

Ich kann Dein Programm egal mit oder ohne !Sleep so oft flashen wie ich 
will, da gibt's überhaupt kein Problem, und das war auch anzunehmen.

Mit Sleep funktioniert Dein Programm selbst allerdings nicht, was daran 
liegt:

Klaus-Peter schrieb:
> MWS schrieb:
>> Du hast das Datenblatt gelesen ?
>> "Standby mode is only recommended for use with external crystals or
>> resonators."

Damit fällt der Standby-Mode für Dich aus. Auch der Power-Down geht 
nicht, denn da läuft der Timer nicht mehr.

Was funktioniert ist der Idle-Mode, da läuft Dein Programm auch und die 
Leds blinken.

Hier hab' ich alle Modi getestet:

1

        Mcucr = &B00100000   ' timer läuft

2

'        Mcucr = &B00110000   ' timer läuft nicht

3

'        Mcucr = &B01100000   ' timer läuft nicht

4

'        Mcucr = &B01110000   ' timer läuft nicht

5

        !Sleep

6

        Mcucr = &B00000000

Entweder Dein Programmer arbeitet nicht zuverlässig, die Stromversorgung 
ist nicht ok, Dein Aufbau passt nicht, oder was auch immer.

Der ATTiny2313 kann jedoch immer wieder neu geflasht werden, also nix 
mit toten Käfer.

Hi

Dein Link funktioniert nicht. Aber abgesehen davon sind, wie andere 
schon gesagt haben, Reset-PullUp und IO-PullUp zwei paar Schuhe. Der 
Reset-PullUp lässt sich über PUD nicht abschalten.

MfG Spess

Winfried J. schrieb:
> Schlaf tut? Sollte er eigentlich wenn er ordentlich arbeitet, ich werde
> das mal probieren.
> obwohl will ich dafür einen2313 opfern?

Hättest Du meinen Beitrag gelesen, der zwei Beiträge vor Deinem lag, 
dann würde sich Dir diese Frage nicht mehr stellen.

Was ist los ? Zu tief in's Glas geschaut ? :-)

Winfried J. schrieb:
> Mcucr = &B01100000
> hier wird die MCU schlafen geschickt bevor der externe interrupt erlaubt
> wird!

Nein, das geschieht nicht.
Das MCUCR zu setzen ist nur die Vorbereitung auf den Sleep-Befehl. Ohne 
Sleep schläft da noch gar nix. Der TE hat nur das Setzen des MCUCR an 
die falsche Stelle geschrieben, üblicherweise kommt's unmittelbar vor 
dem Sleep-Befehl.

A.K schrob:
>Ausserdem setzt er das Bit auf 0, schaltet die Pullups also nicht ab.

Au weh, das habe ich jetzt im Quelltext gesehen...

Ich glaube, ich bin noch im Sleep-Modus...

MfG Paul

Hannes Lux schrieb:
> Das würde ich nicht so eng sehen. Bei festem Sleepmode stelle ich den
> Sleepmode bereits in der Init (also beim Reset) ein und rufe Sleep in
> der Mainloop auf.

Ich find's günstig Ursache und Wirkung beieinander zu haben. Für 
Übersichtlichkeit kann man mit Konstanten arbeiten.

Peter Dannegger schrieb:
> Aber dazu sagt er ja nichts und hat es wohl nichtmal nachgemessen.

Richtig, ich war seit Freitag ausser Gefecht. Man hat mir mein Auto 
geschrottet und ich war nach mehreren Arztbesuchen und dam ganzen 
Hickhack mit ADAC, Anwalt und Werkstatt (Gutachter) voll beschäftigt und 
hatte keinen Kopf mich momentan mit diesem Problem zu befassen.

Peter Dannegger schrieb:
> Ich vermute ja immer noch, er hat die Dinger spannungsmäßig gekillt.

Dann müssten ja alle IC's sterben und nicht nur wenn der !Sleep-Befehl 
mit drin steht.

MWS schrieb:
> Was funktioniert ist der Idle-Mode, da läuft Dein Programm auch und die
> Leds blinken.

Hier bestätigt mir ein Fachmann, dass dieses Programm läuft, mal 
abgesehen davon, dass es besser gemacht werden könnte. Alles was ich 
wissen wollte war, warum die 2313 sich nicht mehr programmieren lasen 
und was ich dagegen tun kann. Denn sie sind ja nicht gekillt, das 
geladene Programm läuft ja. Es war das erste Mal, dass ich mit einem 
ATiny2313 arbeitete. Mit dem ATMEGA-8 und -88 hatte ich bisher null 
Probleme. Da ist mir auch noch keiner ausgestiegen oder gestorben.
Wenn es mir wieder besser geht nehme ich die Versuche wieder auf und 
teste es mit dem Vorschlag:  Mcucr = &B00100000   ' timer läuft
Danke einstweilen
Klaus Peter

Knut Ballhause schrieb:
> Peter, Du wiederholst Dich ;-)

Na und?
Wenn es keine Antwort dazu gibt muss man die Jungs immer wieder in 
Erinnerung rufen.

Peter Dannegger schrieb:
> Der Sleep-Mode Power-Down bewirkt, daß der AVR keinen Strom mehr zieht.

Peter, der Klaus schreibt das doch die Dinger funktionieren bis sie in 
den sleep Mode gehen. Also das Programm läuft in dem µC bis zu einer 
bestimmten Stelle.

Warum soll er jetzt gestorben sein? Das soll jetzt kein Klugscheisser 
Spiel sein, sondern einfach nur für mein Verständnis.