Bootloader stoppt Mikrocontroller

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

    • bitlogger wrote:

      Ich hatte nach so einer Platine gefragt
      Welche genau?
      Die Platine der Geräte ist seit einigen Jahren im einsatzt und funktioniert auch normal.

      bitlogger wrote:

      Habe dein Programm mangels 2561 mit einem 128 untersuchen wollen. Geht nicht, weil Programm zu groß, angeblich nicht rein passt
      Für Bootloader siehe Post #6!

      Der neue Programmer ist auch nicht unzverlässig bei den ATMega128 und ATMega164 funktioniert alles wie es soll.
      Was den Bootloader betrifft hab ich glaube ich schon einige male gesagt wenn ihr den Grundcode haben wollt BASCOM -> HILFE -> SUCHEN "loader" -> nach unten scrollen bis ATMega version kommt -> Strg C und Strg V
      Die Änderungen die von meinem Vorgänger gemacht worden sind habe ich in Post #18 angegeben (wobei der Code an sich ein Copy/Paste der BASCOM Hilfe ist).
      Ich habe, weil das Problem den neuen Programmer betrifft den Code zusammengekürzt und in einem neuen File gespeichert, sodass ich leichet mit dem File arbeiten kann und den bestehenden Bootloader nicht überschreibe und das Original schütze (wie jeder vernünftige Programmierer behalte ich mir ein Backup vom Original damit es nicht überschrieben wird)

      Pluto25 wrote:

      PPS Warum steht an 3F800 etwas? Hatte er keine Lust mehr den Rest zu löschen
      Weil wenn ich Angebe das er Bootloader bei 1FC00 anfängt, was eine Word Adresse ist und als Byte Adresse umgewandelt ist dies 3F800, dieser nicht leer sein darf. Bedeutet das der Bootlader den ersten BYTE bei 3F800 schreibt (WORD 1FC00), also wenn der Bootloader richtig hochgeladen wurde sollte der Flash bis 3F800 leer (FF) sein und der Byte 3F800 muss der erste nicht leere Byte sein weil das die Startadresse des Bootloaders ist. :D

      Pluto25 wrote:

      PS Wenn der Watchdog in den Fuses eingeschaltet wird kann er nicht beim Absturz versagen.
      Also wenn ich den Watchdog per code configuriere und enable, ist er schlechter beim Erkennen von crashes und der gleichen, als wenn ich ihn per Fuse aktiviere? ?(


      Ich hab nochmal nachgemessen einfach um noch einmal zu bestätigen das ich keinen Fehler gemacht hab.

      Neue/Alte Erkenntnisse
      Der alte Programmer scheint den besseren 5V stabilisator zu haben (der Alte schafft es den Prozessor zu starten sodass die LEDs schalten, der Neue schafft das nicht)

      ATMEGA128, FLASH:131072, EPROM:4096
      ATMega2561, FLASH:262144, EPROM:4096
      Sind die Daten die mir der Programmer ausgibt wenn ich den MC (128 und 256) identifizieren lasse.

      Das .bin File an sich sollte ~700 Word groß sein, was der Grund ist warum der 1024 Word Bootlaoder verwendet wird und nicht der 512 Word. Wenn ich wollte, würde ich ihn wahrscheinlich auch noch auf weniger als 512 Word zusammengekürzt bekommen.

      Hab nochmal mit dem alten Programmer den Bootloader hochgeladen und mit dem neuen Verifiziert.
      Der neue Programmer sagt mir nun das der Flash bei Adresse Byte 1F800 (Word FC00) unterschiedlich ist, und wenn ich den Flash auslese ist der Bootloader nun an 1F800 B (0FC00 W) statt an 3F800 B (1FC00 W) ?( ?(
      Bootloader Startet und lässt mich eine Datei hochladen.

      The post was edited 1 time, last by Prepe ().

    • bitlogger wrote:

      Nun, was könnte in dem Bootlader ... solcherlei Meldung auslösen?
      Das er ganz simpel nicht mehr antwortet, weil er zB durch die Locks nicht schreiben darf oder er in die falsche Adresse springt. ( Oder das der Chiptakt so gering ist das der Programmer ungeduldig wird :D wie lang ist das Timeout wohl? )

      Prepe wrote:

      ist er schlechter


      nun an 1F800 B
      unzuverlässiger, da er im Code eingeschaltet werden muß und nicht vorhanden, wenn der Code erst gar nicht dazu kommt/ihn abschaltet.

      Was steht denn in der bin? Ein Programmer sollte nicht seine eigene Interpretation schreiben =O

      In der bin von Post#1 beginnt er bei 3F800. Das würde heißen das Bascom und der alte Programmer beide den selben Fehler machen. (max Word Adresse FFFF)
      Wie war das mit der höheren Adressbank? Rampz=1 ? Das könnte helfen?

      The post was edited 4 times, last by Pluto25 ().

    • Versorgst du etwa das Gerät beim Programmieren vom Programmer aus mit Spannung?

      So wie ich dich verstehe, waren ja unterschiedliche Bytes beim Verifizieren festzustellen, wenn du den neuen Programmer nimmst.
      Offensichtlich klappt da die Komunikation nicht richtig.

      Versorge mal dein Zielgerät, welches du programmieren willst, mit einer eigenen Spannungsversorgung.
    • Mitch64 wrote:

      Versorge mal dein Zielgerät, welches du programmieren willst, mit einer eigenen Spannungsversorgung
      Das mit der externen Spannungsversorgung hab ich schon versucht hab extra ein 10Pol kabel bei dem ich die VCC Leitung getrennt hab vorbereitet damit ich keinen Kurzschluss reise.

      Pluto25 wrote:

      Wie war das mit der höheren Adressbank? Rampz=1 ? Das könnte helfen?
      Dabei müsstest du mir helfen ich weiß gerade nicht was du meinst oder wo ich das einstelle.
    • Pluto25 wrote:

      Das würde heißen das Bascom und der alte Programmer beide den selben Fehler machen.
      Könnte es sein, dass der neue Programmer die speicherbereiche 00000-0FFFF und 10000-FFFFF vertauscht?
      Würde jedoch nicht erklären warum er ohne Probleme ATMega128 und ATMega164 programmieren kann.

      Hab jetzt auch in die andere Richtung geprüft, der alte Programmer gibt mir an das der neue Programmer den Bootloader auf 0FC00 W geladen hat, also welcher von den beiden Lügt und warum? Ich vermute der neue Programmer macht was nicht richtig, da der Bootloader, wenn ich ihn mit dem alten Pogrammer hochlade, funktioniert.
      Sachen mit den alten Programmer zu machen ist halt SEHR Zeitaufwändig da er für das Hochladen des Bootloaders 15 min braucht :sleeping: und auslesen oder Flash prüfen bauchen auch ewig. Manchmal gibt läuft er auch in einen Fehler und dann muss ich hochladen/auslesen/prüfen neu starten und verschwende noch mehr Zeit (einer der Gründe warum der Alte ersetzt werden soll)
    • Warum ist es soooo ein Geheimnis, um welchen alten und neueren Programmer es da geht? Scheint eine Sonderanfertigung zu sein, oder etwas selbst gebasteltes.
      Gibt es nichts zuverlässigeres wie z.B einen Atmel AVRISP MKII oder ähnliches? Mein Programmer ist in Sekunden fertig, incl. Verification.
      Wieso übrigens FFFFF? Der Atmega mit dem größten Flash packt grade mal 256 KB, was ist das in Hex?
      Ein Programmer ist meist nur ein simpler Mikrocontroller, -Programm, das eine entsprechende Schnittstelle (z.B ISP) bedient. USBASP benutzt evtl Mega8 oder Mega 163 etc.
      Ein Programmer übersetzt quasi eine Hex- oder Binärdatei in einen Programmcode. Adressen sind somit Vorgaben der Hex-, Binärdatei.

      Ohje, was ist das denn für ein Programmer, der 15 Minuten braucht, und zum verifizieren ähnlich? Mit sowas wollt Ihr arbeiten?
    • Für Programmer siehe Post #6! The secret lies in the past :D
      Alt und Neu sind leicheter und kürzer zu schreiben :P

      bitlogger wrote:

      Wieso übrigens FFFFF? Der Atmega mit dem größten Flash packt grade mal 256 KB, was ist das in Hex?
      Ups meinte natürlich 1FFFF a_45_132ca9f5 ist aber trotzdem mehr als 256 KB

      Wenn ich den ATMega2561 mit meinem Programmer Verifiziere bekomme ich folgede Meldung
      ATMega2561, FLASH:262144, EPROM:4096

      Die 256KB beziehen sich auf den runtime programmable Flash (oder irgedwie so wird der genannt)
      Der Bootloaderbereich von "4096" Word ist dort noch nicht hineingerechnet, sollte aber einleuchtend sein wenn im Datenblatt steht, dass der Bootloader an Adresse &H1FC00 verschoben werden soll, wenn man einen 1024 Word Bootloader reserviert.

      Ich lass mich gerne Korigieren, aber so fasse ich die Daten aus dem Datenblatt auf.
      Display Spoiler

      1FC00 -> 130 480 Words -> 260 560 Bytes (3F800) => 260 560 > 256 000 => Bootloaderbereich liegt auserhalb des angegebenen Flash :!:
      262 144 - 256 000 = 6 144 Byte -> 3 072 Word => nur wenn man den großen 4096 Word Bootloaderbereich wählt "verliert" man Flash :?:

      The post was edited 1 time, last by Prepe ().

    • Prepe wrote:

      Der Bootloaderbereich von 4096 Word ist dort noch nicht hineingerechnet
      Doch , der geht davon ab.1FC00 ist ja das 254te kB heißt 254 und 255 dürfen nicht als normaler Programmflasch genutzt werden sonst würde das den Bootlader schreddern.
      Lass die Programmer doch eine Bin von dem gelesenen erstellen da sieht man recht gut wer welche "Meinung" hat.
      Ich habe bin's vom Code aus #1 erstellt. Baskom macht einen Unterschied ob der Loader an 0FC00 oder 1FC00 sein soll in 3 Bit (das sind wohl die Sprungadressen) . Die Pos in der bin ist jeweils korrekt. Leider fehlt mir ein Disassembler um genau zu sagen was es tut. Ein Rampz=1 am Anfang ändert auch nur die Adressen (und fügt sich selber natürlich ein) Keine Ahnung ob das Sinn macht, vielleicht wirkt das nur beim Ram? Aber irgendwie muß der Chip ja alles über FFFF auch adressieren können. Vermutlich ohne 3Byte Adressen zu nutzen?

      Prepe wrote:

      trotzdem mehr als 256 KB ...FLASH:262144,
      Opfer der Festplatten"betrüger" geworden? 262144 Byte sind exact 256kB
    • Prepe wrote:

      Der alte Programmer scheint den besseren 5V stabilisator zu haben (der Alte schafft es den Prozessor zu starten sodass die LEDs schalten, der Neue schafft das nicht)
      Diese Programmer haben intern einen CP2102 Chip. Und dieser hat laut Datenblatt einen internen Voltageregulator, der die 5 V USB Busspannung intern auf 3,3 V schaltet!
      Somit haben die Uart-Ausgänge keinen 5 V Pegel, sondern nur 3,3 V. Zwar interpretieren etliche Atmega CPU's einen 3,3 V Pegel als High-Level.
      Fraglich bleibt, wie der Hersteller des Programmers die Umschaltung (laut Beschreibung) von 3,3 auf 5 V, oder umgekehrt löst, oder ob das sinngemäß Bluff ist.
      Wird das zu programmierende Device vom Programmer mit Spannung versorgt, oder hat das Bord mit dem zu brennendem Prozessor seine eigene Betriebsspannung?
      Mal untersucht, wie sich beide Teile verhalten, wenn Bord eine Betriebsspannung von 5 V hat? Im Datenblatt vom CP2102 steht als max Uart-Portspannung 5,8 V. Käme so betrachtet mit externen Spannungen von 5 V noch klar. Nur, wer garantiert, oder denkt an die max. Belastungsgrenze vom CP2102, d.h. wer kontrolliert ob die Bordspannung maximal 5,8 V garantiert?

      Ich hatte mal Probleme mit einem USB Wandler mit einem integrierten FTI Chip. Schaute deswegen bei EEVBlog nach solcherlei. Link: eevblog.com/forum/chat/ft232rl-ch340g-cp2102-which-to-chose/ (Video ansehen)
      Rampz ist ein Register das beim Mega128 nur Bit0 besitzt, beim 2560/2561 sind 2 Bits vorhanden. Wird im Zusammenhang mit dem Z-Pointer für die Adressierung SPM/ELPM verwendet.
      Disassembler habe ich. SPM (Adressierung) Programming via Z-Pointer und RAMPZ ist auf Seite 314 Datenblatt des 2561 beschrieben.
      Ergänzung: silabs.com/documents/public/data-sheets/CP2102-9.pdf

      The post was edited 1 time, last by bitlogger ().

    • bitlogger wrote:

      5 V Pegel, sondern nur 3,3 V.


      für die Adressierung SPM/ELPM verwendet
      Die reichen für gewöhnlich völlig. Ein Stromversorgung/Datentransportfehler ist eher unwarscheinlich da er immer gleich ist.

      Wer sind SPM/ELPM? Ram EEprom?


      bitlogger wrote:

      Disassembler habe ich.
      Toll, könntes Du das übersetzen?
      8FEF8DBFC8EDE0EA4E2E81E28EBFD1E2F1E25F2EA89584B7082E877F84BF88E199278093600090936000EEEFFFE1A0E0B2E088278D933197E9F789E18093C40080E08093C50088E18093C100662400E41DE023E030E0A0E0B2E00D931D932D933C9386E08093C200F89485E0809306025C9A81E090E00F9472FC179A0F9443FC
      oder den Unterschied zu
      8FEF8DBFC8EDE0EA4E2E81E28EBFD1E2F1E25F2EA89584B7082E877F84BF88E199278093600090936000EEEFFFE1A0E0B2E088278D933197E9F789E18093C40080E08093C50088E18093C100662400E41DE023E030E0A0E0B2E00D931D932D933C9386E08093C200F89485E0809306025C9A81E090E00E9472FC179A0E9443FC
      nennen?
      (Die Anweisung , die bits sehe ich auch :D jedoch "Bahnhof" ?( )

      The post was edited 1 time, last by Pluto25 ().

    • Pluto25 wrote:

      Opfer der Festplatten"betrüger" geworden?
      Ne mein Hirn hat gestern einfach vergessen das 1KB = 1024 Byte sind und nicht 1000 Byte. Die vergessenen 24 byte erklären natürlich den zusätzlichen Flash den ich glaubte zu haben a_45_132ca9f5 a_71_f9c57bbe

      Erstelle jetzt erst mal 4 bin Files und vergleiche die, also 1 für jede Kobination. Mal sehen ob ich unterschiede finde. Ledier hab ich auch keinen disassembler, aber Notebad mit combare sollte mir zumindes mal grundlegende unterschiede zeigen.

      bitlogger wrote:

      Diese Programmer haben intern einen CP2102 Chip. Und dieser hat laut Datenblatt einen internen Voltageregulator, der die 5 V USB Busspannung intern auf 3,3 V schaltet!
      Also ich hab mit Multimeter drübergemessen und der alte Programmer hat 5,050V und der neue ist abhänging davon wie der USB angeschlossen ist (verlängerung oder direkt am PC) und wie der USB Stecker in der Buchse sitzt (etwas wackelraum) zwischen 4,305 und 4,989V

      The post was edited 1 time, last by Prepe ().

    • So nebenbei, wenn ich einen MC hab der mir als ID 000000 zurückliefert ist er kapputt oder? Kann man da im nachhinein nochmal was versuchen um ihn zu retten oder ist vollkommen ende? Falls ich ein neues Thema dafür aufmachen soll gebt bescheid.
    • Zitat Pluto25:
      5 V Pegel, sondern nur 3,3 V.
      für die Adressierung SPM/ELPM verwendet

      Die reichen für gewöhnlich völlig. Ein Stromversorgung/Datentransportfehler ist eher unwarscheinlich da er immer gleich ist.

      Das ist einzig deine Interpretation! Wo schrieb ich denn, dass die Stromversorung des Programmers was mit SPM/ELPM zu tun hat?

      Prepe hat angemerkt, er hat zwei fast gleiche Programmer. Einer davon macht mehr Probleme. Darauf habe ich mir den Programmer genauer angesehen.
      Laut Doku vom Hersteller kann der zwischen 3.3 und 5 V umschalten. Hat intern einen CP2102, der von sich aus nur 3.3 V Pegel liefern kann.
      Da die Pegel bei der Übertragung der Programierimpulse (Protokoles) evtl eine Rolle spielen könnten, habe ich gedanklich darauf hingewiesen.
      Der Abstand eines high- zu low- Pegels ist bei 3,3 V Versorgung wesentlich geringer als bei 5 V. Dürfte naheliegend sein.
      Es werden sinngemäß Impulse (Pegelwechsel) übertragen, und wenn die Versorgungsspannung nicht frei von Jittern usw ist, taugt der Programmer evtl nichts.
      Ich nehme deshalb lieber teuere, dafür zuverlässigere Programmer. Zuverlässig sollte sowas sein!

      @Prepe Interessant, ein Programmer hat constant 5 V, der andere wackelt in gewissem Bereich, und Du verwendest den trotzdem?
      Erstelle die 4 Files, biete mir die jeweiligen .obj Dateien an. Die kann ich disassemblieren und als Textdatei zurück geben.
    • Prepe wrote:

      So nebenbei, wenn ich einen MC hab der mir als ID 000000 zurückliefert ist er kapputt oder? Kann man da im nachhinein nochmal was versuchen um ihn zu retten oder ist vollkommen ende? Falls ich ein neues Thema dafür aufmachen soll gebt bescheid.
      Hmmm, kaputt muss so ein MC nicht sein. Das "befragen" seiner ID ist ähnlich wie ein Programmierbefehl. Der MC bekommt über seine Schnittstelle eine Anweisung, liefere die ID.
      Wenn die sinngemäße Übertragung (per Programmer) nicht voll okay ist, kann ein einwandfreies nicht garantiert werden, das gelieferte ist Okay.
      Der Programmer muss zuverlässig sein, wird auch hier deutlich.
    • Also ich hab nochmal nachgefragt was die Programmer betrifft und hab endlich mal genauere Angaben bekommen.
      Der neue Programmer ist: mySmartUSB light
      Der alte Programmer ist: USB-ISP Prog 1 Embud (angeblich direkt von BASCOM vertrieben)

      Bei beiden Programmern wurde nachträglich ein 5V Stabilisator eingebaut, wodurch die Gehäuse der Programmer geändert wurden. X/ (Deshalb habe ich keine genaueren Angaben machen können)
      An sich soll der Alte halt abgelöst werden, weil er sehr langsam ist und anscheinend Probleme mit den ATMega128 und ATMega164 macht. Der Neue kann ohne Probleme ATMega128 und ATMega164 programmieren, hat aber probleme mit ATMega2561.
      Die Stabilisatoren wurden eingebaut, weil der Designer der Paltinen die 5V Leitungen der gesamten Platine zusammengehängt hat, bedeutet das alle Komponenten die mit 5V versorgt werden hochfahren sobald Strom auf die VCC Leitung gegeben wird. a_45_132ca9f5 Ergo wenn mehr als ein MC auf der Platine ist versuchen all zu starten, wenn ich 1 Programmieren will und das erzeugt peaks die ohne den zusätzlichen stabilisatoren halt zum absturz der MC geführt hat. Plus natürlich das andere Komponenten ebenfalls hochfahren wollten. a_45_132ca9f5 a_45_132ca9f5

      bitlogger wrote:

      Interessant, ein Programmer hat constant 5 V, der andere wackelt in gewissem Bereich, und Du verwendest den trotzdem?
      Ich verwende was mit zur verfügung gestellt wird. Eigentlich programmiere ich keine MC, aber ich hab halt die Arbeit übernommen, weil ich der einzige Programmierer in der Firma bin und es sonst keiner anständig machen kann. Also bin ich noch dabei mich in die gesamte Materie einzuarbeiten. Ich vetraue zurzeit einfach darauf das die Werkzeuge die mir zur Verfügung gestellt werden funktionieren.
      Außerdem das mit den Schwankungen hast du falsch verstanden! Die Versorgung ist Stabil, aber halt abhänging davon wie der USB angesteckt ist, kann er halt stabil irgendwo zwischen 4,3 und 4,9 sein, solange niemand am kabel rumspielt wenn er programmiert, schankt er um weniger als 0,002V wärend des Messens.


      bitlogger wrote:

      Hmmm, kaputt muss so ein MC nicht sein.
      Also kann man die wieder herstellen? Wenn ja wie? Brauch ich dafür spezielle tools? ATMega2561 sind zurzeit recht teuer und wäre schön wenn ich die retten kann wenn möglich.


      bitlogger wrote:

      Erstelle die 4 Files, biete mir die jeweiligen .obj Dateien an.
      Wie mach ich aus den .bin Files .obj Files? Ich kann den gelesenen Flash nur als .bin speichern, außerdem muss ich mich noch etwas gedulden ein Kolege Programmiert die nächsten geräte und wir haben nur noch den 1 Funktionierendnen alten Programmer so, dass ich warten muss das der wieder frei ist. a_67_e210de67 Kann auch noch bis morgen dauern das ich den Programmer wiederbekomme. X(
    • bitlogger wrote:

      die Stromversorung des Programmers was mit SPM/ELPM zu tun hat?
      Gar nicht, wie auch? Aber im Zusammenhang mit Rampz. Daher die Frage was SPM und Elpm ist.

      Prepe wrote:

      der mir als ID 000000 zurückliefert
      das sagt nur das er nicht antwortet. Hier z.B. wenn er keine Stromversorgung hat, der Reset an Vcc gelötet ist, der Stecker nicht richtig sitzt oder Win mal wieder einen "besseren" (falschen) Treiber nutzt.
      Einige Fuse Bits können ihn auch zum schweigen bringen SPIEN=1 oder Clock=extern.
      Die bin Files reichen völlig Unterschiede zu erkennen , die kann auch der neue Erstellen.
    • Pluto25 wrote:

      das sagt nur das er nicht antwortet.
      naja aber er sollte antworten! Weil er erst nachdem man versucht hat ihn zu programmieren (alt oder neu) nach dem Programmieren aufgehört hat zu antworten. ?( Also wird wohl etwas bei den Fuse Bits nicht stimmen. Kann ich die einfach mit einen "Erase Chip" resetten, weil ich die Lock and Fuse bits nicht öffnen kann, da der Chip nicht antwortet.
    • @Pluto25
      Die $prog die im Bootloader ist/war, da wenn ein MC mal abraucht, dann direkt nachdem der Bootloader hochgeladen wurde.
      Wie kann ich herausfinden ob der Quarz noch schwingt?

      Hab die .bin Files fertig. Sind im Anhang. Hab sie auch mal vorläufig verglichen und hätte keine Unterschiede entdekt, außer dass der Bootloader an der Falschen stelle steht, wenn die Programmer den Flash der vom jeweils anderen programmiert wurde. Denke dass uns das hier auch nicht weiterbringen wird.
      Files