Hallo Foraner, konkret geht es um dieses Bastelprojekt: https://www.fichtelbahn.de/prod_dcctrain4.html Für den ATTiny44 wäre ein Bootloader vorgesehen, der mit "AVRbootloader" seriell gesendet wird. Kann man die Firmware auch ohne Bootloader brennen? Bei mir läuft der Dekoder ohne BL nicht. Fuses sind, mit AVRdude: efuse:w:0xFF:m -U hfuse:w:0x5D:m -U lfuse:w:0xE2:m Danke und Gruss Chregu
Christian M. schrieb: > Hallo Foraner, > konkret geht es um dieses Bastelprojekt: > https://www.fichtelbahn.de/prod_dcctrain4.html > Für den ATTiny44 wäre ein Bootloader vorgesehen, der mit "AVRbootloader" > seriell gesendet wird. > Kann man die Firmware auch ohne Bootloader brennen? Bei mir läuft der > Dekoder ohne BL nicht. Fuses sind, mit AVRdude: efuse:w:0xFF:m -U > hfuse:w:0x5D:m -U lfuse:w:0xE2:m > Danke und Gruss Chregu Deine Frage ist mir unverständlich. Möchtest du ohne den AVRootloader auskommen? Klar geht das, du benötigst dann einen Programmer für den Attiny um die Firmware drauf zu programmieren. So einem Programmer kann man kaufen oder auch selber bauen. Vielleicht erklärst du dein Anliegen noch einmal etwas genauer. LG, Sebastian
Ja genau, ohne den BL. Als Programmer habe ich den Arduino as ISP. Der funktioniert einwandfrei! Gruss Chregu
Bootloader in fuses deaktivieren. Programm brennen. Fertig.
Christian M. schrieb: > Ja genau, ohne den BL. Als Programmer habe ich den Arduino as ISP. > Der funktioniert einwandfrei! > Gruss Chregu Aber was genau ist jetzt dein Anliegen? LG, Sebastian
Hallo, den ATtiny44 kann man klassisch über sck, mosi, miso programmieren, wie oben bereits genannt. Falls das Programm für Bootlader geschrieben ist, kann es sein, daß der Programmstart an einer falschen Adresse liegt und umgeschrieben werden müßte für Betrieb ohne Bootlader. Die Details habe ich nicht parat. Mfg
Christian S. schrieb: > Programmstart an einer falschen Adresse Das Hauptprogramm liegt bei AVR immer an Adresse 0.
MaWin schrieb: > Bootloader in fuses deaktivieren. Da der ATtiny44 keine solchen Fuses hat, vermute ich eben stark, dass da softwaremässig in der Firmware was gemacht wurde. Darum frage ich, vielleicht kennt sich grad jemand mit diesem AVR im Zusammenhang mit AVRbootloader aus und weiss es. Andererseits wollte ich zuerst mal die kompliziertere Methode mit BL umgehen, damit nicht noch mehr Fehlerquellen vorhanden sind. Gruss Chregu
Frag doch die Leute selbst. Im Gegensatz zur Behauptung auf der Webseite enthält das Downloadpaket keinen Sourcecode der eigentlichen Applikation, daher kann man nicht einfach mal nachschauen, was sie da treiben.
Auch wegen dem "fehlenden" Source sah ich keinen Grund, einen Bootloader zu installieren. Wollte eine weitere Fehlerquelle ausschliessen. Habe heute morgen schnell exakt nach Anleitung mit BL probiert, der BL läuft aber auch nicht auf Anhieb. Jetzt muss ich betonieren, vielleicht komme ich heute Abend wieder dazu... Gruss Chregu
Christian M. schrieb: > Wollte eine weitere Fehlerquelle ausschliessen. Fehlerquellen schließt man übrigens nicht dadurch aus, indem man vom Hersteller/Programmierer vorgegebenen Weg abweicht. Damit fügt man nur Fehlerquellen hinzu.
Christian M. schrieb: > Da der ATtiny44 keine solchen Fuses hat Doch, hat er natürlich. Das entsprechende Fusebit heißt SELFPROGEN. Die Wirkung im Vergleich zu den Megas kann man etwa so beschreiben: Ist das Fusebit programmiert, ist der gesamte vorhandene Flash Bootloader-Bereich. Im Unterschied zu den Megas gibt es allerdings keine zwei Vektortabellen und dementsprechend auch keine zwei Einsprünge zu init. Der Bootloader eines Tiny muss also die Vektoren der einzigen existierenden Vektortabelle nach (oder bei) jedem Flashen einer Anwendung "verbiegen", zumindest einen davon, nämlich den Reset-Vektor. > vermute ich eben stark, dass da > softwaremässig in der Firmware was gemacht wurde. Das wäre möglich. Würde aber bedeuten, dass diese Firmware absolut grenzdebile Scheisse ist. Vernünftige Software sollte laufen, egal auf welchem Weg sie in den Flash gelangt ist. Und andersrum: vernünftige Bootloader sollten dafür sorgen, dass die Firmware ihre Existenz garnicht bemerkt, höchstens dann, wenn sie gezielt danach sucht. > Darum frage ich, vielleicht kennt sich grad jemand mit diesem AVR im > Zusammenhang mit AVRbootloader aus und weiss es. Nun, schon ohne jede Einsicht in den Code der Firmware ist zumindest eins schonmal klar: sie ist ABSOLUTE SCHEISSE!
c-hater schrieb: > Vernünftige Software sollte Mal Hand aufs Herz: Wenn du auf der Arbeit fremder Software begegnest, die ernsthaft zum Geld-Verdienen Entwickelt wurde, jubelst du dann meistens vor Begeisterung oder musst du dich zusammen reißen, nicht wie Bierkutscher zu fluchen? ... Na also. Geht doch jedem so. Verdammte Scheiße. Das ist der ganz normale Wahnsinn.
c-hater schrieb: > Vernünftige Software sollte laufen, egal auf welchem Weg sie in den > Flash gelangt ist. Dann hast du wohl noch nie über den AVR-Tellerrand geguckt. Außerdem widersprichst du dir einigermaßen selbst: wenn man den Bootloader bei diesen AVRs nur damit erreichen kann, dass man die Interruptvektoren verbiegt, dann ergibt sich daraus wohl oder übel, dass die Firmware (die ja die Vektoren enthält) eben gerade nicht mehr unabhängig vom Bootloader sein kann.
Jörg W. schrieb: > Dann hast du wohl noch nie über den AVR-Tellerrand geguckt. Da liegst du aber völlig falsch. > Außerdem widersprichst du dir einigermaßen selbst: wenn man den > Bootloader bei diesen AVRs nur damit erreichen kann, dass man die > Interruptvektoren verbiegt, dann ergibt sich daraus wohl oder übel, dass > die Firmware (die ja die Vektoren enthält) eben gerade nicht mehr > unabhängig vom Bootloader sein kann. Du hast scheinbar das Prinzip nicht kapiert. Die Firmware enthält (idealerweise) ihren ganz normalen Resetvektor und wäre somit ganz normal lauffähig, ohne jeden Bootloader. Wenn sie aber über einen Bootloader geladen wird, macht dieser Bootloader etwas und nicht die Firmware! Er sichert den Resetvektor der Firmware und ersetzt ihn durch seinen eigenen. Das geschieht direkt beim Flashen ganz nebenbei. Damit wird nach einem Reset zunächst wieder der Bootloader angesprungen. Der entscheidet dann, ob er "aktiv" werden soll oder nicht. Wenn nicht, springt er über den gemerkten Resetvektor der Firmware die Firmware an. Wenn er laufen soll, dann halt erst nach dem Flashen der neuen Firmware über den neu gemerkten Resetvektor dieser Firmware. Die Firmware weiss nicht, ob sie über Bootloader oder "direkt" gestartet wurde und braucht es auch nicht zu wissen. Sie kann es aber natürlich herausbekommen. Sie könnte z.B. prüfen, ob ihr Resetvektor auf die erwartete Stelle im eigenen Code zeigt. Wenn der Bootloader Interrupts verwenden will, wird es nur unwesentlich komplizierter, es bleibt aber dabei, dass die Firmware NICHTS damit zu schaffen hat und NICHTS davon wissen muss. Das gilt hier sogar noch mehr als beim Resetvektor, denn zur Laufzeit der Firmware enthalten die Interruptvektoren den ganz normalen Inhalt der Firmware. Ausgetauscht werden sie nur, wenn der Bootloader entscheidet, dass er "aktiv" werden muss.
Jörg W. schrieb: > dann ergibt sich daraus wohl oder übel, dass die Firmware (die ja die > Vektoren enthält) eben gerade nicht mehr unabhängig vom Bootloader sein > kann. Das Erzeugen der Firmware schon, die Hex-Datei bleibt gleich, mit oder ohne Bootloader. Insofern wundert mich das Problem des TO. c-hater, kannst du die Hex-Datei lesen? Ich hab mal reasm bemüht, verstehe aber so wenig von Assembler, dass ich noch nicht einmal die Struktur erkennen kann. LG, Sebastian
Christian M. schrieb: > heute morgen schnell exakt nach Anleitung mit BL probiert Schnell und exakt schliessen sich nach meinen Erfahrungen gegenseitig aus. wendelsberg
Arduino Fanboy D. schrieb: > Leicht verwirrt heute? ??? Was ich beschrieb, ist, wie ein Bootloader und Firmware idealerweise interagieren sollten, nämlich so gut wie garnicht mit der einzigen Ausnahme, dass halt der Bootloader irgendwann auch mal die geladene Firmware starten muss. Mich wundert, dass du das nicht verstehst, denn das ist doch gerade das Arduino-Konzept... Dass das im konkreten Fall wohl offensichtlich nicht so ist, ist eine vollkommen andere Sache...
Sebastian schrieb: > c-hater, kannst du die Hex-Datei lesen? Naja, ich hatte sowieso Langeweile, deswegen habe ich mal reingeschaut. > Ich hab mal reasm bemüht, > verstehe aber so wenig von Assembler, dass ich noch nicht einmal die > Struktur erkennen kann. Die Struktur ist ganz simpel: Es gibt keine, nichtmal der Resetvektor wird initial benutzt (nach dem Flashen einer Firmware natürlich schon). Direkt nach dem Flaschen des Bootloaders passiert folgendes: es werden erstmal 0x700 Worte mit dem Opcode 0xffff durchlaufen. Das sind effektiv NOPs. Ab Adresse 0x700 beginnt dann der eigentliche Bootloader. Wenn du das Teil mit reasm analysiert hast, dann suche einfach nach "L0700:", da beginnt der eigentliche Bootloader.
c-hater schrieb: > Wenn du das Teil mit reasm analysiert hast, dann suche einfach nach > "L0700:", da beginnt der eigentliche Bootloader. Oh, da hab ich mich unklar ausgedrückt. Für diesen AVBootloader gibt es ja den Sourcecode. Mir ging es um die DCC-Firmware, die bei dem TO ja ohne den Bootloader anscheinend nicht spielt. Die ist in dem rar-Archiv als DCC_Decoder.hex drin ... LG, Sebastian
Sebastian schrieb: > Mir ging es um die DCC-Firmware, die bei dem TO ja > ohne den Bootloader anscheinend nicht spielt. Und was hast du an der Struktur nicht verstanden? Ist doch eine ganz normale AVR8-Struktur. Init begint ab "L0607:" und es werden drei Interruptvektoren benutzt, deren ISRs beginnen bei "L00D1:", "L0011:" und "L00B1:". Wenn man sich Init und die ISRs anschaut, dann ist das in der Quelle wohl Assemblercode, der typische unsägliche C-Overhead fehlt nämlich überall.
c-hater schrieb: > Wenn man sich Init und die ISRs anschaut, dann ist das in der Quelle > wohl Assemblercode, der typische unsägliche C-Overhead fehlt nämlich > überall. Damit dürfte sich vermutlich als Ursache für das beobachtete Phänomen herausstellen, dass der Firmwarecode sich darauf verläßt, dass der Bootloader die MCU-Register auf eine bestimmte Art "vorinitialisiert". Sprich: vermutlich ein Bug der Klasse "use of an unitialized variable" (hier: MCU-Register). Da der Bootloader so schön minimalistisch ist und freundlicherweise überhaupt keinen SRAM benutzt, kann es eigentlich nur so sein. Eventuell käme auch noch in Frage, dass die Firmware auf die Initialisierung irgendwelcher Peripherie durch den Bootlader verläßt. Das halte ich aber für relativ unwahrscheinlich.
c-hater schrieb: > Eventuell käme auch noch in Frage, dass die Firmware auf die > Initialisierung irgendwelcher Peripherie durch den Bootlader verläßt. > Das halte ich aber für relativ unwahrscheinlich. Wobei... Wenn man sich anschaut, das der Bootloader so ziemlich als erstes einen wdt macht, könnte es doch schon wahrscheinlicher werden. Normalerweise macht das nämlich an dieser Stelle keinen Sinn, genausowenig wie das cli direkt davor. Das ergibt nur dann einen Sinn, wenn man damit rechnet, dass die Anwendung "die Kontrolle verliert" und der PC unkontrolliert bis zum Bootloadercode läuft.
c-hater schrieb: > Wenn man sich anschaut, das der Bootloader so ziemlich als erstes einen > wdt macht, könnte es doch schon wahrscheinlicher werden. Vielleicht soll das aber hauptsächlich sowas wie ein Kopierschutz sein, der verhindern soll, dass jemand mit der Software herumspielt. Bin mir nicht sicher, wie die kommerziellen DCC-Bauer so drauf sind. Man könnte doch einfach mal bei Hersteller des Decoders nachfragen, ob die Firmware auch ohne Bootloader läuft. Wenn man also mal nur per ISP programmiert. Habe aber auch noch nicht verstanden, warum das unbedingt ohne Bootloader gemacht werden soll?! Gruß Rainer
Rainer V. schrieb: > Habe aber auch noch nicht verstanden, warum das unbedingt ohne > Bootloader gemacht werden soll?! Ja, sorry, habe fälschlicherweise geglaubt, dass MaWin schrieb: > Christian M. schrieb: >> Wollte eine weitere Fehlerquelle ausschliessen. > > Fehlerquellen schließt man übrigens nicht dadurch aus, indem man vom > Hersteller/Programmierer vorgegebenen Weg abweicht. > Damit fügt man nur Fehlerquellen hinzu. c-hater schrieb: > Christian M. schrieb: > >> Da der ATtiny44 keine solchen Fuses hat > > Doch, hat er natürlich. Das entsprechende Fusebit heißt SELFPROGEN. Die > Wirkung im Vergleich zu den Megas kann man etwa so beschreiben: Ist das > Fusebit programmiert, ist der gesamte vorhandene Flash > Bootloader-Bereich. Interessant nur, dass im gesamten DaBla der Begrif "SELFPRGEN" und "Self programming enable" nur einmal vorkommt - bei den Fuses. Aber eine Beschreibung dazu... Nix. Habe jetzt schon 2 Controller verfust, weiss nicht, ob das noch was bringt... Uebrigens heisst der Bootloader "AVRootloader", habe mich verschrieben. Von Hagen Re: https://github.com/damadmai/AVRootloader https://www.mikrocontroller.net/articles/AVR-Bootloader_mit_Verschl%C3%BCsselung_von_Hagen_Re Gruss Chregu
OK, du hast also ein ganz anderes Problem und wolltest ausschließen, dass der Bootloader damit zu tun hat?? Ich halte das für eine abenteuerliche Idee, aber du wirst schon wissen, warum du so vorgehen willst. Gruß Rainer
wendelsberg schrieb: > Christian M. schrieb: > >> heute morgen schnell exakt nach Anleitung mit BL probiert > > Schnell und exakt schliessen sich nach meinen Erfahrungen gegenseitig > aus. Ich habe es jetzt ganz langsam wiederholt, und jetzt auch ein RS232-Adapter verwendet statt dem FT232, wegen dem Invertieren... Geht aber trotzdem nicht. Der BL scheint nicht zu laufen. Ich hasse fremde Projekte! Gruss Chregu
Christian M. schrieb: > Interessant nur, dass im gesamten DaBla der Begrif "SELFPRGEN" und "Self > programming enable" nur einmal vorkommt - bei den Fuses. Aber eine > Beschreibung dazu... Nix. Quatsch. Unter der Fuses-Tabelle steht sogar eine Anmerkung, die direkt auf den entprechenden Abschnitt des DB verweist. Es ist wie immer: Wer lesen kann, ist klar im Vorteil.
Rainer V. schrieb: > Vielleicht soll das aber hauptsächlich sowas wie ein Kopierschutz sein, Als Kopierschutz macht das nicht wirklich Sinn, schließlich sind beide Komponenten als Binary frei verfügbar. Wenn ich einfach nur kopieren wollte, würde ich halt schlicht beides kopieren. > der verhindern soll, dass jemand mit der Software herumspielt. Das kann man nicht verhindern. Nicht, so lange die Binaries unverschlüsselt sind. Und auch mit Verschlüsselung wird das nix, es sei denn, man hat einen sicheren Container für den Key, was bei einem AVR8 nicht der Fall ist. Ohne so einen Container muss sowohl der Schlüssel als auch der Code zur Entschlüsselung wiederum Teil des Bootloaders sein und liegt damit praktisch im Klartext vor, solange das Binary frei verfügbar ist. Das einzige, was man bei AVR8 machen könnte: Man müßte Chips mit vorprogrammiertem Bootloader und gesetzten Lockbits verkaufen. Dann würde ein Angreifer immerhin die Hilfe freundlicher chinesischer Dienstleister benötigen, um an den Bootloader (und den darin enthaltenen Key) heranzukommen. Aber diese Dienstleistung ist inzwischen so billig geworden, dass man de facto sagen kann: bei einem AVR8 ist ein "Kopierschutz" praktisch nicht mehr zu machen.
c-hater schrieb: > Quatsch. Unter der Fuses-Tabelle steht sogar eine Anmerkung, die direkt > auf den entprechenden Abschnitt des DB verweist. Nein. c-hater schrieb: > Es ist wie immer: Wer lesen kann, ist klar im Vorteil. Genau. Gruss Chregu
Christian M. schrieb: >> Quatsch. Unter der Fuses-Tabelle steht sogar eine Anmerkung, die direkt >> auf den entprechenden Abschnitt des DB verweist. > > Nein. Doch, siehe Anhang.
Der c-hater hat offenbar wie ich in weiser Voraussicht die alten Datenblätter von Atmel archiviert. Seit der Übernahme durch Microchip werden die Datenblätter immer bunter aber auch unvollständiger und fehlerhafter. Im Aktuellen Datenblatt fehlt die Fußnote unter der Tabelle tatsächlich. Das Kapitel "Self-Programming the Flash" gibt es allerdings noch. Ich habe mal das alte Datenblatt angehängt. Frage an Andreas: Können wir mal einen Artikel schreiben, wo wir alle guten alten Datenblätter von Atmel sammeln, um sie für die Nachwelt zu bewahren?
> Im Aktuellen Datenblatt fehlt die Fußnote ...
?
Jetzt bin ich platt! Eben habe ich mir das aktuelle Datenblatt von
Microchip heruntergeladen, nur um festzustellen, dass es dasselbe ist
wie mein altes, vom Oktober 2010, mit Fußnote.
S. Landolt schrieb: > Jetzt bin ich platt! Es kommt noch dicker: Du hast die Suchfunktion Microchip verwendet und das Datenblatt von 2010 gefunden, richtig? Das aktuelle ist von 2015 und wird von Google gefunden: http://ww1.microchip.com/downloads/en/devicedoc/Atmel-7701_Automotive-Microcontrollers-ATtiny24-44-84_Datasheet.pdf Das ist aber noch nicht so schlimm wie der Fall, wo die erforderliche Zugriffs-Reihenfolge auf 16 Bit Register genau falsch herum beschrieben war obwohl es in einer früheren Fassung noch richtig war.
c-hater schrieb: > Doch, siehe Anhang. Im Übrigen ist das, bezogen auf dein Problem, sowieso irrelevant. Man kann mit dieser Fuse im Prinzip nur sagen, ob Bootloaderfunktionalität (sprich: ändern des Flash-Inhalts) überhaupt möglich ist oder eben nicht. Wenn man keinen Bootloader haben will, braucht man auch die Fuse nicht programmieren. Um die eigentliche Firmware zum Laufen zu bringen, muß man nur herausfinden, was der Bootloader AUSSER seinem eigentlichen Job im Kontext der Anwendung tut. Und das können, wie schon weiter oben erwähnt, nur zwei Sachen sein: entweder initialisiert er irgendwelche MCU-Register oder er bringt die Peripherie in einen bestimmten (vom Reset-Zustand abweichenden) Zustand. Bei nochmaligem Nachdenken würde ich hinzufügen: er könnte auch den Code der Anwendung über die allfällige Änderung des Resetvektors hinaus manipulieren... Da der Umfang des Bootloaders doch sehr überschaubar ist, sollte sich problemlos herausfinden lassen, wo genau die Säge klemmt. Weiß man das erstmal, muss man nur noch das Binary der Anwendung so patchen, dass sie dies einfach selber erledigt.
Also ich frage in Google nach 'ATtiny44', dann unter dem Suchergebnis '... Microchip Technology ...' auf deren ATtiny44-Seite, dort unter 'Documents' das 'ATtiny24/44/84 - Complete Datasheet' geladen.
an Stefan Frings: Fällt mir jetzt erst auf: weshalb 'automotive'?
S. Landolt schrieb: > Fällt mir jetzt erst auf: weshalb 'automotive'? Habe ich auch gerade gesehen. Damit hatten wir doch schon öfter Irritationen, das im Automotive Datenblatt gewohnte Infos fehlten.
Stefan ⛄ F. schrieb: > Damit hatten wir doch schon öfter > Irritationen, das im Automotive Datenblatt gewohnte Infos fehlten. Manche Features sind unter den erweiterten Betriebsbedingungen nicht zuverlässig. Somit nicht freigegeben und auch nicht dokumentiert. Selbst, wenn sie nachprüfbar vorhanden sind. Auch sind manchmal die Peripherie "Bausteine" schlicht (gegen stabilere?) ersetzt worden. Also, mich wundert nicht, dass sich das automative vom industriellen Datenblatt unterscheidet.
Arduino Fanboy D. schrieb: > Manche Features sind unter den erweiterten Betriebsbedingungen nicht > zuverlässig. Somit nicht freigegeben und auch nicht dokumentiert. Das könnte hier tatsächlich der Knackpunkt sein. Für das Self-Programming wird der eingebaute Generator (=DCDC-Wandler) für die Programierspannung benötigt. Der funktioniert aber nicht hinreichend gut über den vollen Bereich der Betriebsspannung. Anmerkungen dazu finden sich in zahllosen Errata von AVR8-Datenblättern. Allerdings: Dann hätte für die "automotive"-Variante zumindest dokumentiert gehört, dass diese Fuse KEINESFALLS programmiert werden darf. Also, so oder so: Microchip hat hier Scheisse gebaut.
c-hater schrieb: > Da der Umfang des Bootloaders doch sehr überschaubar ist, sollte sich > problemlos herausfinden lassen, wo genau die Säge klemmt. Weiß man das > erstmal, muss man nur noch das Binary der Anwendung so patchen, dass sie > dies einfach selber erledigt. Und noch eine Idee: Wenn man zu faul/doof ist, das herauszufinden, kann man auch den ganz großen Trick machen: Man zieht genau einmal die vorgesehene Prozedur der Programmierung durch. Dann liest man einfach den kompletten Flash des Targets aus und benutzt für beliebig_viele weitere Kopien schlicht dieses Image... Da ist dann alles, was der Bootloader tut, schlicht mit drinne.
Christian M. schrieb: > Kann man die Firmware auch ohne Bootloader brennen? Bei mir läuft der > Dekoder ohne BL nicht. Ich wiederhole jetzt noch mal...warum nicht einfach den Hersteller des Decoders fragen? Offensichtlich braucht die Firmware doch den Bootloader. Welchen Sinn soll es also machen, die Software ohne Bootloader laufen zu lassen?? Die Antwort auf die Frage ist also schlicht: Nein. Gruß Rainer
c-hater schrieb: > Man zieht genau einmal die vorgesehene Prozedur der Programmierung > durch. Ja, funktioniert nur in meinem Fall auch nicht. Rainer V. schrieb: > warum nicht einfach den Hersteller des Decoders fragen? Ja, werd ich noch als letztes probieren. Sonst lass ich es dann. Wie gesagt, wenn etwas schlecht dokumentiert nicht auf Anhieb läuft, kannstes vergessen... Gruss Chregu
c-hater schrieb: > Dann liest man einfach den kompletten Flash des Targets aus Nur wenn man Reset nicht auf I/O schaltet. Gibt's bei AVR auch so etwas wie HV-Programmierung? Gruss Chregu
Christian M. schrieb: > Nur wenn man Reset nicht auf I/O schaltet. Gibt's bei AVR auch so etwas > wie HV-Programmierung? Wie immer... Das Datenblatt schafft Klarheit, ob und welche HV Methode. Die Kurzfassung: Der Tiny kann es.
Christian M. schrieb: > Gibt's bei AVR auch so etwas > wie HV-Programmierung? Ja, sicher. Braucht halt einen STK500 oder sowas.
...trotzdem interessiert mich immer noch, warum das jetzt unbedingt ohne Bootloader funktionieren soll :-) Gruß Rainer
Weil ich fälschlicherweise angenommen habe, dass ohne BL würde das blinde herumprogrammieren Vereinfachen / Fehler vermeiden. Aber es funktioniert ja auch mit BL nicht! Gruss Chregu
Du hast also ein eigenes Programm für diese Decoder geschrieben und hast nun das Problem, dass es nicht funzt. Das ist bitter, aber man kann sich das Leben durchaus schwerer machen :-) Wünsche viel Erfolg! Rainer
Nein, eben nicht, sonst würd ich es ja bis zu Ende bringen! Es ist ein fertiges Third-Party-Projekt, ohne Source... Gruss Chregu
Christian M. schrieb: > Es ist ein > fertiges Third-Party-Projekt ...scheint aber nicht wirklich fertig zu sein...trotzdem wünsche ich euch viel Glück und Erfolg. Rainer
Christian M. schrieb: > Ja Solltest Du weiter Dein Glück per ISP versuchen wollen, dann würde ich auf hfuse:w:0xDD ändern. Nur Li_R wird dann nicht arbeiten.
Christian M. schrieb: > Nur wenn man Reset nicht auf I/O schaltet. Gibt's bei AVR auch so etwas > wie HV-Programmierung? Also, erstens ja, der Tiny44 kann (serielles) HV-Programming. Aber zweitens, brauchst du das eigentlich gar nicht. Du verkneifst dir einfach die Aktivierung der entsprechenden Fuse (RSTDISBL) bis nach dem Auslesen des kompletten Image. So macht man das übrigens typisch generell: diese Fuse wird immer als letztes aktiviert, nachdem man alles erledigt hat, was über ISP erledigt werden muss. Wenn dazu das Auslesen des Flash gehört, dann eben erst nach Selbigem. > Ja, funktioniert nur in meinem Fall auch nicht. Was genau funktioniert da nicht? Ein wenig konkreter wirst du schon werden müssen... Läßt sich schon der Bootloader nicht brennen? Läßt sich die Firmware nicht via Bootlader brennen? Macht die Firmware nicht, was sie machen sollte? Das sind grob die drei entscheidenden "Schwellen", an denen irgendwas schief gehen könnte.
c-hater schrieb: > Du verkneifst dir einfach die Aktivierung der entsprechenden Fuse > (RSTDISBL) bis nach dem Auslesen des kompletten Image. Übrigens ist die Tatsache, dass der Resetpin als IO verwendet wird, ein sehr guter Grund dafür, einen Bootloader zu verwenden. Der macht es nämlich ohne HV-Gehassel möglich, nachträglich noch bessere Versionen der Firmware zu flashen.
Christian M. schrieb: > Es ist ein > fertiges Third-Party-Projekt, ohne Source... Ich denke, wir werden hier nicht zu einer Lösung kommen. Es geht ja nicht um einen "nackten" Controller, sondern um eine Decoder-Platine, deren Controller neu programmiert werden soll. Und wie auch immer dieses Third-Party-Projekt/Programm ins Spiel kommt, man kann halt nicht mehr, als festzustellen dass es nicht funzt. Gruß Rainer
c-hater schrieb: > So macht man das übrigens typisch generell: diese Fuse wird immer als > letztes aktiviert, nachdem man alles erledigt hat, was über ISP erledigt > werden muss. Und nachdem man das alles gemacht hat, kommt Murphy. Nur deshalb gibt es HV-Programmer... Oliver
Oliver S. schrieb: > Und nachdem man das alles gemacht hat, kommt Murphy. Ja, Scheisse passiert halt gelegentlich. Da kann man grundsätzlich wohl nix gegen machen. Aber natürlich kann man mit gut geplantem Vorgehen einen Haufen Mist daran hindern, überhaupt zu geschehen. > Nur deshalb gibt es > HV-Programmer... Wobei bei den heutigen Preisen eines Tiny44 wohl der Austausch die bei weitem billigere Variante ist. Es sei denn, man hat bereits einen HV-Programmer. Bei den fetteren Teilen, die HVP nur parallel können, muss man ja i.d.R. sowieso tauschen.
c-hater schrieb: > Was genau funktioniert da nicht? Ein wenig konkreter wirst du schon > werden müssen... Das Prog läuft nicht. Na brennen bring ich schon noch zustande, obwohl ich sonst mit PIC zu tun habe. Also brennen geht, Verifying OK. Was kann man sonst noch machen? Nichts! Wie gesagt auch genau nach Anleitung mit BL probiert, der läuft auch nicht. Schon 3 Tinys zerschossen, 2 hab ich noch. Die kann dann sonst jemand haben, der HV kann... Gruss Chregu
Christian M. schrieb: > Das Prog läuft nicht. Na brennen bring ich schon noch zustande, obwohl > ich sonst mit PIC zu tun habe. Also brennen geht, Verifying OK. Was kann > man sonst noch machen? Hast du denn nun den Bootloader mal mit rein gepackt? Es ist gut möglich, dass die Applikation sich darauf verlässt, dass der Bootloader da ist. > Schon 3 Tinys zerschossen, 2 hab ich > noch. Die kann dann sonst jemand haben, der HV kann... Wenn du sie mir mitsamt eines frankierten Rückumschlags sendest, lösche ich dir die Fuses in einem STK500.
Ich wiederhole mich noch mal...nachdem das "dritte-Party-Projekt" ins Spiel gekommen ist, sollte man natürlich auch erst mal bei denen nachfragen. Du hast doch offensichtlich Unterlagen...z.B. sowas wie Step for Step-Anleitung. Fürs Programmieren oder wofür? Und wenn diese Software per Bootloader aufgespielt werden soll, dann stimmt doch ganz woanders irgendwas nicht!? Gruß Rainer
Rainer V. schrieb: > Und wenn diese > Software per Bootloader aufgespielt werden soll, dann stimmt doch ganz > woanders irgendwas nicht!? Nein, für die Verwendung eines Bootloaders gibt es hier einen durchaus legitimen Grund: die Firmware will den Reset-Pin als GPIO verwenden, damit wird er für ISP unbrauchbar. Das ist aber kein Ausrede für die drei verflashten Tinys. Zum Ausprobieren hätte man den Reset-Pin erstmal als solchen belassen können, dann wäre halt einer der Schaltausgänge des Controllers nicht benutzbar gewesen. Es wären aber genug übergeblieben, um die Funktion zu testen.
Ja ich habe inzwischen das Forum entdeckt: https://forum.opendcc.de/viewforum.php?f=39&sid=0fd2e2a69ab84f7b8205e04c2d5680be Da scheint bei niemandem ein entsprechendes Problem zu geben => ich bin zu blöd! Gruss Chregu
Christian, hast du endlich mal den Autor der Schaltung kontaktiert und gefragt? Oder geht es dir nur darum, sein Produkt anzuprangern?
Stefan ⛄ F. schrieb: > Christian, hast du endlich mal den Autor der Schaltung kontaktiert und > gefragt? Das habe ich doch schon mehrmals gefragt! Aber solange da nichts kommt, wird es halt nichts... Gruß Rainer
Also Entschuldigung mal, wenn es bei allen anderen funktioniert liegt es doch klar bei mir! Die Fragen im Forum sagen ja wohl alles. Da muss ich mich nicht zum Affen machen... Gruss Chregu
...bin jetzt etwas irritiert..das es an dir/bei dir liegt, ist ja außer Frage, und das es bei allen anderen funzt, ist neu! Da bin ich aber mal gespannt :-) Gruß Rainer
Stefan ⛄ F. schrieb: > Christian, hast du endlich mal den Autor der Schaltung kontaktiert und > gefragt? Ja, noch keine Antwort bekommen. Rainer V. schrieb: > und das es bei allen anderen funzt, ist neu Ja schau nur mal die Diskutionen im Forum https://forum.opendcc.de/viewforum.php?f=39 an. Die haben andere Probleme, aber die FM läuft dort überall... Gruss Chregu
Es funktioniert jetzt! Habe einen anderen USB-RS232-Adapter genommen, der funktioniert! Ist ein fertiger hp, aber auch mit FT232. Danke an alle für die interessante Diskussion! Gruss Chregu
Christian M. schrieb: > Es funktioniert jetzt! Habe einen anderen USB-RS232-Adapter genommen, Beschreib' doch noch, wie Du vorgegengen bist, d.h. erst Bootloader und dann Programm, oder gleich Programm über ISP geflasht. Wenn über Bootloader geflasht wurde: Der Bootloader wartet auf ein Pinwackeln an PinB2, wenn der FT232 nicht wackelte und der Controller ansonsten leer war, dann rief sich der BL immer wieder selbst auf. Das würde die Adapter-Abhängigkeit erklären.
Hallo Zusammen, TO hätte auch gleich persönlich anfragen können. Das ist alles kein Geheimnis und uralter Code. Der Bootloader ist der org. vom Hagen als 1-wire Ausführung. Die eigentliche DCC FW ist die ASM Variante (nur auf den Tiny44 und zusätzliche Ports angepasst), welche hier im Forum in dem Beitrag von 2005 schon zu finden ist. Da ist nichts geheim und blockiert. Die läuft auch problemlos ohne den BL. Da der BL hier vom watchdog gestartet wird, muss man halt die Fuse entsprechend anpassen. LG Willi
ah, noch vergessen, der Reset Pin wird als IO verwendet, wenn per ISP programmiert werden soll, muss auch diese Fuse angepasst werden und in dem Fall würde ich den Reset Pin selbst auch noch eine Pullup verpassen... LG Willi
Willi schrieb: > Da der BL hier vom watchdog gestartet wird Der Bootloader wird vom Watchdog gestartet? Das wäre mal eine sehr ungewöhnliche Konstruktion...
Jetzt laßt doch mal das Gezanke....wenn ich richtig verstanden habe, dann bezieht sich der TO auf ein Forum, wo die Leute diese Decoderplatine mit einer "neuen" Software programmieren (warum auch immer) und genau dies funzt beim TO nicht. Also ist die Fragestellung doch eine ganz andere...nämlich die, warum nur der TO das nicht programmiert bekommt!? Gruß Rainer
Guten Abend, ist schon richtig, der Bootloader wird nur angesprungen wenn der watchdog einen Reset ausgelöst hat. Hintergrund ist das Schiene - Rad - Kontakt Thema auf einer Moba. Im Normalfall soll nach einem Neustart (Gleisunterbrechung) so schnell wie möglich die Decoder FW wieder laufen. Um trotzdem möglichst einfach automatisch in den BL zu kommen, wird gezielt ein WD IRQ ausgelöst und nur dann wird der BL auch aktiv, sonst reicht er gleich an die FW weiter. Der TO möchte aus irgend einem Grund seinen Decoder abweichend zu dem mal geplanten Weg aufbauen und hat damit Probleme. LG Willi
Rainer V. schrieb: > Also ist die Fragestellung > doch eine ganz andere...nämlich die, warum nur der TO das nicht > programmiert bekommt!? Jeder andere kennt die Antwort auf die Frage schon. Du kannst deine Selbstgespräche beenden. Oliver
Willi schrieb: > der Bootloader wird nur angesprungen wenn der > watchdog einen Reset ausgelöst hat. Dann disassembliere das hex und erkenne, dass auf Portpin B.2 gewartet wird.
... und daran scheiterte es, solange der Controller leer war.
MWS schrieb: > Beschreib' doch noch, wie Du vorgegengen bist Also genau nach Beschrieb, aber nicht in der Schaltung, sondern auf einem Adapter. Script für AVRdude:
1 | avrdude.exe -C avrdude.conf -p t44 -c avrisp -P COM%NEUERCOMPORT% -b 19200 -u -U efuse:w:0xFE:m -U hfuse:w:0xDD:m -U lfuse:w:0xE2:m |
2 | |
3 | avrdude.exe -C avrdude.conf -p t44 -c avrisp -P COM%NEUERCOMPORT% -b 19200 -U flash:w:AVRootloader.hex:i |
4 | |
5 | avrdude.exe -C avrdude.conf -p t44 -c avrisp -P COM%NEUERCOMPORT% -b 19200 -u -U efuse:w:0xFE:m -U hfuse:w:0x5D:m -U lfuse:w:0xE2:m |
Dann den Adapter umgemodelt zum Anschluss an RS232. Habe die einfachste Variante genommen, ohne Dioden. Nur einen 3k3 Widerstand. 5V daneben von USB. AVRootloader auf 9600 Baud, programmiert, fetsch! Gruss Chregu
Christian M. schrieb: > Also genau nach Beschrieb, > ... > Dann den Adapter umgemodelt zum Anschluss an RS232. Habe die einfachste > Variante genommen, ohne Dioden. Nur einen 3k3 Widerstand. Mich interessiert ob Dein erster RS232-Adapter inkompatibel war, der dürfte nicht inkompatibel, sondern defekt gewesen sein, oder Du hast beim zweiten Anschluss des zweiten Adapters etwas geändert Beim Disassemblieren des AVRootladers findet man, dass der Lader auf einen Pegelwechsel an PB2 wartet, um zu starten. Das jedenfalls solange wie das Flash außer dem Bootlader leer ist. Nun ist auf Seite 6 des Manuals die Herstellung der "1-wire"-Verbindung nach RS232 über PB1 gezeichnet. Das passt nicht zum Bootloader, der Aktion auf PB2 erwartet. Im Pdf des Schaltbilds liegt 1-wire auf PB2, da passt's also zum Bootloader. Wenn also der erste RS232-Adapter wie im Manual auf PB1 geklemmt wurde, dann erklärt sich, warum Du zuerst gescheitert bist. Möglicherweise ist beim zweiten RS232-Adapter auch der Wechsel auf den richtigen PB2 erfolgt. Damit müsste auch der erste Adapter arbeiten und es lag nicht am RS232-Adapter, sondern am Fehler im Manual.
MWS schrieb: > Mich interessiert ob Dein erster RS232-Adapter inkompatibel war, der > dürfte nicht inkompatibel, sondern defekt gewesen sein, oder Du hast > beim zweiten Anschluss des zweiten Adapters etwas geändert Ich habe denselben Adapter (SUB-D-9 mit R und SO14, anderes Bild) zuerst an einem Eigenbau USB-RS232-Adapter gehabt, siehe Bild, vorne. Erst mit dem hp, hinten, gings dann. In der Mitte einen FT232 als 5V-Quelle. MWS schrieb: > Nun ist auf Seite 6 des Manuals die Herstellung der "1-wire"-Verbindung > nach RS232 über PB1 gezeichnet. Das passt nicht zum Bootloader, der > Aktion auf PB2 erwartet. Ja, das hatte ich zuerst auch nicht beachtet, und hatte es korrigiert, was aber nichts half. Das Bild ist halt symbolisch und findet sich auch in der Anleitung zum AVRootloader. MWS schrieb: > Im Pdf des Schaltbilds liegt 1-wire auf PB2, da passt's also zum > Bootloader. Ja, das ist korrekt! Christian M. schrieb: > Nur einen 3k3 Widerstand. 2k7! Gruss Chregu
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.