Hallo Kollegen, ich habe einen ATMega16 auf einer Platine, die bisher gut funktionierte, ich benutze sie als Testbord. Nachdem ich einen neuen Sensor eingelötet habe und die Software aufspielte, ging nix mehr. Nach langer Fehlersuche (ohne Befund): Sensor wieder ab und den ATMega gewechselt-> er lässt sich nur einmal Programmieren, dann ist schluss. Selbst das Auslesen der Fusebits geht dann nicht mehr. Es kommt beim Proggen die Fehlermeldung "Unable to lock, bad device or device locked". Inzwischen habe ich den dritten Atmel vergeigt: man kann solange drauf zugreifen (z.B. Fusebits auslesen) bis er programiert wird. Ich benutze Ponyprog oder Codevision, beide mit gleichem Stress. Meine ATMega8-Platine funktionert reibungslos. Kann mir jemand helfen? Habe ich beim Programieren die Fusebits geändert? Geht das überhaupt. Danke im Voraus Günni PS: Versorgungsspannung habe ich inzwischen 100 mal gemessen, immer Okay.
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
Was hast du denn für einen Programmer? Ich könnte mir vorstellen, dass die HC244 variante auch ne Ursache sein kann.
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
...wo hängt denn der Sensor dran? Haben die benutzten Pins was mit der ISP-Schnitte gemeinsam? Ansonsten kann ich immer nur wiederholen: die paar (~30) Kröten für ein ATAVRISP sind die beste Investition, die ein AVR-Freak tätigen kann...
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
>"Unable to lock, bad device or device locked"
Klingt für mich irgendwie so als würdest du (wieso auch immer) versuchen
nach der Programmierung die Lockbits zu setzen ... (Kann sein dass das
jetzt schon gesagt wurde aber beim überfliegen hab ichs ncih gesehen)
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
>>Aber wie könnte ich dann die Atmels retten? An Deiner Stelle würde ich es mit einem STK500 oder AVR Dragon versuchen. Software gibt´s kostenlos. BTW: kann es sein, daß Dein Programm Lockbits verstellt? So per "SPM" vielleicht irgendwo...?
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
Thread beobachten
Seitenaufteilung abschalten![http://www.blafusel.de/bilder/misc/upc/atmega8-2.gif"](http://www.blafusel.de/bilder/misc/upc/atmega8-2.gif"){kind=link}
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.