Atmega8, Ports schalten nicht

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

Ist der ATmega8 nicht intern default mit 1 MHz geschaltet?

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

Hi

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

MfG Spess

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

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?

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?

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.

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.

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

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.

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 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... ;-)

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.

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.... :-)

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.

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?

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

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

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...

Ü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 !

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 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....

Hi

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

Das Hexfile passt aber.

MfG Spess

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. 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. 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.

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.

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. 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. 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?

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

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...