Atmega8, Ports schalten nicht

[Smarki (Gast)]

Hallo zusammen,
ich versuche seit zwei Tagen vergebens eine LED über den Port B meines 
AtMEga8 Prozessors zum Blinken zu bewegen.
Die Schaltung habe ich meiner Meinung nach richtig geschaltet (siehe 
Logikplan).
Programmiert habe ich in Assembler mit dem Programm Atmel Studio 6.0. 
Hier ist der Quellcode:
;  --------------------------------------------------
;  Test-Projekt: ATmega8 - blinkende LED an Port PB0,
;  bei 4 MHz ergibt sich eine Frequenz von ca. 1 Hz
;  --------------------------------------------------
;
.include "m8def.inc"      ;Definitionsdatei laden

start:  ldi  r16,low(ramend)
  ldi  r17,high(ramend)  ;Adresse vom RAM-Ende laden
  out  spl,r16      ;Stackpointer auf
  out  sph,r17      ;RAM-Ende setzen
  ldi  r16,0b00000001    ;PortB: PB0 auf Ausgang
  out  ddrb,r16    ;setzen
  clr  r16      ;Datenwert für Ausgabe setzen
;
loop:  out  portb,r16    ;Daten an PortB ausgeben
  rcall  wait      ;Warteschleife aufrufen
  inc  r16      ;Datenwert erhöhen
  rjmp  loop      ;Programmschleife neu beginnen
;
;  Warteschleife (ungefähr 500ms)
;
wait:  ldi  r19,10      ;r19,r18,r17 -> 3-Byte-Zähler
  clr  r18      ;höchstes Byte = 10, restliche
  clr  r17      ;Bytes = 0
wait1:  dec  r17      ;niedrigstes Byte -1
  brne  wait1      ;0 erreicht? nein -> Schleife
  dec  r18      ;mittleres Byte -1
  brne  wait1      ;0 erreicht? nein -> Schleife
  dec  r19      ;höchstes Byte -1
  brne  wait1      ;0 erreicht? nein -> Schleife
  ret        ;Schleifenende, Rückkehr
;

Nach einem „Build“ habe ich die Hex-Datei des Projektordners „Debug“ mit 
dem Programm Ponyprog auf den Controller übertragen .Die Kommunikation 
erfolgt hier über ein Atmel ISP seriell Programmer Kabel von der Firma 
Anvilex. Ich hab vor ein paar Monaten schon einmal mit Ponyprog über dem 
PC und das ISP-Kabel einen Atmega8-Prozessor erfolgreich beschrieben und 
die Hardware sollte richtig konfiguriert sein.

Die Übertragung erfolgt in diesem Fall fehlerfrei, Die LED blinkt aber 
nicht.

Nun meine Fehlersuche:
1.  Led direkt zwischen VCC <-1kR-> und GND geschaltet  - Ergebnis LED 
funktioniert generell
2.  An den Ausgängen liegen laut Messgerät weder 5V noch GND an
3.  Atmega8 – Prozessor ausgetauscht = Ergebnis: LED blinkt nicht
4.  Schaltung und Programm von PortB nach PortD modifiziert =  Ergebnis: 
LED blinkt nicht, Port D verhält sich genau wie PortB

Ich hab aber auch ein paar Probleme gefunden und behoben:

Laut Datenblatt kann der Prozessor ein VCC zwischen 4,5 und 5,5V ab und 
die Mikroprozessoren,  die Serielle Schnittstelle des PC’S oder das 
ISP-Programmierkabel können theoretisch beschädigt worden wenn eine 
höhere Versorgungsspannung anliegt.
Mit einem Messgerät habe ich herausgefunden, dass VCC zwischenzeitlich 
bei 5,9V lag. Ich hab das dann direkt auf 5,0V runterreguliert.
1.)  Kann es etwa sein, dass die Hardware durch die 0,4 V zu hohe 
Spannung beschädigt wurde?

Bei der Verschaltung hatte ich zwischenzeitlich einen Fehler drin, da 
ich nicht ins Datenblatt geschaut hatte und davon ausgegangen bin dass 
der Pin 15 anstatt unten rechts oben rechts liegt. Hab das gemerkt, weil 
ich in Ponyprog beim Schreiben eine Fehlermeldung bekam. Durch den 
Fehler lagen einige Ports vermutlich kurzzeitig an VCC und GND und 
könnten beschädigt worden sein. Nach meiner Korrektur konnte ich aber 
mit Ponyprog den Mikrokontroller erfolgreich beschreiben.

2.)  Kann es sein, dass man per Ponyprog noch den Mikrokontroller 
beschreiben kann, die Ports aber trotzdem nicht funktionieren?

Ich wäre Euch super dankbar wenn ihr mir weiterhelfen könntet.

Ich hab parallel auch noch neue Prozessoren bestellt, möchte aber 
gewappnet sein, falls diese auch nicht funktionieren

[Karl H. (kbuchegg)]

Smarki schrieb:

> Ich hab parallel auch noch neue Prozessoren bestellt,

Du hast dann hoffentlich ein paar 7805 Spannungsregler mitbestellt.
So was:
> Mit einem Messgerät habe ich herausgefunden, dass VCC
> zwischenzeitlich bei 5,9V lag.
darf nicht passieren. Und mit einem 7805 + Steckernetzteil passiert es 
auch nicht. Da ist ein Festspannungsnetzteil jedem einstellbaren 
überlegen.

Aber das muss nicht das Problem sein. Die µC stecken so manches Problem 
weg. Nur wenn man sie zu sehr malträtiert, kann es natürlich schon auch 
sein, dass du die Ausgangstreiber geschossen hast.


Welchen Pegel misst du am Reset Pin?

[Icke ®. (49636b65)]

Der µC ist auf internen Oszillator gefused? Weil, ich sehe keine externe 
Taktquelle?

[Smarki (Gast)]

Hallo und danke für die Antwort.

Das mir der Versorgungsspannung ist natürlich bitter und ich hab sogar 
noch 7805 Festspannungsregler zuhause parat. Vor meinen nächsten Tests 
werde ich natürlich die Versorgungsspannung stabilisieren.
Ich hab jetzt leider keine Möglichkeit den Pegel am Reset zu messen, 
werde es aber heute Abend durchführen.
Gruß,
Smarki

[Smarki (Gast)]

Ist der ATmega8 nicht intern default mit 1 MHz geschaltet?

Mein Code entspreicht dem Posting und ich hab nichts weiter 
konfiguriert....

[spess53 (Gast)]

Hi

Leuchtet deine Led, wenn du (ohne Controller) den Pin auf Masse legst?

MfG Spess

[Smarki (Gast)]

spess53 schrieb:
> Leuchtet deine Led, wenn du (ohne Controller) den Pin auf Masse legst?

Ja, die LED leuchtet (siehe Fehlersuche 1)

1.  Led direkt zwischen VCC <-1kR-> und GND geschaltet  - Ergebnis LED
funktioniert generell

Gruß,
Smarki

[F. K. (superpcfan)]

Ein paar Ideen auf die Schnelle:

- kleiner Kondensator zwischen Reset und Gnd fehlt
- Könnte es ein Problem wegen der fehlen Interupt Vektor Tabelle geben?
- Ist der Watchdog Timer noch an?

[Smarki (Gast)]

F. K. schrieb:
> - kleiner Kondensator zwischen Reset und Gnd fehlt

Das dürfte eigentlich nicht so soooooo kritisch sein, da Der 
Pullup-Widerstand 10k den Reset in einen genügend stabilen Zustand 
bringt.
>
> - Könnte es ein Problem wegen der fehlen Interupt Vektor Tabelle geben?

Ich glaube nicht. In allen Tutorials "erste Schritte mit den Atmega8" 
wurden hier keine Anpassungen vorgenommen. Hier ist ein Beispiel: 
http://www.dieelektronikerseite.de/uC%20Ecke/Lections/AVR-ASM/Erste%20Befehle%20-%20Mit%20Assembler%20das%20Laufen%20lernen.htm
>
> - Ist der Watchdog Timer noch an?

Interessant, wie kann ich das überprüfen oder ihn zwingend ausschalten?

[F. K. (superpcfan)]

Natürlich ist die Interrupt Vektor Tabelle theoretisch erstmal 
überflüssig, wenn man keine Interrupts verwendet.
Das bedingt aber, das alles so läuft, wie man es erwartet.

Wenn jetzt ungewollt ein Interrupt auftritt und in dem Vektor kein 
sinnvolles Sprungziel steht, gibt's Datensalat.

Für den Watchdog gibts drei herangehensweisen:
1. Der ASM Befehl "wdr" setzt den Timer zurück. Pack den Befehl in jede 
Schleife und der Wachhund wird zahm.

2. Der Watchdog kann beim Atmega8(wenn ich mich reht erinnere) durch 
Fusebits abgeschaltet werden.

3. Der Watchdog kann auch per Software abgeschaltet, die Register dafür 
stehen im Datenblatt.

[Rudi M. (rudimentaer)]

Smarki schrieb:
> 2.)  Kann es sein, dass man per Ponyprog noch den Mikrokontroller
> beschreiben kann, die Ports aber trotzdem nicht funktionieren?

Hast Du schon mal die gegenprobe gemacht, also den Controller ausgelesen 
und den Fileinhalt mit dem Hexfile auf plausibilität geprüft?

Kannst Du die Fuses des Controller auslesen?

Poste mal das Ergebnis.
R.

[Karl H. (kbuchegg)]

F. K. schrieb:

> Wenn jetzt ungewollt ein Interrupt auftritt und in dem Vektor kein
> sinnvolles Sprungziel steht, gibt's Datensalat.

Solange im Programm kein sei vorkommt passiert da gar nichts.

> 2. Der Watchdog kann beim Atmega8(wenn ich mich reht erinnere) durch
> Fusebits abgeschaltet werden.

Der ist auch abgeschaltet, wenn der Mega von Atmel geliefert wird. 
Solange er also nicht an den Fuses gespielt hat, ist der aus.


Smarki.
Mach mal ein einfacheres Testprogramm rein

.include "m8def.inc"      ;Definitionsdatei laden

  ldi   r16,0b11111111
  out   DDRB,r16

loop:
  ldi   r16,0b10101010
  out   PORTB,r16
  rjmp  loop

Eigentlich sollten jetzt die Pins am Port B immer abwechselnd 0 und 1 
sein.
Also Pin 0 auf 0, Pin 1 auf 1, Pin 2 auf 0, Pin 3 auf 1, etc.

[Smarki (Gast)]

Rudi M. schrieb:
> Hast Du schon mal die gegenprobe gemacht, also den Controller ausgelesen
>
> und den Fileinhalt mit dem Hexfile auf plausibilität geprüft?

Ja, Hexfile und Speicher stimmen überein

>
> Kannst Du die Fuses des Controller auslesen?

Ich versuche es heute Abend mal mit Ponyprog und poste dann den 
Screenshot

[Jens G. (jensig)]

Schonmal nach Anlegen der Ub die Resettaste gedrückt? Um Resetprobleme 
beim "Hochfahren" des µC aus dem Wege zu gehen ...

[Rudi M. (rudimentaer)]

Smarki schrieb:
> Ja, Hexfile und Speicher stimmen überein
> ...
> Ich versuche es heute Abend mal mit Ponyprog und poste dann den
> Screenshot

Poste auch das ausgelesene Hexfile, das kann man dann debuggen.

R.

[Smarki (Gast)]

Jens G. schrieb:
> Schonmal nach Anlegen der Ub die Resettaste gedrückt? Um Resetprobleme
>
> beim "Hochfahren" des µC aus dem Wege zu gehen ...

Nein, von Resetprobleme hab ich noch nie was gehört. Und dann bei zwei 
verscheidenen µC dasselbe Problem?
Bin aber offen für alles und teste es ASAP in diesem Projekt:

> Karl Heinz Buchegger schrieb:
> Smarki.
>
> Mach mal ein einfacheres Testprogramm rein
>
> .include "m8def.inc"      ;Definitionsdatei laden
>
>
>
>   ldi   r16,0b11111111
>
>   out   DDRB,r16
>
>
>
> loop:
>
>   ldi   r16,0b10101010
>
>   out   PORTB,r16
>
>   rjmp  loop

[Karl H. (kbuchegg)]

Smarki schrieb:
> Jens G. schrieb:
>> Schonmal nach Anlegen der Ub die Resettaste gedrückt? Um Resetprobleme
>>
>> beim "Hochfahren" des µC aus dem Wege zu gehen ...
>
> Nein, von Resetprobleme hab ich noch nie was gehört. Und dann bei zwei
> verscheidenen µC dasselbe Problem?

* Reset Pin: Pegel feststellen, wenn der Brenner von der Schaltung
  weg ist.
* Verifizieren ob das Gebrannte auch tatsächlich im µC steht
* Ansonsten poste mal ein Foto (aber scharf und so das man auch was
  erkennen kann!) deines Aufbaus.
  Das stinkt danach, als ob da was im Aufbau schief gegangen ist.

An defekte µC, und schon gar an 2 defekte brandneue µC, glaub ich erst 
wenn alle anderen Möglichkeiten ausgeschöpft sind.

[Rudi M. (rudimentaer)]

Karl Heinz Buchegger schrieb:
> * Verifizieren ob das Gebrannte auch tatsächlich im µC steht

Und ob das gebrannte auch dem Quelltext entspricht. Wäre nicht das erste 
mal das ein falsches (altes) Hexfile gebrannt wurde... ;-)

[Smarki (Gast)]

Karl Heinz Buchegger schrieb:
> * Ansonsten poste mal ein Foto (aber scharf und so das man auch was
>
>   erkennen kann!) deines Aufbaus.
>
>   Das stinkt danach, als ob da was im Aufbau schief gegangen ist.

Ist der Logikplan OK? Ich nehme mir dann die Zeit und verdrahte die 
Schaltung von Grund aus noch einmal ganz von neuem...

Karl Heinz Buchegger schrieb:
> An defekte µC, und schon gar nicht an 2 defekte brandneue µC, glaub ich
>

Brandneu ist relativ, ich hab beim ersten Versuch ja einige Ports 
fehlerhaft beschaltet und eine etwas zu hohe Betriebsspannung angelegt. 
Ich glaube sogar bei beiden yC (kopfschüttel)

Smarki schrieb:
> Mit einem Messgerät habe ich herausgefunden, dass VCC zwischenzeitlich
>
> bei 5,9V lag. Ich hab das dann direkt auf 5,0V runterreguliert.
>
>
> Bei der Verschaltung hatte ich zwischenzeitlich einen Fehler drin, da
>
> ich nicht ins Datenblatt geschaut hatte und davon ausgegangen bin dass
>
> der Pin 15 anstatt unten rechts oben rechts liegt. Hab das gemerkt, weil
>
> ich in Ponyprog beim Schreiben eine Fehlermeldung bekam. Durch den
>
> Fehler lagen einige Ports vermutlich kurzzeitig an VCC und GND und
>
> könnten beschädigt worden sein. Nach meiner Korrektur konnte ich aber
>
> mit Ponyprog den Mikrokontroller erfolgreich beschreiben.

[Smarki (Gast)]

Rudi M. schrieb:

> mal das ein falsches (altes) Hexfile gebrannt wurde... ;-)

Ja ja :-) Aber ich habe zig verschiedene Testprogramme übertragen, aber 
nix motiviert die Ports mal den Zustand zu ändern.... :-)

[Karl H. (kbuchegg)]

Smarki schrieb:
> Rudi M. schrieb:
>
>> mal das ein falsches (altes) Hexfile gebrannt wurde... ;-)
>
> Ja ja :-) Aber ich habe zig verschiedene Testprogramme übertragen, aber
> nix motiviert die Ports mal den Zustand zu ändern.... :-)

Sagen wir mal so:
Du hast das Hex-File in den Brenner gestopft. Ob es auch tatsächlich im 
µC gelandet ist, ist bis jetzt erst mal nur eine unbelegte Hypothese, 
weil es halt im Normalfall so ist.

Wenns um Fehlersuche geht, gilt erst mal alles als 'möglicher Fehler', 
bis man es durch einen expliziten Test ausschliessen kann.
In dem Fall ist das ja leicht möglich. µC auslesen und vergleichen

[Rudi M. (rudimentaer)]

Smarki schrieb:
> Aber ich habe zig verschiedene Testprogramme übertragen

Na ja deshalb hab ich das ja geschrieben, bist Du sicher, das Du die zig 
Programme auch wirklich übertragen hast? Ich hab auch schon mal Fehler 
korrigiert umd immer das gleiche (falsche) Programm übertragen weil es 
voreingestellt war...

Das Problem sitzt halt meistens vor dem Bildschirm, das gilt ganz 
besonders fürs programmieren... Und das ist auch kein Angriff auf Deine 
Fähigkeiten, da ist bestimmt den meisten hier schon mal passiert.

Hast Du auch mal andere Ports benutzt? Wenn das programmieren 
funktioniert müssten ja mindestens die vom ISP Port noch intakt sein.

R.

[Smarki (Gast)]

Karl Heinz Buchegger schrieb:
> bis man es durch einen expliziten Test ausschliessen kann.
>
> In dem Fall ist das ja leicht möglich. µC auslesen und vergleichen

Ich drücke zum auslesen den im Bild(Pony.gif) markierten Button, oder?

[Karl H. (kbuchegg)]

Smarki schrieb:
> Karl Heinz Buchegger schrieb:
>> bis man es durch einen expliziten Test ausschliessen kann.
>>
>> In dem Fall ist das ja leicht möglich. µC auslesen und vergleichen
>
> Ich drücke zum auslesen den im Bild(Pony.gif) markierten Button, oder?

Yep

[Uwe (Gast)]

Du solltest immer folgende Schritte tun (die lassen sich im Ponyprog 
sogar konfigurieren und auf den shortcut ctrl^p legen):
1. Erase
2. Program
3. Verify

[Smarki (Gast)]

Rudi M. schrieb:
> Das Problem sitzt halt meistens vor dem Bildschirm, das gilt ganz
>
> besonders fürs programmieren... Und das ist auch kein Angriff auf Deine
>
> Fähigkeiten, da ist bestimmt den meisten hier schon mal passiert.
>
>
>
> Hast Du auch mal andere Ports benutzt? Wenn das programmieren
>
> funktioniert müssten ja mindestens die vom ISP Port noch intakt sein.

Schusselig genug bin ich in jedem Fall und der Fehler würde zu mir 
passen :-) Ich hab aber nach dem Schreiben Ponyprog neu gestartet und 
den Speicherinhalt überprüft. Es waren Änderungen zu erkennen.

Kann es evtl. auch sein dass irgendein Upgrade von Windows XP SP3 mir 
einen Strich durch die Rechnung macht und Ponyprog deshalb nicht korrekt 
schreibt?

Mit diesem Testprogramm kann ich dann ja auch überprüfen ob was am ISP 
anliegt….
>
> .include "m8def.inc"      ;Definitionsdatei laden
>
>
>
>   ldi   r16,0b11111111
>
>   out   DDRB,r16
>
>
>
> loop:
>
>   ldi   r16,0b10101010
>
>   out   PORTB,r16
>
>   rjmp  loop

[Rudi M. (rudimentaer)]

Smarki schrieb:
> Kann es evtl. auch sein dass irgendein Upgrade von Windows XP SP3 mir
> einen Strich durch die Rechnung macht und Ponyprog deshalb nicht korrekt
> schreibt?

wenn Du damit meinst, das ein funktionierendes Programm falsch 
geschrieben wird ohne das der verify das merkt... Nein.

>
> Mit diesem Testprogramm kann ich dann ja auch überprüfen ob was am ISP
> anliegt….
Ja, klar, das ist sogar noch besser, weil keine delayschleife drin ist 
und damit Fehler vermieden werden.

Voraussetzung ist aber auch hier, das das Programm korrekt geschrieben 
wird.

Lies doch mal das aus was drinsteht und poste es (als Hexfile, nicht 
screenshot). Dann kann man auch verifizieren (im simulator) ob das 
Programm tut was es soll...

[Uwe (Gast)]

Übrigens wenn man nur programmieren drückt dann werden nur Bits auf Null 
gesetzt, eine 1 kann man nicht programmieren sondern nur Erasen.

z.B. eine Erase(te) Flash Zelle:
0b11111111 oder 0xFF

z.B. eine programmierte Flash Zelle:
0b00100101 oder 0x25

Wenn du jetzt danach 0b00100010 bzw. 0x22 in DIESE schon programmierte 
flash Zelle schreiben willst müßte nun Bit 1 und Bit 5 gesetzt werden 
alle anderen gelöscht. Bit 5 ist schon gesetzt alles OK. Bit 1 ist schon 
Null und kann so nicht wieder auf gebracht werden. Bit 0 und Bit 2 
werden hingegen gelöscht.
Also steht danch 0b00100000 bzw. 0x20 in der Zelle.
Man kann nur Nullen programmieren !
Einsen erzeugst du durch das Erasen !

[Smarki (Gast)]

Uwe schrieb:
> 1. Erase
>
> 2. Program
>
> 3. VerifyBeitrag melden Bearbeiten Löschen

Danke für dem Hinweis, Erase hab ich nie benutzt...

Mir ist noch aufgefallen, dass der Schreibvorgang beim gleichen 
.Hex-File teilweise nur ca 0,5 Sekunden dauert und manchmal dauert er 
genauso lange wie das "Verify" nach dem Schreiben (ca. 7s). Ist das 
normal, oder bricht das Programm bei einem so kurzen Schreibvorgang ab? 
Bei beiden Aktionen meldet Ponyprog "erfolgreich geschrieben"

[Smarki (Gast)]

Smarki schrieb:
> Mit diesem Testprogramm kann ich dann ja auch überprüfen ob was am ISP
> anliegt….

> .include "m8def.inc"      ;Definitionsdatei laden
>
>  ldi   r16,0b11111111
>  out   DDRB,r16
>  loop:
>  ldi   r16,0b10101010
>  out   PORTB,r16
>  rjmp  loop


Hallo, ich hab gestern noch das Programm auf den Controller geladen und 
die LED leuchtet an einigen Pins vom Ports laut dem Bitmuster des 
Programms. Komischerweise funktionieren aber nur die Pins über die auch 
das ISP  kommuniziert (PB3, PB4, PB5, PB6).
PB0, PB1, PB2, PB7, PB8 zeigen keine Reaktion.
Ich hab mal die Fusebits ausgelesen. Darüber hinaus hab ich auch noch 
den Speicher ausgelesen. Beide Dateien findet ihr in der Anlage.
Vielleicht fällt einem von Euch ja was auf den ersten Blick auf. Da sich 
der PortD immer noch nicht schalten lässt tippe ich mittlerweise auf 
defekte Controller....

[Hubert G. (hubertg)]

Nachdem bei den Fuses alles angehakt ist, hast du erfahrungsgemäß Unsinn 
ausgelesen.
Das heißt, die Verbindung zum Kontroller ist nicht korrekt.

[spess53 (Gast)]

Hi

>Das heißt, die Verbindung zum Kontroller ist nicht korrekt.

Das Hexfile passt aber.

MfG Spess

[Smarki (Gast)]

spess53 schrieb:
>>Das heißt, die Verbindung zum Kontroller ist nicht korrekt.
>
>
>
> Das Hexfile passt aber.

Hm, war gestern um 23:30h mit und ich hab die Daten nicht mehr groß 
kontrolliert. Ich werde die Fusebits heute Abend noch einmal neu 
auslesen.

@spess53: Danke für die Überprüfung des Hexfile....

[Hubert G. (hubertg)]

Ich denke mal das nicht alles angehakt programmiert wurde.
Außerdem könnte dann durch die gesetzten Lockbits nichts ausgelesen 
werden.

[Smarki (Gast)]

Hubert G. schrieb:
> Ich denke mal das nicht alles angehakt programmiert wurde.
>
> Außerdem könnte dann durch die gesetzten Lockbits nichts ausgelesen
>
> werden.

Meine Vorgehensweise war:
1.) Erase
2.) Write
3.) Verify (Success)
Was kann denn dann schiefgelaufen sein und erkennt ein Verify nicht wenn 
was falsch läuft?

[Hubert G. (hubertg)]

Ich nehme mal an das du bei den Fuses Unsinn ausgelesen hast, wie auch 
immer.
Es wären ja nicht nur die Lockbits gesetzt, sondern es wäre auch auf 
ext. Takt gestellt.

[Rudi M. (rudimentaer)]

Hubert G. schrieb:
> Es wären ja nicht nur die Lockbits gesetzt, sondern es wäre auch auf
> ext. Takt gestellt.

Bei Ponyprog ist es allerdings andersrum, wenn ich mich recht erinnere. 
Alles was einen Haken hat ist 1 also nicht gesetzt. Immer wieder ein 
Ärgernis wenn man da nicht dran denkt und den Takt umstellen will...

Smarki schrieb:
> der PortD immer noch nicht schalten lässt tippe ich mittlerweise auf
> defekte Controller....

Also wenn das Programm auch auf Port D geändert war denke ich das auch 
mittlerweile. Obwohl das Fehlerbild sehr seltsam ist. Aber wer weis was 
beim probieren alles an Pegeln wo angelegen hat.
Klemmst Du den ISP Port ab, wenn Du die Pegel misst?


Smarki schrieb:
> Was kann denn dann schiefgelaufen sein und erkennt ein Verify nicht wenn
> was falsch läuft?

Doch, wenn der Programmer funktioniert wird das erkannt. Eine häufige 
Fehlerquelle sind halt die "einfachst Programmer" und auch Ponyprog 
(siehe Fuses), gerade für einen Anfänger. Das klappt nicht immer und die 
Fehlermeldungen sind oft nicht da, oder schlecht verständlich.

Rudi

P.S. das ausgelesene Testprogramm arbeitet jedenfalls so wie es soll.

[Hubert G. (hubertg)]

Rudi M. schrieb:
> Bei Ponyprog ist es allerdings andersrum, wenn ich mich recht erinnere.
> Alles was einen Haken hat ist 1 also nicht gesetzt. Immer wieder ein
> Ärgernis wenn man da nicht dran denkt und den Takt umstellen will...

Du  erinnerst dich nicht recht.
Du solltest mal ins Fenster von PonyProg schauen, ein Haken ist 0 und 
programmed.

[Smarki (Gast)]

Rudi M. schrieb:
> Klemmst Du den ISP Port ab, wenn Du die Pegel misst?

Ja, obwohl PortD eigentlich auch völlig unabhängig vom ISP sein müsste.

Ich layoute in den nächsten Tagen ein kleines für mich optimiertes 
Testboard mit einem stabilisierten VCC, ein paar Tastern und LED’s, da 
ich demnächst mehrere kleine Anwendungen umsetzten möchte und dafür eine 
stabile Entwicklungsumgebung benötige. Dann spare ich mir die 
Basisschaltungen auf dem Experimentierboard und kann so 
Verdrahtungsprobleme im Aufbau vermeiden.
Ich hab gestern fünf neue Mikrocontroller bekommen und wenn das 
Testboard funktioniert, setze ich die beiden Pflegefälle noch einmal in 
das Board. Dann habe ich alle Möglichkeiten den Fehler einzukreisen und 
berichte natürlich auch was faul war.

[Hubert G. (hubertg)]

Wenn du ein neues Board layoutest, dann lege AREF nicht auf VCC, sondern 
nur über einen 100n Kondensator auf GND.
Das ist ein Unfug der leider in vielen Beispielen zu sehen ist.
Weiters solltest du für AVCC einen eigenen 100n Kondensator vorsehen.
Die Kondensatoren für VCC und AVCC so nahe wie möglich an die Pins 
plazieren.

[Dietrich L. (dietrichl)]

Smarki schrieb:
> ein paar Tastern

Da solltest Du noch Strombegrenzungwiderstände spendieren (in Reihe mit 
den Tastern). Sonst hast Du das gleiche Problem wie beim Pollin-Board, 
wo beim Betätigen der Taster Vcc einbricht (durch Laden der 330nF) und 
der µC resetten kann.

Gruß Dietrich

[Smarki (Gast)]

Dietrich L. schrieb:
> Da solltest Du noch Strombegrenzungwiderstände spendieren (in Reihe mit
>
> den Tastern).

Ich hab den Teil auch beim Pollin-Board übernommen. Hast Du einen 
Vorschlag für den Wert?

[Hubert G. (hubertg)]

Für die Reset-Beschaltung solltest du dir die App.Note AVR042 ansehen.
Ob du die Tasten nicht gegen GND schaltest und die internen PullUp 
verwendest, solltest du dir auch überlegen.
Du hast da die schlechten Teile des Pollin Boards übernommen.

[Smarki (Gast)]

Hubert G. schrieb:
> Ob du die Tasten nicht gegen GND schaltest und die internen PullUp
>
> verwendest, solltest du dir auch überlegen.


Hab ich auch schon einmal so umgesetzt. Mir fehlte nur etwas ein C zum 
entprellen....

[Hubert G. (hubertg)]

Ich habe mein Pollin-Board umgebaut, die Tasten gegen GND geschaltet und 
10n parallel zu den Tasten. Die Tasten prellen dann fast nicht mehr.
In der Software sehe ich aber grundsätzlich Entprellen vor.

[Smarki (Gast)]

Hubert G. schrieb:
> Ich habe mein Pollin-Board umgebaut, die Tasten gegen GND geschaltet und
>
> 10n parallel zu den Tasten. Die Tasten prellen dann fast nicht mehr.
>
> In der Software sehe ich aber grundsätzlich Entprellen vor.


Wenn ich die  App.Note AVR042 richtig lese sollte man beim Reset auch 
einen 330R in Reihe schalten und nicht direkt auf GND gehen.

Hast Du bei den Eingängen zur Strombegrenzung auch noch einen Widerstand 
in Reihe geschaltet?

[Hubert G. (hubertg)]

Wenn die Tasten auf GND gehen sind keine Strombegrenzungswiderstände 
notwendig. Es werden ja keine Kondensatoren entladen.
Die 330Ohm sind Obergrenze, 100Ohm genügen in Serie zum Taster. Der 100n 
Kondensator gehört aber dann nicht auf die VCC- sondern auf die 
RESET-Seite.

[Karl H. (kbuchegg)]

Smarki schrieb:
> Hubert G. schrieb:
>> Ob du die Tasten nicht gegen GND schaltest und die internen PullUp
>>
>> verwendest, solltest du dir auch überlegen.
>
>
> Hab ich auch schon einmal so umgesetzt. Mir fehlte nur etwas ein C zum
> entprellen....

Das Entprellen machst du in Software.

Diesen Pollin Müll sollte man den Entwicklern um die Ohren hauen.


Tasten kann man ganz einfach anschliessen. Einfach vom Pin zum Taster. 
Vom Taster zu GND. Mehr braucht man nicht. Einfach, simpel und doch 
geschmacklos :-)

[Smarki (Gast)]

Danke für Eure Hilfe, ich hab jetzt noch einmal das Board modifiziert.

1.)  AREF liegt jetzt nicht mehr auf VCC sondern über 100nF auf GND
2.)  Die Taster werden jetzt mit GND beschaltet und hardwaretechnisch 
mit 10nF entrprellt
3.)  VCC und AVCC haben einen eigenen 100nF
Die Reset-Schaltung belasse ich wie sie ist. Wenn man mal googelt 
schalten neun von zehn Anwendern diesen Port standardmäßig so. Ich hab 
einen Prozessor seit drei Jahren im Einsatz und es gab noch nie 
Probleme.

Viele Grüße,
Smarki

[Rudi M. (Gast)]

Hubert G. schrieb:
>> Bei Ponyprog ist es allerdings andersrum, wenn ich mich recht erinnere.
>> ...
> Du  erinnerst dich nicht recht.
> Du solltest mal ins Fenster von PonyProg schauen, ein Haken ist 0 und
> programmed.

Na wo Du Recht hast, hast Du Recht...
Was den Programmer wieder in den Fokus der Fehlerquelle rückt, wenn der 
schon die Fuses falsch liest...