- Labornetzteil AliExpress         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 19

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

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    38
    Beiträge
    795

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

    Anzeige

    LiFePo4 Akku selber bauen - Video
    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:
    Code:
    //  -=> 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

    Bild hier  
    Gruß,
    Franz

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.802
    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.
    Disclaimer: none. Sue me.

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    38
    Beiträge
    795
    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....
    Gruß,
    Franz

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.06.2004
    Ort
    Bad Schussenried in Oberschwaben
    Alter
    34
    Beiträge
    1.461
    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
    http://www.tobias-schlegel.de
    "An AVR can solve (almost) every problem" - ts

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    30.07.2005
    Beiträge
    569

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

    Zitat Zitat von Kaiser-F
    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 ??

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.06.2004
    Ort
    Bad Schussenried in Oberschwaben
    Alter
    34
    Beiträge
    1.461
    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 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...

    VLG Tobi
    http://www.tobias-schlegel.de
    "An AVR can solve (almost) every problem" - ts

  7. #7
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    38
    Beiträge
    795
    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.
    Gruß,
    Franz

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.802
    -- 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.
    Disclaimer: none. Sue me.

  9. #9
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    38
    Beiträge
    795
    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?
    Gruß,
    Franz

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.802
    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:
    Code:
    BURN_SCRIPT    = /d/avr/bin/burn-prog.sh
    
    .PHONY: burn
    
    burn: $(PRG).hex
    	sh $(BURN_SCRIPT) $< $(MCU_TARGET)

    burn-prog.sh
    Code:
    #!/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 den kannst du entsorgen.
    Was genau gemacht wird wird dir klarer, wenn du in die erzeugte tmp-Datei reinguckst ($burn)
    Disclaimer: none. Sue me.

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests