Atmega2561 Flash Speicher geht kaputt

[ich (Gast)]

Ich habe einen 2561 Atmega, der mit 16 Mhz läuft und irgendwie 
empfindlich auf Spannungseinbrüche o.ä. reagiert. Da steckt er auf einer 
Karte und zwei Tage geht alles gut, dann schalte ich was dazu an der 5V 
schiene, wobei alles gefiltert ist und zack, macht er Fehler. Nach dem 
Abziehen der Stromversorgung etc. bleibt er stur beim fehlerhaften 
Verhalten. Bei einer printfausgabe eine const char[] Arrays zum 
Programmstart spuckt er nur Mist aus wobei die eine feste Ausgabe wie 
printf("__________"); wunderbar ausgegeben wird. Programmiere ich den 
Flasch mit dem gleichen Programm neu, ist alles wunderbar. Ich möchte 
nicht auf die Einzelheiten der Schaltung eingehen, erwähnenswert ist, 
dass der Atmega128 in der gleichen Schaltung beim gleichen 
Hardwareaufbau wunderbar funktioniert und diese Probleme waren 
unbekannt. Muss jedoch zugeben, dann in der aktuellen Softwareversion 
per malloc paar Hundert bits reserviert werden.

PS: wenn ich am System fummel, dann erde ich mich auch ordentlich.


Ist euch so ein Verhalten bei den Atmegas bekannt?

[Benedikt K. (benedikt)]

Nutzt du zufällig Flash Schreib Routinen in der Software?
Falls ja, mach mal die BOD an.

[ich (Gast)]

BOD ist an und steht auf 4,5V bei 5V Vcc
Flashroutinen sind nur im Bootloader drin.

[Knut B. (Firma: TravelRec.) (travelrec)]

Brown-Out Detektor ist Pflicht. Ebenso eine saubere Abblockung aller 
Betriebsspannungsanschlüsse. Außerdem Reset mit 4k7 nach Vcc schalten.

[Knut B. (Firma: TravelRec.) (travelrec)]

>BOD ist an und steht auf 4,5V bei 5V Vcc
>Flashroutinen sind nur im Bootloader drin.

Hmm - aus eigener Erfahrung kenne ich den Mega2560 und 2561 als genau so 
stabil wie alle anderen Megas...

[wt (Gast)]

Schaltplan, layout?

[A. F. (artur-f)]

Werden im Main Programm irgendwo interruptfähige Schnittstellen 
angesteuert, wobei noch keinen allgemeine Interruptfreigabe 
stattgefunden hat? Das kann unter Umständen das Problem sein.

[Knut B. (Firma: TravelRec.) (travelrec)]

>Werden im Main Programm irgendwo interruptfähige Schnittstellen
>angesteuert, wobei noch keinen allgemeine Interruptfreigabe
>stattgefunden hat? Das kann unter Umständen das Problem sein.

Bei keiner allgemeinen Interruptfreigabe werden auch keine Interrupts 
ausgelöst. Ein sprung an den falschen Interruptwektor ist auch nicht 
ausreichend, um das Flash zu manipulieren. Um Flashspeicher zu löschen 
oder zu beschreiben, müssen genau abgestimmte Befehle und Timings rund 
um den Assemblerbefehl 'SPM' ausgeführt werden. Dies kann nur 
absichtlich geschehen oder bei einer MCU, die zu wenig Spannung für 
einen sicheren Betrieb hat.

[Benedikt K. (benedikt)]

Travel Rec. wrote:
> Um Flashspeicher zu löschen
> oder zu beschreiben, müssen genau abgestimmte Befehle und Timings rund
> um den Assemblerbefehl 'SPM' ausgeführt werden. Dies kann nur
> absichtlich geschehen

Er hat ja die entsprechenden Routinen in seinem Code. Der Programmteil 
muss nur ausgeführt werden, warum auch immer.

[Knut B. (Firma: TravelRec.) (travelrec)]

Sicher. Vielleicht sollte der Kollege den vom Programm geschossenen 
Flash einfach mal komplett auslesen (ISP), um dem Fehler auf die Spur zu 
kommen. Wenn das Programm beispielsweise ein externes Ereignis nicht 
korrekt abfängt, könnte ja auch ein Sprung in den Bootloader und 
zufällig an die SPM-Routine stattfinden.

[ich (Gast)]

>Werden im Main Programm irgendwo interruptfähige Schnittstellen
>angesteuert, wobei noch keinen allgemeine Interruptfreigabe
>stattgefunden hat? Das kann unter Umständen das Problem sein.

Tatsächlich habe ich mit dem TWI Master nach Slaves gesucht, bevor sei() 
ausgeführt wurde.

Danke vielmals!

[Knut B. (Firma: TravelRec.) (travelrec)]

Also war der Flash gar nicht kaputt? Na sowas...