Discussion in 'Opencharge' started by Space, Apr 11, 2007.

  1. Space

    Space New Member

    Das Phänomen stellt sich wie folgt da:

    Das Programm des Atmel startet garnicht mehr oder aber verhält sich sehr merkwürdig und springt teilweise wirr :huep: umher.

    Als mögliche Ursachen habe ich 3 Möglichkeiten ausgemacht:

    1. Atmega zu häufig programmiert.
      Häufig macht sich dies bemerkbar wenn der Lader lange nicht genutzt wurde und einige Tage gelegen hat.
      Das Flash wird meiner Meinung nach eher "weich", als es Atmel mit ~100 Programmierzyklen angibt. Meiner Erfahrung nach wird es nach 65-75 Programmierungen kritisch. ​
    2. Überspannung durch Funkenbildung beim Anstöpseln des Akku's oder des Laders an die Autobatterie
      Im Gegensatz zu dem MAX110, welcher auf Funkenbildung mit GameOver :dontknow: reagiert ( das kostet mit der Zeit richtig Geld..), ist der Atmel gegen Überspannungsblitze nicht wirklich geschützt.

      Am 12V Eingang habe ich parallel zu dem Anschlusskabel ein bipolare Surpressordiode mit 22V gelötet. Am Akkuausgang ist das gleiche Modell aber mit 68V Durchbruchsspannung parallel zu den Buchsen eingelötet. (Reichelt: 1,5KE 22 bzw. 68 CA)
    3. Bootloader
      Langsam traue ich dem nicht mehr. Entweder rennt er falsch los und überschreibt schon mal die erste Flashpage oder aber das Timing für das Programmieren der Flashzellen ist zu kurz, so daß diese nicht sauber programmiert werden (geht das?).
      Ich werde demnächst mal mit dem Megaload experimentieren.
      Allerdings nicht als klassischer Bootloader sondern aus dem eigentlichen Programm her ausgerufen. Die nervige Wartezeit beim Boooten entfällt so...​
    Im Moment habe ich die Massnahmen 2 (Surpressordioden) und 3 (kein Bootloader) aktiv. Der Prozessor hat etwa 20 Programmierzyklen hinter sich. Seit 2-3 Wochen und intensiver Nutzung, bisher ohne Probleme...:)
  2. Frogger

    Frogger New Member

    Zack bumm,
    mein zweiter Protz funzt wieder fehlerfrei seit ich den Bootloader entfernt hab. Da muss irgendwas nicht ok sein. Mit überspannungen beim anklemmen des Laders oder akkus hab ich zum Glück noch keine erfahrungen machen müssen. Jedenfalls lebt der MAX110 noch :)
    Ich trau dem Bootloader auch nicht mehr. Leider ist das neu flashen dadurch etwas schwierig da man ja erstmal den Deckel öffnen muss. Das mit dem Megaload in das Programm einbauen finde ich interressant. Ich hab davon noch nicht gehört obwohl ich mich da mal stundenlang eingelesen hab. Prinzipiell ist es ja auch ok wenn der Rechner auf flashen wartet und man beim Lader in das Menue "Flashen" geht.
  3. Ralf P.

    Ralf P. New Member

    Welche Dimensionierung der Surpressordioden schlägst du für 32V Eingangs und max. 60V Ausgangsspannung vor ?

    Gruß Ralf
  4. Space

    Space New Member

    ..der 1,5KE 36CA Typ sollt passen, wenn deine Eingansspannung nicht deutlich über 32V hüpft (Leerlauf ?)
  5. Frogger

    Frogger New Member

    Da ich ja eine Saule Fau bin hab ich die Teile die Thomas mir geschickt hat noch nicht eingabaut. Naja um ehrlich zu sein beschränkt sich meine Freizeit im Moment auf das nötigste und das ist sonntags fliegen. Naja wie dem auch sei ... ich hab also die dioden noch nicht verbaut.
    Mein Mega (der hatte ja nu schon ein paar male sein Flash verloren) funzt wieder problemlos! Der flashfehler beruht also mit an sicherheit grenzender Wahrscheinlichkeit am alten Bootloader.

    PS.: Ich liebe dieses Ladegerät! :)
  6. Holger

    Holger LogView Team

    Hallo,

    Mit Megaload habe ich bisher nur gute Erfahrungen gemacht.
    Ich benutze die Version 3.0b7, da die noch ohne .Net-Framework auskommt. Die späteren Versionen haben dann auch eine Registrierung erfordert, die wohl aber seit V5.0b1 nicht mehr erforderlich ist.

    Bei virtuellen ComPorts muss man aufpassen, dass man die bei aktiver Megaload-Oberfläche nicht ständig an- und abstöpselt, da sich MegaLoad sonst aufhängen kann und den Rechner dabei lahmlegt.

    Megaload kann man sich in main.c relativ leicht passend einstellen und mit dem ICCAVR-Compiler neu übersetzen, so daß keine wirkliche Wartezeit notwendig ist. Vor allem das Setzen einer festen Baudrate ist da sehr zeitsparend. :)

    Dann ist es so: Ist die Megaload-Oberfläche aktiv, der Controller angeschlossen und es kommt ein Reset, dann wird innerhalb weniger Zehntelsekunden (nicht wirklich wahrnehmbar) die Verbindung aufgebaut und der Flashvorgang läuft schon.

    Code:
    in main.c
    ...
    // To setup the bootloader for your project you must
    // remove the comment below to fit with your hardware
    // recompile it using ICCAVR setup for bootloader
    // of 512 word for ONLY flash programming
    // or 1024 word for flash and eeprom programming
    //
    //*****************************************************************************
    // MCU selection
    // -->Do the same thing in assembly.s<-- 
    //*****************************************************************************
    //#define MEGATYPE 8
    //#define MEGATYPE 16 
    //#define MEGATYPE 32 
    //#define MEGATYPE 64 
    #define MEGATYPE 128
    //#define MEGATYPE 162
    //#define MEGATYPE 169
    //#define MEGATYPE 8515
    //#define MEGATYPE 8535
    //#define MEGATYPE  2313
    //*****************************************************************************
    // Bootload on UART x
    //*****************************************************************************
    //#define UART       0
    #define UART       1
    //*****************************************************************************
    // BaudRate
    // If you don't specify the baudrate divisor the bootloader
    // will automaticaly be in AutoBaudRate mode
    //*****************************************************************************
    #define BAUDRATE     12
    //*****************************************************************************
    // Crystal speed
    // frequancy of your MCU speed
    // LOW  -> Xtal < 8Mhz
    // HIGH -> Xtal >= 8Mhz
    //*****************************************************************************
    //#define LOW
    #define HIGH
    ...
    ICCAVR-Compiler: Als Demoversion volle 45 Tage lauffähig, danach auf 4k Codegröße begrenzt (bei nichtkommerzieller Nutzung). Ich habe schon viel mit diesem Compiler gearbeitet (Version 6.31A als Kaufversion) und bin sehr zufrieden damit.
    Etwas im Sourcecode ändern, F9 drücken und der Rest passiert von allein (alles einstellbar), bis schließlich das neue Programm im Controller seine Arbeit tut. :)
  7. Space

    Space New Member

    Busted

    @Frosch

    Sehe ich genauso, das Thema ist :[​IMG]

    Ich habe die Schottkys drinne und gleichzeitig den Bootloader gewechselt. Deine Erfahrung scheint nun nur den Bootloader als Übelwurzel zu idetifizieren. Lass mal die Schottkys weiterhin draussen und teste mal
    weiter. Vielleicht kann ich ja die Hardwareänderung wieder zurücknehmen.

    Aussserdem:
    Ich gebe dir den Rat, dein liebliches Verhältnis zu dem Ladegerät nochmals zu überprüfen und ggf. Selbshilfeeinrichtungen aufzusuchen :D

    @Holger

    Derzeit setze ich schon Megaload in der neusten Version 6.3 (.NET) ein. Das Ergebis deckt sich mit deinen Erfahrungen, problemlos. Der Megaload wird derzeit allerdings aus dem Hauptprogramm heraus angesprungen. Wenn ich das nun richtig verstehe, ist alleinige die Geschwindigkeitserkennung für die laaaaaange Verzögerung verantwortlich, so das man den Megaload auch als wirklichen Bootloader betreiben kann.:grin:

    ....guter Tip, ich werde ihn gleich mal mit einem Fixwert kompilieren. Ich bin wech...
  8. Holger

    Holger LogView Team

    Hallo Space,

    viel Erfolg! Bin gespannt, bitte berichten!

    Gruß, Holger
  9. Space

    Space New Member

    Bericht:

    Megaload .NET fix auf 38400 @8MHz kompiliert im Anhang. Funzt wie verrückt, keien Wartezeit beim Booten. :)

    Attached Files:

Share This Page