ATMega16 gesperrt

Hallo,

wenn das Board wirklich zuverlässig zu prgrammieren ging, bis Du den 
Sensor angelötet hast, würde ich dort auf die Suche gehen.
Zinnbrücke, Zinnkrümel an der unsinnigsten Stelle verklemmt, 
Unterbrechung am einzigen wichtigen Lötauge erzeugt usw. usw.

Meine persöhliche Variante: nöglichst alle Verbindungen (oder alle 
wichtigen für die gewollte Funktion) auf Durchgang prüfen, dabei auch 
auf Schluß gegeneinander und gegen GND bzw. +UB prüfen.
ICs alle Pins gegen GND, wenn es piept kontrollieren, ob es wirklich ran 
muß, selbiges gegen Ub, alle IC-Pins und Steckverbinder jedes Pin gegen 
seine direkten Nachbarn auf Schluß prüfen. Lötaugen mit sehr kleinem 
Abstand auf Schluß prüfen.

Klingt aufwändig, dauert aber bei mir selbst bei  bei relativ vielen 
Bauteilen höchstens 20-30min.
So habe mir schon öfter "plötzlich" auftretende Fehler in 
Experimentieraufbauten und auf Lochrasterplatinen gefunden, merklich 
schneller als durch stundenlanges Rätselraten, weil nicht sein kann, was 
nicht sein darf. ;)

Gruß aus Berlin
Michael

Hallo,

@Henrik Jahnke:
deshalb mein erster Satz. ;)
Ich benutze auch eine HC(T)244 Version und hatte noch nie Probleme 
damit.
Der Programmiert auch Mega16 mit 16MHz auf dem Steckbrett absolut 
zuverlässig, wenn der Rechner dabei noch in 16x DVD brennen muß... :)

Gruß aus Berlin
Michael

Danke schon mal für die Antworten,

das mit den Lötbrücken/Krümeln etc. hab ich natürlich auch zuerst 
gedacht. Inzwischen mehrere Stunden daran verbracht, jeden unötigen Kram 
runtergelötet, etliche male nachgemessen. Inzwischen sind nur noch 
Spannungsversorung und Schnittstelle drauf. Dann nochmal kontrolliert. 
Und wie gesagt: Zugriff zum Controller ist solange möglich, bis ich das 
erste mal (pro Atmel) programmiere.
Übrigens verwende ich (bisher ohne Probleme) die HC(T)244 Version. Mein 
anderes Board funzt noch einwandfrei.

Gruß
Günni

klingt nach "zerfust". Wenn man den externen Clock deaktiviert, läßt er 
sich nicht mehr programmieren, da er keinen externen Clock mehr hat.
Da hilft nur wegschmeißen oder auf Parallel Programmer versuchen das 
Ding zu retten.

>Wenn man den externen Clock deaktiviert, läßt er
>sich nicht mehr programmieren, da er keinen externen Clock mehr hat.
>Da hilft nur wegschmeißen

Das ist Unsinn. Wenn man CSEL0..3 versehentlich auf 0000 setzt (also
die Fuses programmiert), hat man immer noch die Möglichkeit, einen
externen Quarzoszillator anzuschließen und kann dann wieder 
programmieren.

...das ich den Atmel "zerfused" habe dachte ich natürlich auch zuerst. 
Aber ich habe ja gar keine Fuse gesetzt. Der Controller funzt definitiv 
"nach dem Programmieren" nicht mehr. Kann man durch Programmieren die 
Fuses umsetzen? Habe leider kein Oszi zum testen. Ich habe übrigens mein 
Makefile im ersten Tread mit reingesetzt. Aber ich sehe keinen Hinweis, 
das dabei die Fuses geändert werden. Ansonsten wäre der Fall ja klar und 
ich wüsste, wie ich weitermachen kann. Aber so...

Gruß
Günni
PS: @ Stefan Wimmer: kann man mit dem AVRISP auch High Voltage 
Programmieren? Wollte diese Anschaffung nächstens tätigen.

Hallo,

"Ich habe übrigens mein
Makefile im ersten Tread mit reingesetzt. Aber ich sehe keinen Hinweis,
das dabei die Fuses geändert werden."

Und ich sehe keinen Hinweis auf den "ersten Tread" und werde ihn mir 
deshalb auch nicht anschauen...

Gruß aus Berlin
Michael

Ich würde das Testboard mal aufgeben und den Atmega16 auf einem neuen 
Minimalaufbau anschauen. Was kannst du messen? Hast du Möglichkeiten zu 
oszilloskopieren?

´tschuldigung falls ich falsche Worte verwendet habe, ich meinte den 
ersten Eintrag (Beitrag) in diesem Tread. Aber ich sehe gerade, auch 
dort ist er irgendwie nicht gelandet. Werde ich schnellstmöglich 
nachholen.
Gruß
Günni

Hallo Stefan,
leider habe ich kein Oszi. Am Board (Lochrasterplatine) kann es 
definitiv nicht liegen, da ich bis auf Spannung und 
Programmierschnittstelle nix mehr drauf habe. Also nur noch 7 
Lötstellen. Vorher waren da noch Taster und LEDs. Aber das Board funzt 
ja auch bis zum ersten Programmieren.

Gruß
Günni

Hallo,

naja, irgendwie verliere ich etwas den Überblick... ;)

Hast Du mal nur PonyProg bemüht (weil ich es selber nutze), über das 
Command-Menu nur die Security und configurationsbuts gelesen?
Macht er das?
Irgendein .hex in Pony reingeladen und nur Write Program (Flash) 
gemacht?
Macht er das?
Macht er danach Verify Program (Flash) oder ist er da schon tot?

Wie programmierst Du normalerweise mit Pony? Write All?
Wie stehen da die Program Options?
Wenn z.B. Write Security and Config Bits aktiv ist, weiß ich auch nicht 
genau, was er da schreibt, benutze ich nie, ist aus bei mir.

Codevision weiß ich nichts zu...

Gruß aus Berlin
Michael

Hallo Michael,

er liest die Bits nicht. Ich habe jetzt aber noch mal probiert: wenn ich 
beim Fusebitlesen "Ignore" sage, dann kann ich die Bits (scheinbar) 
auslesen. Ich kann sie auch scheinbar zurückschreiben, aber ohne Erfolg. 
Das kann natürlich auch eine Müllanzeige sein, weil er ja nicht lesen 
kann.
Ich habe (wie Du es beschrieben hast), das .hex mit "write programm" 
geschrieben. Danach geht nix mehr, auch kein Verify. Die Programm 
Options sagen ebenfalls nur "write flash".

Anbei nochmal das makefile, hoffe, das es diesmal dabei ist.

Gruß
Günni

PS: das mit dem hochladen funzt nicht, hier also:
http://www.diers-technik.de/ftp/Makefile

Hallo,

wenn er freiwillig nicht liest, ist was faul.
Ignore ist in meinen Augen ein Button, den es bei Pony besser nicht 
gäbe...

Wenn das vorher mal ging, muß es den Programmer zerlegt haben oder die 
Betriebsspannung der Geschichte hat ein Problem oder es kommen nicht 
alle Leitungen vom Programmer am ATMega an.

Das Makefile können wir dann auch ignorieren, weil es Ponyprog und dem 
ISP-Programmer völlig egal, was wir in den AVR schreiben.
Es würde sich schließlich auch eine hex-codiertes Word-Dokument brennen 
und lesen lassen. Das der AVR damit nicht viel anfangen kann, ist sowohl 
dem Flash als auch Ponyprog sowas von egal...

Geh der Sache nach, bis Pony wieder ohne Meckern liest, sonst zerlegst 
Du nur weitere Atmels...

Was für einen Programmer benutzt Du? Mit der Mega8-Platine geht der 
Programmer? Spannungsversorgung ist dabei die gleiche?

Das Verhalten verschiedener AVR-Serien (hier Mega8 und 16) kann durchaus 
unterschiedlich sein, wenn z.B. die Pegel nicht mehr hinhauen, weil bei 
einem Programmer mit 74HC(T)244 das IC angeschossen ist oder bei rein 
passiven sogar der Druckerport gelitten haben kann.

Gruß aus Berlin
Michael

RAHHHH, ich werd bekloppt.

Ich hab am Wochenende mal einen Adapter von ATMega8 auf ATMega16 gebaut. 
Und siehe da: Es klappt. Ich konnte den ATMega8 beschreiben und lesen 
wie blöd. Das das Prog nicht funzte machte mir erstmal nix, es war ja 
auf den ATMega16 programmiert, ich musste ja Softwareseitig nur ein Pin 
wechseln und dem Compiler sagen, dass es jetzt ja kein ATMega16 sondern 
ein ATMega8 ist. Gesagt, getan, gebrannt und... Das selbe Symptom. Da 
stimmt doch was nicht.

Helft mir: Kann ich mit Software (also wirklich Reiner Software, ohne an 
den Fuses zu spielen) einen ATMega zerfusen oder gar kaputtmachen?

Gruß
Günni

PS: ich komme auf diesen ATMega8 auch nicht mehr mit meinem andere Borad 
rauf. Finito, nix

Dein Bericht ist für mich schwer nachzuvollziehen. Ich verstehe nicht 
was du mit Pin wechslen usw. meinst.

Was ich glaube zu verstehen ist dies: Du hast in die problematische 
Schaltung über einen Adapter einen Atmega8 eingesetzt und programmiert. 
Und jetzt ist der genauso tot, wie die drei Atmega16, die du in der 
gleichen Schaltung abgemurkst hast.

Ich kann eigentlich nur meinen Tipp von oben wiederholen. Darauf zu 
beharren "Am Board (Lochrasterplatine) kann es definitiv nicht liegen" 
bringt dich doch offensichtlich nicht weiter, oder?

Ansonsten kannst du ja mal Butter bei die Fische geben und beschreiben, 
was du in die µC geschrieben hast (Sourcecode) und wie die Schaltung im 
Moment tatsächlich aussieht. Sinnvoll wäre es auch den Bauzustand inkl. 
Sensor und nach Entfernen des Sensors anzugeben.

Hallo Stefan,

mit Pin wechseln meine ich, dass ich, dass ich den Peter 
Fleury-Sourecode für LCD wie folgt angepasst habe:
in der LCD.h:
#define LCD_RW_PORT      PORTD     /**< port for RW line         */
#define LCD_RW_PIN       0            /**< pin  for RW line
da stand vorher PortC und Pin 6 drin.

Der Code:
#include <stdlib.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include "lcd.h"
int main(void)
{
  DDRB &= ~((1 << DDB7)|(1 << DDB6)|(1 << DDB5)|(1 << DDB4)|(1 << 
DDB3)); //als Eingang
  DDRD = ((1 << DDD6)|(1 << DDD5)|(1 << DDD4)|(1 << DDD3)|(1 << DDD2)); 
// als Ausgang
  int stlg2=92;
  /*
    /* initialize display, cursor off */
    lcd_init(LCD_DISP_ON);
  lcd_clrscr();
    lcd_puts("Testwert:");
  lcd_gotoxy(4,1);
    lcd_puts("stlgx=");
    int stlg;
  stlg=110;
  char buffer[7];
  for (;;) {                           /* loop forever */
  // wert 1
        if (PINB & (1 << PB3))  {  // wenn taste gedrückt wird
    stlg=60;

    itoa( stlg2 , buffer, 10);
    lcd_gotoxy(10,1);
    lcd_puts(buffer);

    PORTD = PORTD | (1 << DDD6);  // LED  ein
    itoa( stlg , buffer, 10);
    lcd_gotoxy(10,1);
    lcd_puts(buffer);

    }
    else {
    PORTD = PORTD &~ (1 << DDD6);  // LED  aus
    }
// wert 1
        if (PINB & (1 << PB5))  {  // wenn taste gedrückt wird
    stlg=60;
    itoa( stlg2 , buffer, 10);
    lcd_gotoxy(10,1);
    lcd_puts(buffer);
    PORTD = PORTD | (1 << DDD5);  // LED  ein
    itoa( stlg , buffer, 10);
    lcd_gotoxy(10,1);
    lcd_puts(buffer);
    }
    else {
    PORTD = PORTD &~ (1 << DDD5);  // LED  aus
    }
    }
}
Der Sensor liegt auf Pin B3, der Rest entspricht blafusels 
"http://www.blafusel.de/bilder/misc/upc/atmega8-2.gif";, also nix 
besonderes.
Und unter "Projekt->configuration options" hab ich den ATMega8 
eingestellt.
Ich hab jetzt leider keinen ATMega mehr, um mal was anderes zu testen, 
z.B. ob der Atmel auch auf dem anderen Board mit dieser Software 
abschmiert.
Gruß
Günni

1/ Das Bild http://www.blafusel.de/bilder/misc/upc/atmega8-2.gif ist 
eine Schaltung für einen Atmega8. Ich dachte dein vermaledeites 
Testboard ist für Atmega16? Fehlersuche macht eigentlich nur Sinn, wenn 
du exakt die Schaltung des Testboards angibst und auch nicht so, wie du 
denkst, dass sie aufgebaut ist, sondern exakt so wie sie aufgebaut ist 
;-)

2/ Wenn du nur
#define LCD_RW_PORT      PORTD     /**< port for RW line */
#define LCD_RW_PIN       0         /**< pin  for RW line */
geändert hast, gibt es mit der Library ein Problem. Dort wird intensiv 
PORTA genutzt. Die hättest du auch umbiegen müssen. 
http://homepage.hispeed.ch/peterfleury/group__pfleury__lcd.html

PORTA hat der Atmega8 nicht. Ich weiss nicht wie der Atmega8 auf 
Beschreiben/Lesen nonexistenter Ports reagiert (1. Versuch Atmega16-HEX 
in Atmega8 quetschen). IMHO hätte beim 2. Versuch (Recompilierung für 
Atmega8) der Compiler deswegen mosern müssen.

3/ In dem Blafusel-Bild ist mir noch Der Resetkondensator C6 mit 47 pF 
aufgefallen, während im AVR-Tutorial an der Stelle ja 47 nF verwendet 
werden. Das ist der Faktor 1000! Welchen Wert hast du an der Stelle 
verwendet?

Um eine Fehlbedienung auszuschliessen... Hast du noch eine Idee, was du 
in PonyProg gemacht hast? Gibt es da ein Logfile seitens PonyProg?

Ansonsten mal diesen Tipp versuchen, um eventuell durch irgendeine 
Aktion gesetzte Security Bits zu löschen:

Unable to probe, bad device or device locked (-25)
Ursache: Die Security Bits sind gesetzt, dieses kann folgendermaßen 
geändert werden:
- Auf -> Edit -> Security Bits -> clear all -> program (die Karte muß 
sich natürlich in der Programmer befinden )
- Den Atmel Chip notfalls mehrere Male -> device -> erase.
http://www.eubnet.tv/help/PonyProg2000-DE.html

Hallo Stefan,

vielen Dank für Deine intensive Mühe.
Den Eintrag "-> Edit -> Security Bits -> clear all -> program" Hat Pony 
bei mir nicht.
Den Port A benutze ich gar nicht und habe alles auf Port C umgeschaltet. 
Nur das R/W wird bei blafusen nicht benutzt, bei Fleury wohl, und daher 
beim ATMega8 diese Änderung. Das hat ja bis Mittwoch auch dauernd 
geklappt. Bis heute Vormittag hat das auch beim ATMega8 gefunzt, aber 
nach der obigen Änderung....
Wenn das ganze nicht so furchbar reproduzierbar wäre...
Das Board ist übrigens wirklich wür den ATMega16, habe daher diesen 
Adapter gebaut (werde es morgen mal Fotografieren).

Aber der Hinweis mit dem Reset-Kondensator werde ich mir noch mal 
reinziehen. Die Lötstellen des Kondensators konnte ich nict untersuchen 
weil .... ich keinen Resetkondensator habe. uups. Aber warum funzt er 
dann nur mit einem bestimmten Code nicht. Ich halte das für eine Lösung, 
werde morgen (so ich es schaffe) mal Atmel-Ersatz kaufen.
Aber wie könnte ich dann die Atmels retten?
Gruß
Günni

Hallo Travel,
ich wollte mir sowieso einen Brenner zulegen. Aber ich dachte an den 
günstigen 40Euro-Brenner von Reichelt. Von wegen der Preisklase. Kann 
der eigentlich auch HV-Brennen?
Eigentlich verstelle ich keine Lockbits. habe schon alle einstellungen 
angesehen. Aber vielleicht ist durch das falsche Timing (und dem 
fehlenden Kondensator) doch ein Bit gesetzt worden. Ich mag das aber 
noch nicht so recht glauben weil es so sehr reprodzierbar ist.
Gruß
Günni

>Aber ich dachte an den günstigen 40Euro-Brenner von Reichelt.

Welchen meinst Du denn?
Hoffentlich nicht das ISP 89.

>Kann der eigentlich auch HV-Brennen?

Wenn du den AVRISP mkII meinst: Nein. Das ist ein reiner ISP-Programmer.
(HV-)Parallel kann der von "der-hammer.info" oder das STK500.

Nein, der AVR-ISP kostet ja auch 40€.
Aber Parallel-Programming kann der auch nicht. Ist praktisch das gleiche
was Du schon hast