-
        

Ergebnis 1 bis 7 von 7

Thema: ATmega durch falschen Code kaputt machen

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    09.06.2005
    Beiträge
    108

    ATmega durch falschen Code kaputt machen

    Anzeige

    Hallo

    Ich habe mal eine Frage, die mich schon länger beschäftigt.
    Ist es eigentlich möglich, durch einen falschen Code einen ATmega wegzublaßen?

    Zum Beispiel durch...
    ...falsche Initialisierung (mega32.def statt mega8.def, falsche Quarzfrequenz)
    ...Syntaxfehler im Programm
    ...Falsche Registerangaben (1 gesetzt wo 0 hingehört)
    ...Zu hohe Zyklen (Wait-Befehle im µs-Bereich über lange Zeiten)

    Ich meine damit direkte Codefehler. Also kein "Tod durch sekundäre Folgen" wie den Versuch einen Motor durch einen IO-Pin direkt zu betreiben oder solche Späße Auch von den Fuse- und Lock-Bits soll ausgegangen werden, dass diese korrekt gesetzt sind und nicht verändert werden.

    ...oder kann man den ATmega mit jedem x-beliebigen Code flashen ohne befürchten zu müssen, dass er sich selbst vernichtet?
    Die Frage geht natürlich nicht nur an die Programmiersprache BASIC, aber da es ein "Softwareproblem" ist, dachte ich ists hier am besten.

  2. #2
    Administrator Robotik Einstein Avatar von Frank
    Registriert seit
    30.10.2003
    Beiträge
    4.989
    Blog-Einträge
    1
    Mir fällt nix ein, was den Controller beschädigen würde solange nix angeschlossen ist. Er würde höchstens Abstürzen udn müsste neu programmiert werden.
    Sobald was dran hängt sieht die ganze Sache natürlich anders aus. Dort könnte zum Beispiel ein Port der als Eingang für Taster gedacht ist, zerstört werden, wenn er als Ausgang programmiert wird usw.

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    11.04.2005
    Beiträge
    1.469
    Hi,
    denke nicht, daß das alles irgendwas ausmacht.
    Man kann den Chip ja immer wieder durch einen Chip Erase komplett löschen, inklusive Lockbits, falls die versehentlich gesetzt wurden.
    Und falsch gesetzte Taktfuses kann man ja auch wieder mit einer externen Taktquelle rücksetzen.
    Zitat:
    ..oder kann man den ATmega mit jedem x-beliebigen Code flashen ohne befürchten zu müssen, dass er sich selbst vernichtet?

    Ich glaube nicht, daß der Chip das übelnimmt.

    Man kann sich aber zB. das EEprom zerschießen, wenn man zu oft abspeichert.
    100 000 Schreibzyklen sind schnell erreicht, wenn man in kurzen abständen speichert.

    Wenn du jede Sekunde speicherst, ist das EEprom (theoretisch) nach einem bis zwei Tagen defekt.

    Da muß man also im Code schon etwas aufpassen.

    Elektrisch zerstört habe ich einen Mega auch noch nicht.
    Selbst mit stundenlang kurzgeschlossenen Ausgängen.
    Der wurde nur recht warm

    Gruß
    Christopher

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Oft sieht man in Grundschaltungen eine Beschaltung von V_REF mit VCC. Je nachdem, wie man den internen Multiplexer stellt, schliesst dieser V_REF (also VCC) mit (dem Treiber) der internen Spannungsreferenz kurz. Diese Einstellung dient dazu, die interne Referenz extern zu glätten, indem man einen C anschliesst.

    Ob es duch beschaltung mit VCC und falsche ANsteuerung zu Problemen kommt, weiß ich allerdings nicht.

    Neben der Abnutzung des EEPROM kann sich auch der Flash abnutzen, zB ein µC der nicht richtig läuft, zB dauern resettet/sinnlos rumhüpft und dauern den Flash neu schreibt.
    Disclaimer: none. Sue me.

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.04.2005
    Beiträge
    178
    Dass man mit Dauerflashen den EEPROM oder FLASH zerschiessen kann gehört ins Buch der Legenden. Das Einzige, was nach 10000 Flashs oder 100000 mal EEPROM schreiben anders ist, ist die Tatsache, dass der Speicher ohne Strom die Daten nicht mehr 20 Jahre behält, sondern entsprechend weniger. Zu Fehlfunktionen kann es also erst kommen, wenn der Chip 20 Jahre lang unbenutzt rumliegt.

    felack

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.03.2006
    Ort
    WOB
    Beiträge
    630
    Dazu kann ich heute eine interessante Frage beisteuern:

    Ich habe heute den 2. AT90CAN128 tot bekommen und ich weiß nicht warum. Beide waren ca. 7 Tage alt und ich hatte ca. 50mal geflasht.
    Gerade eben, das ding lief, habe ich eine neue Funktion geschrieben und wollte flashen.... (PonyProg2000 mit Paralleladapter von Robotikhardware). Plötzlich sagt er missing Device (-24) und läuft nicht mehr. Gar nicht mehr... nichtmal meine Status LED blinkt.

    Die Versorgung ist nach wie vor da und OK. Es war mittlerweile der 2. Fall, dass er nach dem Flashen eines Updates die Beine streckt. Hat da jemand ne Idee???
    Gruß Thomas \/

    Alles über AVR, PIC und CAN
    blog.cc-robotics.de

  7. #7
    Neuer Benutzer Öfters hier
    Registriert seit
    06.04.2008
    Beiträge
    18

    PonyProg2000

    Ich hatte auch schon mehrfach Probleme mit PonyProg2000 in Verbindung mit einem "0815" Programmieradapter einfachster Bauweise - seriell wie auch parallel - Mittlerweile hab ich mir ein AVR Dragon angeschafft und 2 weitere höherwertige Programmieradapter und habe seither keine Schwierigkeiten mehr.

    cu
    olby2
    Zitat Zitat von T.J.
    Dazu kann ich heute eine interessante Frage beisteuern:

    Ich habe heute den 2. AT90CAN128 tot bekommen und ich weiß nicht warum. Beide waren ca. 7 Tage alt und ich hatte ca. 50mal geflasht.
    Gerade eben, das ding lief, habe ich eine neue Funktion geschrieben und wollte flashen.... (PonyProg2000 mit Paralleladapter von Robotikhardware). Plötzlich sagt er missing Device (-24) und läuft nicht mehr. Gar nicht mehr... nichtmal meine Status LED blinkt.

    Die Versorgung ist nach wie vor da und OK. Es war mittlerweile der 2. Fall, dass er nach dem Flashen eines Updates die Beine streckt. Hat da jemand ne Idee???

Berechtigungen

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