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?
Nutzt du zufällig Flash Schreib Routinen in der Software? Falls ja, mach mal die BOD an.
BOD ist an und steht auf 4,5V bei 5V Vcc Flashroutinen sind nur im Bootloader drin.
Brown-Out Detektor ist Pflicht. Ebenso eine saubere Abblockung aller Betriebsspannungsanschlüsse. Außerdem Reset mit 4k7 nach Vcc schalten.
>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...
Werden im Main Programm irgendwo interruptfähige Schnittstellen angesteuert, wobei noch keinen allgemeine Interruptfreigabe stattgefunden hat? Das kann unter Umständen das Problem sein.
>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.
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.
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.
>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!
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.