Bootloader stoppt Mikrocontroller

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Prepe wrote:

      Post #18 ist die Version, welche wir jetzt weitherhin verwenden
      Die bin von Post #18 unterscheidet sich in drei Byte von dem der bins: 3F862 $76 zu $74, 3F864 $75 zu $76 und 3F866 $74 zu $75 . Vermutlich Clear Port?.? Die Pinbelegung mal geändert?
      Der Booloader erwachtet den Wert 123 (ein Byte geschweifte Klammer auf) gefolgt von einem Byte 0 Bin 0000 0000 (läßt sich im Simulator nicht eingeben - kann Waitkey 0 verstehen/ausgeben? Er bleibt stehen ( Endlosschleife ) wenn keine 0 kommt. Ist das der "Fehler" der auffiehl. ? Womit wurde getestet? Mit welchem Tool arbeiten die Kunden?
    • Die Funktionlität des Bootloaders und der Bootloadersoftware ist sichergestellt, die tuen was sie soll. Wenn der Bootloader richtig hochgeladen ist gibt es kein Probleme auch nicht mit der Schnittstelle zum Bootloaderprogramm, welches das .bin File hochläd.
    • Womit wird er betrieben? Er könnte mit Einzel-Befehlen ein paar Byte irgendwo im oberen Bereich schreiben. Dann sieht man ob sein Tool oder er selbst (seine Firmware) den Fehler macht. Ein anderes Tool und/oder Firmware versucht?

      Ps wie lange dauert das brennen? Da keine 1600 Byte geschrieben werden sollte das in 2 Sec erledigt sein?
    • Tut mir leid für das ich erst heute wieder Antworte, hatte viel zu tun die letzte Woche.

      @Pluto25 Also du meinst sowas wie einen Bootloader für den Bootloader? Nur das der neue Bootloader bei Adresse 00000 programiert wird? Ich hatte zumindest schon mit der Idee gespielt so ein Datei zu erstellen, es aber dann nicht gemacht, weil ich dachte es würde auch nicht funktionieren. Also der neue Programmer braucht zwar nicht lange, aber deutlich länger als 2 sekunden. Beim alten Programmer sitze ich dan schon mal 2-4 minuten bis er mit hochladen fertig ist.
    • Das würde ja auch nur funktionieren wenn der "richtige" Bootloader an der richtigen Adresse ist. Dein Problem liegt vermutlich in der Software die dem Programmer sagt wo was zu brennen ist. Bzw ein Mißverständnis der beiden über die höheren Pages (Rampz). Daher die Frage nach dem Womit?
      Wenn der neue so lange braucht - wie viele Bytes schreibt der denn? Die ganzen 256 K ?
      Dann ist es vielleicht wirklich schneller ein Progrämmchen zu schreiben das dann den Bootloader brennt Obwohl das dann drei Schritte werden. ca 2k für den "Urloder" 1,6k für den Bootloader und zum Schluß die Fuses. Die kann er nicht selbst ändern.
      Kann er selber denn den Bootloderbereich beschreiben? Da ist mir das Datenblatt etwas unklar?
      Ich hatte nie den Wunsch nur oben was zu schreiben. Kann man z.B. Drude nicht sagen "schreibe nur ab FC00 die 1,6K" ?

      2-4 min ist doch ideal für Kaffepause :D Ich bastle gerade mit nem Nextion das braucht ca 20 min ;(
    • So wie ich es verstanden hab ist der obere Flash paralell schreibbar und der untere Flash würde nur das Programm unterbrechen solange er Flash schreibt.
      Demnach würde ich sagen, dass die Anweisungen !LDS, !STS und !SPM async sind solange es der Zugriff auf den oberen Flashbereich ist, weshalb auch die Bitwait Anwseisungen am Anfang der Do_spm routine sind.
      Demnach würde die asyncronität verlore gehen, wenn auf den unteren Flashbereich zugegriffen wird (wo auch normalerweise der Bootloader ist). Da sich die Bootloader ja selber überschreiben können, wenn die Fuse Bits nicht richtig gesetzt sind und das File zu groß für den restlichen Flashbereich ist, ergibt es Sinn, dass das schreiben auf den Bootloaderbereich nicht asyncron gemacht werden kann.

      Da ein Kolege von mir zuständig ist das die richtigen Dateien auf die MC geladen werden (Bootloader und Firmware), will ich ihm nicht zutrauen dass er bei jedem MC die Fuses nach dem Upload des Bootloades richtig setzt. Schade das der MC die Fuses nicht selbst setzten kann nachdem der Bootloader fertig mit hochladen ist.

      Ich hab aber noch gute Nachrichten, hab mich durchgesetzt und bekomme neue Programmer, welche auch wirklich mit Bascom funktionieren und für die Anwendung ausgelegt sind. Habe halt das Gefühl, dass der mySmartUSB light nicht für ATMega2561 ausgelegt ist.
    • Wenn Du einen neuen Programmer auswählen, ordern, bestellen darfst, empfehle ich Dir den hier verlinkten. ;)
      Den gibt es auch ohne Gehäuse, einiges preiswerter. (Muss man speziell suchen.)
      Fixier Dich mal nicht unbedingt auf "muss per Bascom" bedient werden können. Das sollte nur für diverse Kunden gelten, nicht für dich als Programmierer.
      Für Dich sollte zählen, so ein Gerät sollte die größest- und bestmögliche "Unterstützung beim Programm-Entwickeln und Debuggen bieten!
      Das bietet dieses vorgeschlagene Teil im Zusammenhang mit den Atmel- Studioversionen.
      Du kannst damit in das Innenleben der CPU incl. Speicher schauen, Disassemblieren lassen usw. Was mit so einem Gerät möglich ist, möglich wird, sollte man einmal erlebt haben.
      Jemand wie Du braucht sowas beruflich, also verlange sowas, setz dich durch.

      Okay, das einarbeiten etc ist keine Sache von Minuten, erschließt sich fast von selbst. Und wenn erst mal gewisse Erfolge, Erlebnisse damit gemacht wurden, möchte man auf sowas nie mehr verzichten.
      Link: digikey.com/en/product-highlig…l-ice-programmer-debugger

      Noch was, dieser Programmer/Debugger kann einige Programmierschnittstellen bedienen. Wenn möglich, sollte JTAG benutzt werden, das bietet spezifischere Debugmöglichkeiten.
      Jtag kann euer Atmega 2561 und etliche andere. (Wie gesagt, ich antworte hier speziell für Dich als Programierer in euerer Firma, versuche dir speziell die besten Tipps und Arbeitsmöglichkeiten anzubieten.) Gedacht ist solcher Programmer nicht für euere Kunden, nur speziell für Dich, deinen Job.
    • Prepe wrote:

      welche auch wirklich mit Bascom funktionieren
      Soweit ich weiß unterstützt Bascom nicht das Schreiben ab irgendwann sondern schreibt immer? von 0000 bis zur bin-Länge. Für Euch wäre es schneller eine Software zu haben die nur den Bootloder und die Fuses schreibt und nicht 126 k Leerdaten.
      Für Deinen Kollegen wäre auch ein Script/batch nützlich um nicht jedesmal die Fuses zu Fuß setzen zu müssen. Das macht nur in der Testphase/ Einzelstück Sinn.
      Oder gleich einen z.B. Mega 8 der alleine den 2561 brennt ohne PC. Dann ist das Anstecken das was die meißte Zeit braucht :D