-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: ATMega2561 - Zerstörung

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183

    ATMega2561 - Zerstörung

    Anzeige

    Hallo Roboternetz.

    Ich bin gerade ziemlich fertig und ratlos, was mein Problem betrifft.

    Ich habe hier einen ATMega2561 auf einen Board. Dieser wurde von mir bereits mehrfach geflasht und hat bisher auch funktioniert. Zudem befinden sich auf dem Board noch ein Funkmodul von Pollin (RFM02) ein MAX232-Pegelwandler und einige Kleinteile.

    Nun ist der aktuell verbaute Controller nicht mehr über ISP ansprechbar. Ich habe sonst keinerlei Möglichkeit, den Controller zu prüfen. Der Einzige Anhaltspukt, den ich habe ist:

    Ich hatte vorher schonmal einen anderen Controller auf dem Board verbaut, der ebenfalls funktionierte. Ich flashte ein Programm drauf, das den SPI-Bus initialisierte und anschließend das Funkmodul dazu veranlassen sollte, die Taktfrequenz an seinem CLK-Pin (die ich als Takt für den Prozessor verwende) von 1Mhz auf 10Mhz umzuschalten. Ob mein Programm geht, weiß ich bis heute nicht. Fakt ist, dass dieser Prozessor daraufhin nicht mehr anprechbar war. Also habe ich ihn mühevoll ausgebaut und einen Neuen draufgelötet. Dann noch als "Funktionsindikator" das An- und Ausschalten einer LED in das Programm eingefügt und wieder geflasht. Seitdem ist auch dieser Prozessor nicht mehr nutzbar.
    Desweiteren fiel mir noch etwas auf. Der Prozessor ist auf der Unterseite des Boards verlötet. Unmittelbar nachdem der neue Prozessor eingesetzt war, flashte ich ein LED-Blink Programm drauf, um zu testen, ob alles geht. Ging auch. Das war gestern Abend. Heute schalte ich das Board an und bilde mir ein, einen Lichtblitz _durch_ die Platine gesehen zu haben, und zwar genau dort, wo der Prozessor drunter ist. Schon voller Angst, es könnte etwas zerstört sein, öffne ich PonyProg und lese die Daten des uC's. PonyProg machte mir keinen Fehler. Ich flashe mein "Problemprogramm" und seitdem geht nichts mehr.
    Ich weiß nicht mehr genau, ob der erste uC auch einen solchen Blitz erlebt hat, vermute es aber. Ob er unmittelbar nach dem Blitz noch zu flashen war, wie es ja beim 2. Prozessor der Fall war, weiß ich nicht mehr. Von unten sieht er ganz normal aus. Es wurde auch bei beiden uC's nichts heiß oder hat geraucht oder gestunken.

    Was mir Kopfzerbrechen bereitet:

    - Was war das für ein Lichtblitz?
    --- Hat er etwas zerstört und hat PonyProg einmal fälschlicherweise ausgelesen und auch noch geflasht ;
    --- oder habe ich mir den nur eingebildet und PonyProg hat wirklich geflasht und ausgelesen (Das bedeutet, mein Programm und nicht der Blitz hat den uC zerstört)?

    - Woher könnte der Lichtblitz (wenn es ihn denn gab) gekommen sein?

    - Was kann man in einem Programm falsch machen, was den Prozessor zerstören könnte? (Programm angehängt)

    Im Anhang ist das Layout und der Schaltplan, hier noch das besagte Problemporgramm:

    Code:
    #include <AVRlib\avrlibtypes.h>
    #include <inttypes.h>
    #include <avr\io.h>
    
    void Keyboard_ReceiveMessage(unsigned char c);
    char dispbuffer [5];
    
    #define UART_RX_BUFFER_SIZE		0x0000
    #define UART_TX_BUFFER_SIZE		128
    
    #include <stdlib.h>
    #include <avr\interrupt.h>
    #include <util\delay.h>
    #include <adc.c>
    #include <SPI.c>
    #include <lcd.c>
    #include <Funk.c>
    #include <midi_messages.h>
    
    #include <All.c>
    #include <PitchBend.c>
    #include <Distance.c>
    #include <Keyboard.c>
    #include <neck.c>
    
    int main(void) {
    	
    	DDRF |= (1<<PF3);
    	PORTF |= (1<<PF3);
    	
    	SPI_Init();
    	
    	for (unsigned char i=0; i<15; i++)
    		_delay_ms(10);			// wait until POR done
    	
    	Funk_Init();
    	PORTF &= ~(1<<PF3);
    	
    	
    	while (1) {
    		_delay_ms(500);
    		PORTF |= (1<<PF3);
    		Funk_SetCrystalFreq(0);
    		_delay_ms(500);
    		PORTF &= ~(1<<PF3);
    		Funk_SetCrystalFreq(8);
    	}
    }
    Sowie de SPI.c
    Code:
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    // SPI ////////////////////////////////////////////////////////////////////////////////////////////////
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    
    
    #define SPI_PORT PORTB
    #define SPI_DDR  DDRB
    #define SPI_PIN  PINB
    
    #define SPI_MISO PB3
    #define SPI_MOSI PB2
    #define SPI_SCK  PB1
    
    //char SPI_Ready;
    
    
    void SPI_Init(void);
    void SPI_WriteByte(char b);
    char SPI_TransmitByte(char b);
    
    
    
    
    void SPI_Init(void){
    	
    	// Define MOSI and SCK as output
    	SPI_DDR |= (1<<SPI_MOSI) | (1<<SPI_SCK);
    	// Configure as Master
    	SPCR |= (1<<MSTR);
    	// Set ClockRate to fck/16
    	SPCR |= (1<<SPR0);
    	// Send MSB first
    	SPCR |= (1<<CPOL);
    
    	// Finally Enable SPI
    	SPCR = (1<<SPE);	
    	
    	//SPI_Ready = TRUE;
    }
    
    void SPI_WriteByte(char b) {
    	
    	SPDR = b;
    	
    	// wait for the transmission to be complete
    	while(!(SPSR & (1<<SPIF)));
    }
    Und die Funk.c
    Code:
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    // Defines ////////////////////////////////////////////////////////////////////////////////////////////
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    
    //#define FC_Crystal 
    #define SS_PORT PORTD
    #define SS_DDR  DDRD
    #define SS_PIN  PD5
    
    #define FUNK_SELECT SS_PORT &= ~(1<<SS_PIN);
    #define FUNK_DISSELECT SS_PORT |= (1<<SS_PIN);
    
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    // Variables //////////////////////////////////////////////////////////////////////////////////////////
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    
    char Funk_Config[2]; 						// Containing now used parameters for the Configuration Setting Command
    
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    // Functions //////////////////////////////////////////////////////////////////////////////////////////
    ///////////////////////////////////////////////////////////////////////////////////////////////////////
    
    void Funk_Putc(char c){
    	SPI_WriteByte(c);
    }
    
    
    void Funk_Init(void){
    	
    	// Configure the slave select line as output
    	SS_DDR |= (1<<SS_PIN);
    	// Set the slave select line to low, to signalize the transmitter, that data will be send now
    	FUNK_SELECT;
    	
    	// 433Mhz frequency band, 10Mhz crystal output
    	Funk_Config[0] = 0b10001000;
    	// 
    	Funk_Config[1] = 0b00110000;
    	
    	// Send the Configuration Setting Command
    	Funk_Putc(Funk_Config[0]);
    	Funk_Putc(Funk_Config[1]);
    	
    	// Set the SS-line to high-state, to signalize, that all data was sent
    	FUNK_DISSELECT;
    }
    
    
    void Funk_SetCrystalFreq(char Freq) {
    
    	FUNK_SELECT;
    	
    	if (Freq > 8) 
    		Freq = 8;
    		
    	Funk_Config[0] |= Freq;
    	
    	Funk_Putc(Funk_Config[0]);
    	Funk_Putc(Funk_Config[1]);
    	
    	FUNK_DISSELECT;
    }
    Meine bitte ist nun, jede Idee, die euch einfällt zu posten. Ich habe keine Ahnung, was die beide uC's zerstört haben könnte, zumal die möglichen Ursachen sehr eigenartig sind. (Flashen nach dem Blitz... usw.)

    Vielen Dank für jede Hilfe,
    Bääääär
    Angehängte Dateien Angehängte Dateien

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.08.2006
    Ort
    Budapest
    Alter
    30
    Beiträge
    563
    Naja, wenns immer mit dem SPI Programm zusammenhängt, wäre es eine Erklärung, dass beim Init ein Kurzschluss entstanden ist, zum flashen werden nämlich auch die Pins benutzt, wie für den HW-SPI. Wenn Dein Programm also sofort zu kommunizieren beginnt, wenn sie noch am ISP hängt, kanns vielleicht zu einer Datenkollision kommen.

    Ein Lichtblitz kann bei einer solchen Schaltung (5V) nur entstehen, wenn irgendein dünner Leiter durch einen Kurzschluss zerstört wird.

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.11.2003
    Beiträge
    1.111
    Ich habe mal so etwas ähnliches erlebt. Ich habe es darauf geschoben, dass ich neben dem Programmieradapter (AVRISP MKII) noch etwas anderes an den SPIPorts angeschlossen habe. Obwohl es nichts war, was man nicht an einen µC hängen sollte (Ich glaube es waren LEDs mit Vorsiderstand gegen Vcc), hat es in Verbindung mit dem Programmer den µC zerstört. Das konnte ich aber abklemmen und danach ging es. Hat mich 3 µCs gekostet und trat nur sporadisch auf (etwa alle 10mal flashen), aber mir konnte auch niemand sagen, warum es jetzt passiert ist.
    Am Code kann es eigentlich nicht liegen. Du könntest höchstens mal versuchen, die Startup Time in den Fusebits zu erhöhen um dem Programmer mehr Zeit zu geben, "abzuschalten". Vielleicht konfigurierst Du Deine SPI Ports sehr früh im Programm als Ausgänge mit Wert 0. Wenn der Programmer dann noch Strom liefert, könnte es DIr die Ports zerschießen. Das war meine Vermutung damals. Ist aber nur ein Schuß ins Blaue.
    Würde die Lösung auch gerne wissen.
    Gruß

  4. #4
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183
    Das Ding ist, dass der Programmer nicht an den SPI-Pins angeschlossen wird (das dachte ich auch erst, worauf ich verzweifelt nach Fehlern gesucht habe, bis mich das Datenblatt aufklärte). MOSI wird an den Pin mit der Bezeichnung PDI und MISO an PDO angeschlossen (oder andersherum, siehe Schaltplan).

    Das kann es also nicht sein. In meinen Programm schalte ich MOSI und SCK als Ausgang und sende dann Daten. Also kann nur einer dieser Pins einen Kurzschluss haben. Bisher hängt am SPI nur das Funkmodul.

    Das Problem ist, dass jeder ATMega2561 11€ kostet und mein Geld bei diesem Projekt den Nullpunkt erreicht hat. Zumal sich schon beim Wechseln des Prozessors einige Leiterbahnen zu lösen begannen. Noch einenWechsel wird das Board nicht verkraften.

    //Edit: Achso. Der Programmer besteht bei mir aus einem Parallelportstecker mit zwei Widerständen dran. Alle Versuche, mit Treiber misslangen, also habe ich es so belassen.

    //Edit2: Äh Moment mal. Der SCK-Pin könnte es sein. Aber kann der wirklich einen Kurzen verursachen, der den ganze uC zerhaut?

  5. #5
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Die ISP Dougles nur mit 2 Widerständen sind nicht besonders zuverlässig. Gerade wenn die CLK Leitung probleme (überschwinger) macht, können die Fuses verstellt werden. Dann werden nähmlich einige daten doppelt gezählt, und das Ende eines Programms kann so ziehmlich alles verstellen was per ISP geht.
    Das Typische Problem ist dann, das ein externer Takt erwartet wird, der nicht da ist. Ohne Takt geht dann ISP auch nicht. Den externen Takt kann man notfalls provisorisch bereitstellen und es noch mal versuchen.

    Ich würde empfehlen erst mal einen zuverlässigen ISP Programmierer zu besorgen oder zu bauen. Die einfache 2 Widerstandslösung ist auch eine gewisse Gefahr für den PC.

    Auch poyprog gilt nicht als besonders zuverlässig. AVRDude versucht wenigstens die Fuses noch mal zu lesen und notfalls zu korrigieren.

  6. #6
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183
    Das Ding ist, dass ich, wie schon gesagt mit dem Geld sehr knapp bin im Moment (naja, eigentlich dauerhaft). Ich war erstmal froh, dass es überhaupt ging. Dann habe ich aus von Besserwessi genannten Gründen einen Standart-Prommer mit dem 74HC244 oder so ähnlich aufgebaut. Ging nicht. nach dem dritten habe ich es dann aufgegeben. Kaufen... ja, klar, aber da wäre wieder das mit dem Geld...

    Aber zurück zum eigentlichn Problem: An den Fuses kann es eigentlich auch nicht liegen. Der Externe Takt ist von Funkmodul ja da (mit Oszi überprüft), also sollte es zumindest möglich sein, den uC zu flashen. ISP kann man ja in den Fuses auch deaktivieren. Das kann aber auch nicht sein, dann würde nämlich das Programm laufen, was es ja nicht tut.

    Tja, also erstmal neuen Prozessor kaufen und Programm erst auf Tastendruck starten, damit man den ISP-Stecker von Board trennen kann?

    Vielen Dank schonmal für alle Hilfe,
    Bääääär

  7. #7
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Ich habe erst jetzt den Schaltplan und das layout gesehen. Da ist ja nur ein Entkopplekondensator drauf, und auch der scheint nicht gerade dicht am IC zu sein. Eventuell kann man noch ein paar als SMD ( Größe 0603 oder 0805) nachbestücken. Es könnte sein das die Versorgung einfach zu schlecht ist für den vollen Takt.

    Schon die Reset Leitung zum ISP Stecker ist recht lang, da sollte man eventuell mal einen kleinen Kondesator nach GND vorsehen, damit man sich nicht Störungen einfängt.

  8. #8
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    13.05.2007
    Alter
    26
    Beiträge
    183
    Thema Reset-Leitung:

    Da ist ja ein Pull up dran. Eigentlich sollten doch Störungen gar nicht so direkt möglich sein. Ich hatte eher Angst, dass die CLK-Leitung auf die paar cm verunreinigungen an den danebenliegenden Datenleitungen verursachen könnte oder auch umgedreht. Und da ist ein Kondensator etwa 0,5cm vom uC weg. Ist das schon zu weit?

    Ganz abgesehen davon ist (war) der uC noch gar nicht auf externen Takt eigestellt.

    Trotzdem danke für die Tipps, mir war z.B. nicht bewusst, dass PonyProg da Probleme machen kann. Als Autodidakt hat man's da nicht so leicht, hab das ja nicht mal annähernd irgendwo gelernt. Ich werd' mal schauen, wie ich das mit der ISP-Leitung auch gleich im Layout unterbringe.

    Bääääär

    Edit:// Wenn ich das richtig verstanden habe, kann die Zerstörung nach bisherigem Stand nur durch einen Kurzschluss an der SCK Leitung entstanden sein. Und zwar in dem Moment, wo ich mit dem Programm SCK als Ausgang setze. Aber wenn ich das richtig verstanden habe, verwenden die AVR's interne PullUps/PullDowns um die Leitung auf das jeweilige Potential zu ziehen. Wenn es einen Kurzschluss gegeben hat, dann muss dieser Widerstand weggefackelt sein. Der uC ist aber eigentlich nicht warm geworden. Also er war nur so handwarm, nicht so, als wären da irgendwelche zerstörerischen Ströme drübergeflossen. Ich weiß ja nicht, wie die interne Struktur eines ATMega2561 aussieht, aber ich kann mir nicht vorstellen, dass dieser zerstörte Widerstand gleich den ganzen uC außer Gefecht setzt. Wie gesagt, es ist nichts warm geworden. Ich glaube, hier brauche ich dann doch die Hilfe eines Profis, denn das kann ich einfach nicht beurteilen.

  9. #9
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Durch einen Kurzschluß sollte der Controller nicht so schnell kaputt gehen, vor allem weil ja der Programmierer wohl da einen Schutzwiderstand haben sollte. In diesem Fall reicht es den SCK Pin zu zerstören, dann geht ISP nicht mehr, ist aber eher unwahrscheinlich.
    Ich würde auf unabsichtlich verstellte Fusebits tippen.

    Der mögliche Lichtblitz kommt mir komisch vor, das könnte am ehesten von einer LED kommen. Von Wideständen würde ich keine Licht erwarten. das kenne ich höchstens von Dioden im Glasgehäuse, wenn die wirklich viel Strom (>1 A) abbekommen. Es konnte eventuell eine Elktrostatischen Entladung gewesen sein, wobei eine derart starke Entladung dann auch den Controller zuerstören kann.

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    25.11.2003
    Beiträge
    1.111
    Die AVR Eingänge haben nur PullUps, um 5V zu liefern. Einen Port zerschießt man sich auf die bereits beschriebene Weise (Konfig als Ausgang und Wert 0, wenn eine Quelle mit viel Strom dranhängt, denn dann versucht der "kleine" FET innen drin den ganzen Strom kurz zu schließen) oder indem man zu hohe bzw. zu negative Spannungen anlegt. In letzterem Fall gehen die Schutzdioden hinüber, weil die auch nur Spannungsspitzen verkraften. In keinem der Fälle wird der µC wirklich heiß, weil er einen kurzen Strompuls von einigen hundert mA nur sehr kurz verkraftet. Danach kannst Du also nicht gehen.
    Ich würde immernoch versuchen, den µC erst zu starten, wenn das Programmierkabel ab ist. Beim LPT weiß man nie, was der macht...
    Gruß

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

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