ATMega2561 - Zerstörung

[Bääääär]

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:


#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

///////////////////////////////////////////////////////////////////////////////////////////////////////
// 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

///////////////////////////////////////////////////////////////////////////////////////////////////////
// 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

[pongi]

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.

[Gock]

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ß

[Bääääär]

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?

[Besserwessi]

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.

[Bääääär]

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

[Besserwessi]

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.

[Bääääär]

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.

[Besserwessi]

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.

[Gock]

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ß

[Bääääär]

@Besserwessi: LED's sind ja auf der Platine keine drauf. Elektrostatische Entladung... Möglich, aber in dem Ausmaße? Das kann ich mir nicht so richtig vorstellen.

Nungut. Ich versuche erstmal, einen neuen Controller zu bekommen, den baue ich dann auf das Board auf (wenn es ein erneutes Auslöten verkraftet) und starte mein Programm erst dann, wenn ich den ISP-Stecker gezogen habe. Wenn es nochmal einen Blitz geben sollte oder sonst irgendwas auffälliges passiert, dann melde ich micht natürlich sofort.

Desweiteren versuche ich mal, irgendwoher einen fertigen Programmer zu bekommen. Dann kann ich die Sache mit den verstellten Fuses auch gleich ausschießen.

Vielen Dank erstmal für alle Hilfe, wenn jemandem noch Vorschläge einfallen - immer her damit! =)

Bääääär

[avion23]

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.
Das kann ich bestätigen. Ich war das erste mal ziemlich "überrascht".