Forum: Mikrocontroller und Digitale Elektronik AVR Programm brennen ohne Bootloader


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von Christian M. (christian_m280)


Lesenswert?

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

von Sebastian (Gast)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

Ja genau, ohne den BL. Als Programmer habe ich den Arduino as ISP. Der 
funktioniert einwandfrei!

Gruss Chregu

von MaWin (Gast)


Lesenswert?

Bootloader in fuses deaktivieren.
Programm brennen.
Fertig.

von Sebastian (Gast)


Lesenswert?

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

von Christian S. (roehrenvorheizer)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

Christian S. schrieb:
> Programmstart an einer falschen Adresse

Das Hauptprogramm liegt bei AVR immer an Adresse 0.

von Christian M. (christian_m280)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Christian M. (christian_m280)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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!

von Stefan F. (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Einer K. (Gast)


Lesenswert?

c-hater schrieb:
> ...

Leicht verwirrt heute?

von Sebastian (Gast)


Lesenswert?

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

von wendelsberg (Gast)


Lesenswert?

Christian M. schrieb:
> heute morgen schnell exakt nach Anleitung mit BL probiert

Schnell und exakt schliessen sich nach meinen Erfahrungen gegenseitig 
aus.

wendelsberg

von c-hater (Gast)


Lesenswert?

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...

von c-hater (Gast)


Lesenswert?

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.

von Sebastian (Gast)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

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

von Rainer V. (a_zip)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Christian M. (christian_m280)


Lesenswert?

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

von c-hater (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Stefan F. (Gast)


Angehängte Dateien:

Lesenswert?

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?

von S. Landolt (Gast)


Lesenswert?

> 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.

von Stefan F. (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

an Stefan Frings:
Fällt mir jetzt erst auf: weshalb 'automotive'?

von Stefan F. (Gast)


Lesenswert?

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.

von Einer K. (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

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

von Einer K. (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Christian M. schrieb:
> Gibt's bei AVR auch so etwas
> wie HV-Programmierung?

Ja, sicher.

Braucht halt einen STK500 oder sowas.

von Rainer V. (a_zip)


Lesenswert?

...trotzdem interessiert mich immer noch, warum das jetzt unbedingt ohne 
Bootloader funktionieren soll :-)
Gruß Rainer

von Christian M. (christian_m280)


Lesenswert?

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

von Rainer V. (a_zip)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

Nein, eben nicht, sonst würd ich es ja bis zu Ende bringen! Es ist ein 
fertiges Third-Party-Projekt, ohne Source...

Gruss Chregu

von Rainer V. (a_zip)


Lesenswert?

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

von MWS (Gast)


Lesenswert?

Christian M. schrieb:
> Nein, eben nicht

Die .eep wurde hochgeladen?

von Christian M. (christian_m280)


Lesenswert?

Ja

von MWS (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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.

von Christian M. (christian_m280)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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.

von Christian M. (christian_m280)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

Christian, hast du endlich mal den Autor der Schaltung kontaktiert und 
gefragt?

Oder geht es dir nur darum, sein Produkt anzuprangern?

von Rainer V. (a_zip)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

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

von Rainer V. (a_zip)


Lesenswert?

...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

von Christian M. (christian_m280)


Lesenswert?

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

von Christian M. (christian_m280)


Lesenswert?

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

von MWS (Gast)


Lesenswert?

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.

von Willi (Gast)


Lesenswert?

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

von Willi (Gast)


Lesenswert?

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

von c-hater (Gast)


Lesenswert?

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...

von Rainer V. (a_zip)


Lesenswert?

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

von Willi (Gast)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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

von MWS (Gast)


Lesenswert?

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.

von MWS (Gast)


Lesenswert?

... und daran scheiterte es, solange der Controller leer war.

von Christian M. (christian_m280)


Lesenswert?

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

von MWS (Gast)


Lesenswert?

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.

von Christian M. (christian_m280)


Angehängte Dateien:

Lesenswert?

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
Noch kein Account? Hier anmelden.