ATmega8 Problem... Geht nach ein paar mal proggen nimma

[Kaiser-F]

Hallo,

Ich habe ein echt merkwürdiges Problem!

Ich habe mir einen Programmer gebaut, an welchen man vier
Controller programmieren kann....
Man kann diese per Knopfdruck über Multiplexer durchschalten.

Dazu sitzt ein ATmega8 drauf.
Der muss lediglich zwei Leitungen binär von 0-3 ausgeben (für die Multiplexer)
und vier LEDs schalten.
Und einen Taster als Eingang.

Das Ganze habe ich so geschrieben:

// -=> AVR Includes <=-
#include <avr/io.h>

int main (void){

DDRC = 0b00111100;
DDRD = 0b00011000;
PORTD |= (1<<PD2)|(1<<PD5);

uint8_t channel = 0;
uint8_t flag = 0;
uint8_t prell = 0;

// -=> Hauptschleife <=-
while(1){

if(bit_is_clear (PIND, PIND2)){
if( (!prell) && (!flag) ){ channel++; flag = 1; }else{ prell--; }
}else{
prell = 255;
flag = 0;
}

if( channel > 3 ){ channel = 0;}

switch(channel){
case 0: PORTC = ( PORTC & ~0x3C) | (0x04 & 0x3C); PORTD = ( PORTD & ~0x18 )|(0x00 & 0x18); break;
case 1: PORTC = ( PORTC & ~0x3C) | (0x08 & 0x3C); PORTD = ( PORTD & ~0x18 )|(0x08 & 0x18); break;
case 2: PORTC = ( PORTC & ~0x3C) | (0x10 & 0x3C); PORTD = ( PORTD & ~0x18 )|(0x10 & 0x18); break;
case 3: PORTC = ( PORTC & ~0x3C) | (0x20 & 0x3C); PORTD = ( PORTD & ~0x18 )|(0x18 & 0x18); break;
}
}
}

Lade ich das Programm, ist der Controller weg!
Er lässt sich nicht mehr ansprechen.
An den FUSES wurde nichts geändert. NUR geflasht!

Als ich das erste mal geflacht habe, war es das selbe Programm, nur ohne den "if(bit..." Teil. Lade ich diese, so kann man nichts mehr machen...
Controller hinüber sozusagen...

Ich flashe sonst immer ATmega32 und 128... da gabs nie sowas.
Mit dem ATmega8 stell ich mich immer so blöd an anscheinend!

Der mag mich einfach nicht hab ich das Gefühl.

Ich kann mir das nicht erklären. Ich hab ihn jetzt schon das dritte mal gewechselt. Und immerwieder kommt das Problem!

Ich hoffe Ihr könnt mir helfen.. Ich zweifle schön langsam an meinem Verstand! DAS GIBDS DOCH NICHT ODER? ](*,)

Und schön langsam geht es auch ins Geld ;-)

http://www.sir-kaiser.de/upload/Quattro4.JPG

[SprinterSB]

Welche Software verwendest du?

Ist VCC mindestens 500mV über VCC_MIN?

Du hast hoffentlich XTAL1 und XTAL2 nach aussen geführt und kannst nen anderen Oszillator anschliessen!? Ich hatte schon mal ähnlich Probleme (ATmega8 TQFP), konnte aber nicht genau fixen, was es war. Ich hatte einige Änderungen in Hard- und Software gemacht. Möglicherweise ein Silicon-Bug der nur unter bestimmten Bedingungen auftritt, hab schon öfter davon gehört. In den Errata findet sich jedenfalls nichts darüber.

[Kaiser-F]

Hallo Georg-Johann,

Danke für deine Antwort!

Hier mal der Schaltplan:
http://www.sir-kaiser.de/upload/Quattro5.JPG

Ich habe ihn ohne Quarz betreiben wollen...
Der muss ja kaum was machen... des halb möchte ich das Interne Quarz verwenden.

Aberdass der bei SOO einem SIMPLEN Programm gleich diesen
brutalen Fehler aufweist?

Soband das programm oben ist.. ist er weg!...

Meinst ob sich die FUSES zür die CLOCK-SOURCE verstellt haben?
XTAL1 und XTAL2 sind zugänglich....

[tobimc]

HI

Du hast AVCC AGND und AREF nicht mit Spannung versorgt. Der ADC liegt an PortC, und ausserdem steht im DS, das man das immer tun sollte... (auch wenn man den ADC nicht benutzt!) ;)
Versuchs einfach mal, indem du AVCC und VREF auf +VCC legst, und AGND nach GND.
Kannst du ja mit ein paar Drähten machen.

Soll diese etwas komplexe IF-Abfrage ein Tastenentprellen sein?

VLG Tobi

PS: Bilder über 800px width sind glaub ich zu groß... (warens 800??)
PS: Ok, jetzt hab ich deine if-Geschichte verstanden... ;D

[Hanni]

Lade ich das Programm, ist der Controller weg!
Er lässt sich nicht mehr ansprechen.
An den FUSES wurde nichts geändert. NUR geflasht!

Als ich das erste mal geflacht habe, war es das selbe Programm, nur ohne den "if(bit..." Teil. Lade ich diese, so kann man nichts mehr machen...
Controller hinüber sozusagen...


Mal abgesehen davon, das du den Chip niht mehr ansprechen kannst, funktioniert die Software wenigstens ??

[tobimc]

HI!

Deinen Reset hast du ja vorzüglich entstört und gepullupt.
Halte mal während des Einschaltens auf RESET auf LOW.
Dann versuch nochmal zu flashen.

Hast du evtl. ein Fehler im Layout? (Pullup von reset nach GND statt nach VCC? Lötbrücke mit Massefläche?)

Au :idea: Hast du den ISP des M8 schon auf Kurzschlüsse überprüft? Man kann mit kurzgeschlossenen ISPs zwar wunderbar in den AVR "schreiben", allerdings Lesen und fusebits und so geht garnicht... :D

VLG Tobi

[Kaiser-F]

Hallo,

Danke für die Ideen..

Vorweg möchte ich nochmal darauf hinweisen, dass ich ja zuvor immer ein paar mal flashen konnte... OHNE JEGLICHE PROBLEME...
Allerdings sah da das Progreamm etwas anders aus.
(Eigendlich nuir ohne den IF-Teil... )

Erweitere ich mein Programm dann so wie es oben steht, kann ich auch noch flashen! Er zeigt mir im PonyProg an "successful".
Aber der Mega8 ist dann (anscheinend sobald er das Programm ausführt) weg.. keine LED leuchtet, und man kann nicht mehr lesen/schreiben...

Am Layout kann es also nicht liegen..
Flashen ging ja... NUR wenn das Programm drauf ist, so wie es oben steht,
dann mag er nicht mehr.... Ein Programm das den Controller killt?


Reset beim PowerOn geht auch nicht... Leider..
Ich muss gleich mal die methode von SprinterSB versuchen mit dem
externen Oszi...


Habt ihr ausserdem noch Ideen, an was es liegen könnte?
Das ist NUR wenn ich dieses programm rauflade!
In den Fuses ist ganz normal der interne Quarz aktiviert...
an den FUSES wurde quasi nichts geändert.


EDIT: @SprinterSB:
Die VCC liegt korrekt bei 4,987V. Programmieren tuh ich mit PonyProg2000.


EDIT: Sorry wegen dem großen Schaltplan.. aber wenn ich ihn kleiner mache kann man nichts erkennen (hat aber eh nur um die 100kB)
Die anderen Bilder sind immer 800 breit.

[SprinterSB]

-- bevor du proggst, lies jedes mal mit Pony die fuses ein (auch wenn du die fuses nicht brauchst), einfach im script ein "READ_FUSE" dazuschreiben
-- ich weiß nicht, wo du deine C sitzen hast, aber ein 100nF kommt möglichst dich an den µC. zudem zupft die charge pump gründlich an vcc --> C der ähnliche Eigenschaften hat wie die Cs an der pump dicht an den 232.
-- 100pF an MOSI, MISO, SCK nach GND (bei interface PC-seitig, also nach dem Kabel)
-- versuch mal ihn aufzuwecken mit externem oszi oder quarz. oszi mit einem R von ein paar k&Omega; anschliessen, damit nix kaputt geht wenn's das nicht war.

[Kaiser-F]

Hallo SprinterSB!

Sorry, hat etwas lange gedauert! Tut mir leid!
Ich habe den Mega8 mit dem Oszi gespeist..Und es hat
funktioniert! Vielen Dank! Sowas müsste man halt wissen^^.
Wie du gesagt hast, wurde er wieder zum Leben erweckt.
Ich habe dann gleich die Fuses wieder richtig eingestellt.
Und auch wie du gesagt hast, wenn man die FUSES vorher liest, dann
funktioniert es auch wunderbar!

Könntest du mir das nochmal genauer erklären wie du das mit dem
Script gemeint hast? Ich benutze das WIN-AVR ind zum Proggen
PonyProg... ( in WinXP )

Ein 220nF sitzt direkt vor dem Mega8... Das ist generell bei meinen Boards so...

Die Frage ist nun wie man dieses Problem beheben kann...
Weil... NORMAL IST DAS NICHT... oder?

[SprinterSB]

Wie gesagt, ich vermute mal es ist ein silicon bug mit im Spiel oder/und ein Bug im Pony. Von dem Problem hab ich schon öfter gehört, (weiß jetzt nicht mehr mit welchen Proggern).

Bei mir ist der Ablauf so: Zum Brennen wird per make-Target ein sh-script gestartet. Das script bekommt die mcu geliefert. Es schreibt ne tmp-datei und startet danach pony.

Makefile:

BURN_SCRIPT = /d/avr/bin/burn-prog.sh

.PHONY: burn

burn: $(PRG).hex
sh $(BURN_SCRIPT) $< $(MCU_TARGET)



burn-prog.sh

#!/bin/sh

burn=e:/temp/burn-tmp.e2s
pony=e:/PonyProg2000/PONYPROG2000.EXE

case $2 in
at90s2313)
target=AT90S2313
;;
atmega8)
target=ATmega8
;;
at90s8515)
target=AT90S8515
;;
*)
echo !!! Unknown Target $2;
exit 1;
;;
esac

portion=PROG

echo Burning $1 for $target
rm -rf $burn

echo "# generated file" > $burn

EEPROM_FILE=`basename $1 .hex`_eeprom.hex

#------ START --------
#Programming sequence
echo "SELECTDEVICE $target" >> $burn
echo "call \"echo Clearing buffer...\"" >> $burn
echo "CLEARBUFFER" >> $burn
echo "call \"echo Loading PROG from $1...\"" >> $burn
echo "LOAD-PROG $1" >> $burn

echo "call \"echo read FUSE...\"" >> $burn
echo "READ-FUSE" >> $burn

# LOAD-DATA eeprom.hex
# echo "PAUSE \"Reinstöpseln, anschalten, und los geht's!\"" >> $burn
# READ-CALIBRATION 0x3ff
echo "call \"echo Erasing $target...\"" >> $burn
echo "ERASE-ALL" >> $burn
# echo "WRITE&VERIFY-ALL" >> $burn
echo "call \"echo Writing PROG to $target...\"" >> $burn
echo "WRITE-PROG" >> $burn

$pony $burn

Dateinamen musst du natürlich anpassen. Die Stellen findest du. In dem Script steht noch etwas Müll rum :oops: den kannst du entsorgen.
Was genau gemacht wird wird dir klarer, wenn du in die erzeugte tmp-Datei reinguckst ($burn)

[Kaiser-F]

Guten Morgen,

Vielen Dnak für die Infos... Damit werd ich bei Zeiten mal rumspielen...

Anscheinend muss man sich halt dann damit abfinden, dass man vorher die FUSES READen muss... aber ist ja auch nicht allzu tragisch...

Das Script ist aber sehr Interessant und klingt praktisch!

[tobimc]

Hi

Also ich muss sagen, dass ich nicht glaube, dass das ein Silicon-Bug ist, da auf dem M8 so ziemlich alles läuft OHNE die Fuses zu verstellen, sowas höre ich jetzt zum ersten mal.
Die meisten Fehler liegen, und das sage ich aus leidvoller Erfahrung meistens zwischen den Kopfhörern.
Es kann sein, dass ein Bug im AVRGCC oder im Pony ist, oder ein Bedienfehler vorliegt.
Ich hatte noch keine Probleme mit selbstständigem "refusing"

Aber jetzt sind wir alle wieder Glücklich, dass es wieder geht.
Schöne Schaltung übrigens ;D
Ist das verzinnt oder versilbert?

VLG Tobi

[Kaiser-F]

Ich denke, dass es an PonyProg liegt. Denn das Programm läuft ja...
Mit anderen Chipshatte ich sowas noch nie...

Die Platine ist Chemisch Verzinnt...

[SprinterSB]

mit der Platine hat das IMHO nix zu tun und auch nicht mit deinem Programm, das ist da unerheblich. Silicon bugs sind Fehler in der Hardware (zB im AVR-Core/Design)

[Kaiser-F]

Oder so... Um das herauszufinden müsste man einfach mal das obige
Programm mit nem anderen Programm auf nen ATmega8 Laden.

[SprinterSB]

Ich hatte es nur mit Pony versucht, den Fehler konnte ich aber nicht wirklich nachvollziehen, es trat nur sporadisch auf. Womöglich auch nur bei krachneuen Controllern? Hauptsache, es gibt nen work around. So nen Fehler dingfest zu machen und mit Sicherheit zu sagen, welche Komponente(n) der Bösewicht ist/sind, ist super aufwändig und weit jenseits meiner Möglichkeiten...

[Wambly]

Meiner ist neu, aber ich konnte noch keine komminikation aufbauen.
Angefangen hab ich mit einem PAR-Prommer mit Buffer, dann PAR-4Widerstandsmethode nach STK200/300 und schlussendlich mir SER(RS232) Version nach PONYPROG Bauanleitung ohne 5V Buffer füe den AtMega (Wird über Regelnetzteil erledigt).

Der /RESET geht beim Auslesen mehrmals nach LO.

SCK schwingt wunderbar mit einigen Aussetzern (warscheinlich /RESET syncron, kann ich jedoch nicht exakt messen)

MOSI erhält auch PULSE.

MISO hüpft nur einige mV herum, auch Pullup 10k half nix.



XTAL1 hat +5V
XTAL2 hat LO und eigentlich alle anderen Anschlüsse.

Hab auch schon enen 4MHz Q +2KerKo(XTAL1-2), bzw einen 555 mit 1MHz Oszilator an XTAL1 angehängt. Bachte nix.
Beim 555 ist das Taktverhältnis ca. 2/3 und nicht gerade Rechteckig, bügelt das der Atmega aus?


Ist mein neuer Atmega8 futsch. Werd bald einen zweiten zulegen, Fehlersuche kann einfacher sein wenn mann evtl 2x den selben Fehler hat. (dann liegs meist wo anders).

Ist nur der Mega8 so "empfindlich" oder alle gleich, sonst wechsle ich gleich auf eine andere Sorte. Sollte 2-3 Steuerungen pasteln.

Hoffe auf Hilfe.

Toni :?

[Kaiser-F]

Hallo Toni,

ich hab Deine Nachricht ganz übersehen.
Wenn es Dir noch hilft:


Versuch mal den XTAL1 Pin mit einem Quarzoszillator zu speisen...
Evtl hat es Dir die Fuses durcheinandergehaun...


Zum Programmer:
Ich habe bisher diese Programmermethode gehabt:
http://www.sir-kaiser.de/upload/atmel-programmer.jpg
Hat mich bisher noch nie in Stich gelassen!
Und der 74HCT244N schützt deinen PC!

Natürlich die Versorgung für dieses IC nicht vergessen! 5V

[Wambly]

@Kaiser-F Vielen dank für die Antwort

Habe meinen alten Progger vernichtet und zwischenzeitlich den Progger von
kreatives-chaos.com (Schaltung fast wie oben von Kaiser-F) gebaut, und gleich die Experimentierplatiene für den Mega8-48-88-168.
Da ich vom Bügeleisen auf einen Lami umgestiegen bin, hatte ich zu langes Timing, und musste noch Brücken entfernen, aber der Mega88 wird von BASCOM sofort erkannt. Zuerst machte der Progger noch Probleme, MOSI ging nur bis zum HC244. Hab dann mit Farbverdünner die Flussmittelreste entfernt und auch den 74hc244 nochmal aus dem Sockel gehoben und neu eingesetzt. Dann lief's.
Ohne Oszilloskop würde ich wohl immer noch suchen, wo der Fehler liegt.
Grüsse aus Tirol
Toni