Hallo allerseits,
ich verzweifle gerade an der (selbst gestellten) Aufgabe, mein MPLAB
Snap mittels der MPLAB IPE und einer per avrasm2 erzeugten Hex-Datei
dazu zu bringen, Fuse-Bytes auf einem angeschlossenen ATtiny3227 zu
schreiben.
Was ich bisher versucht habe:
1
.dseg
2
.org FUSE_BODCFG
3
.db 0x40 ; 2.6 V
4
.org FUSE_OSCCFG
5
.db 0x7D ; 16 MHz
6
.cseg
am Anfang der Assembler-Quelldatei; avrasm2 warnte, die Adressen seien
außerhalb des SRAM-Bereichs; das erzeugte Hex habe ich mittels MPLAB IPE
in den tiny3227 geladen, allerdings ohne Erfolg, die Taktfrequenz
(mittels aktiviertem CLKOUT gemessen) liegt immer noch bei 3,33 MHz (=
factory-default 20 MHz mit factory-default 1/6-Prescaling).
Nach Informationen der Microchip-Website
https://developerhelp.microchip.com/xwiki/bin/view/software-tools/ides/x/debugging/view-set-configuration-bits/
lassen sich die Fuses in der MPLAB X IDE im Fenster "Configuration Bits"
einstellen und daraus C-Code generieren (#pragma config ...), allerdings
eben nur in C-Projekten und nicht mit (von MPLAB X scheinbar nicht mehr
unterstütztem) Assembler.
Johannes Fe schrieb:> ich verzweifle gerade an der (selbst gestellten) Aufgabe, mein MPLAB> Snap mittels der MPLAB IPE und einer per avrasm2 erzeugten Hex-Datei> dazu zu bringen, Fuse-Bytes auf einem angeschlossenen ATtiny3227 zu> schreiben.
Das geht auch schlicht und einfach nicht. Du kannst in einer Hex-Datei
keine Fuses unterbringen. Das kannst du nur in Elf-Dateien. Und die kann
avrasm2 nicht erzeugen. Naja, jedenfalls nicht von Hause aus. Man kann
es ihm beibringen, aber das ist doch eher mühsam und alleine kann er es
dann immer noch nicht, man braucht mindestens ein zusätzliches Tool, um
das erzeugte Hexfile dann nachträglich in ein binäres File zu
verwandeln. Das darf dann allerdings strohdumm sein, braucht wirklich
nur 1:1 umzuwandeln.
Der Witz bei der ganzen Sache ist: auch das Elf-Format verwendet im
Prinzip nur einen Trick, um sowas wie Fuses (oder Sigrow oder...) zu
ermöglichen. Dieser Trick funktioniert nur per Konvention. Einen echten
physikalischen Hintergrund hat die Sache nicht. Der Trick ist: Es wird
einfach völlig willkürlich ein Speicherbereich (weit außerhalb des
Flashbereichs) zum Träger der Fuse-Informationen bestimmt. Der
Generator (also der Linker) kennt den, die Brenntools kennen den und so
kann das funktionieren. Das Brenntool trifft halt auf diesen
Speicherbereich und weiß: Aha, das sind jetzt Fuses, die muß ich dem
Target auf andere Weise verklickern als den Flashinhalt.
Dasselbe Grundprinzip hätte man auch für Hexfiles verwenden können. Aber
es gab halt hierfür nie eine ensprechende Konvention. Deswegen kann's
der avrasm2 nicht erzeugen und kein Brenntool könnte es brennen.
Ob S. schrieb:> Du kannst in einer Hex-Datei> keine Fuses unterbringen.
Ja stimmt, in der Hex-Datei ist ja wohl nur der Code-Space enthalten,
nicht der gesamte Data-Space ... Denkfehler meinerseits. Kenne mich mit
diesen Dingen auch zugegebenermaßen noch nicht besonders aus.
Dann muss ich mich wohl nun erstmal damit beschäftigen, wie ich dem XC8
meine Assembler-Quellen füttern kann ...
Es sieht so aus, als ob die zu schreibenden Fuse Bytes von MPLABX am
Ende der Hex-Datei abgelegt werden; siehe dazu die angehängten Dateien
eines Minimal-C-Projekts (in Zeile 23 der *.hex finden sich die
Fuse-Werte wieder). Scheint aber nicht offiziell dokumentiert zu sein,
wie genau das codiert ist, zumindest habe ich nichts dazu gefunden.
Also: Work-around für mich wird erstmal sein, pro Device ein
"Dummy"-C-Projekt (Main-Funktion mit Endlosschleife) zu erstellen, darin
die gewünschten Fuse-Werte zu deklarieren, das ganze zu compilieren und
die resultierende Hex in die IPE zu laden, um die Fuses zu schreiben.
Beim anschließenden Flashen einer nicht-inhaltsleeren Firmware sollten
die vorher geschriebenen Fuses ja erhalten bleiben.
Das sind diese beiden Zeilen hier:
(der besseren Lesbarkeit wegen habe ich Leerzeichen eingefügt
:02 0000 04 0082 78
Das ist der "record type" 'Extended linear Address', für folgende Bytes
wird als MSW der Adresse 0x0082 verwendet
:09 0000 00 00547E0000F6FF0000 30
Die Werte kommen einem bekannt vor:
Die stehen in den folgenden zwei Zeilen drin:
:02 0000 04 0083 77
"Extended Address" 0x0083
:01 0000 00 C5 3A
Adresse 0x0083 0000 bekommt also das Byte C5 verpasst.
Ich denke, daß damit der Aufbau hinreichend klar ist.
Wenn der eigene Assembler/Compiler das nicht erzeugen kann, ist es recht
leicht, das von Hand an das Hex-File anzuhängen. Vor die letzte Zeile
(End of file record) werden die vier Zeilen eingefügt, fertig.
Harald K. schrieb:> Den Aufbau dieser Struktur hat hier> https://www.avrfreaks.net/s/topic/a5C3l000000UctsEAC/t163324 schon mal> wer beschrieben.
Die steht auch immer im DB drin. Siehe Anhang für den konkreten
Tiny3227.
Allerdings: Wenn man den Kram selber erzeugt, heißt es bei etlichen
Typen aufpassen bezüglich der reservierten Bereiche. Die sind als
reserviert markiert. Das bedeutet nicht, dass da nicht u.U. etwas ist,
was etwas bewirkt...
Es ist dringend empfehlenswert, ein reales Exemplar des Targets
auszulesen, um an die Default-Werte der reservierten Bereiche zu kommen.
Ob der konkrete Tiny3227 diesbezüglich kritisch ist, entzieht sich
allerdings meiner Kenntnis.
Dirk F. schrieb:> Falsch. In von MPLABX erzeugten HEX files sind fuse bit setting drin.> https://microchip.my.site.com/s/article/Creating-production-file-for-AVR-devices-using-MPLAB-X-IDE
Interessant. Hoffen wir, dass sich das analog zur Situation beim
Elf-Format zur allgemein anerkannten und unterstützten Konvention
entwickelt.
Ich habe allerdings ganz erhebliche Zweifel daran, dass MC das dem
avrasm2 noch beibiegen wollen würde. Obwohl es ja ziemlich sicher sehr
einfach umzusetzen wäre.
Nö, sieht eher so aus, als wäre der genauso auf dem sterbenden Ast wie
das MC-Studio insgesamt auch.
Im vorliegenden Beispiel werden zwei reservierte Bereiche mit 0
beschrieben; man könnte aber bei etwaigen Unsicherheiten reservierte
Bereiche auch ausschließen:
:03 0000 00 00547E pp
:04 0005 00 F6FF0000 pp
(die Prüfsumme zu berechnen war ich jetzt zu faul und hab' stattdessen
"pp" hingeschrieben)
Harald K. schrieb:> man könnte aber bei etwaigen Unsicherheiten reservierte> Bereiche auch ausschließen:>> :03 0000 00 00547E pp> :04 0005 00 F6FF0000 pp
Das klappt aber leider nur mit ganzen reservierten Bytes. Bei vielen
Typen gibt es aber auch reservierte Bits innerhalb von Bytes mit
dokumentierten Bits. So auch im konkreten Beispiel bei OSCCFG, SYSCFG0
und SYSCFG1.
Ob S. schrieb:> Bei vielen> Typen gibt es aber auch reservierte Bits innerhalb von Bytes mit> dokumentierten Bits.
Dann wird im Datenblatt drinstehen, welcher Wert da 'reinzuschreiben
ist.
Oder man kann bei Unsicherheit mit dem "offiziellen" Compiler ein
Hexfile erzeugen lassen und nachsehen.
Für die beiden im vorliegenden Fall reservierten Bytes nimmt der
Compiler z.B. 0 an.
Obendrein enthält die im Codebeispiel verwendete Struktur komplette
Bytes.
Das scheint also kein relevantes Problem zu sein.
Ob S. schrieb:> Das klappt aber leider nur mit ganzen reservierten Bytes. Bei vielen> Typen gibt es aber auch reservierte Bits innerhalb von Bytes mit> dokumentierten Bits. So auch im konkreten Beispiel bei OSCCFG, SYSCFG0> und SYSCFG1.
Allerdings: dafür stehen wiederum die Default-Werte im DB.
Harald K. schrieb:> Ob S. schrieb:>> Allerdings: dafür stehen wiederum die Default-Werte im DB.>> Na dann ist der Drops ja gelutscht und das Verfahren ist anwendbar.
Jepp.
Ob S. schrieb:> Harald K. schrieb:>> Ob S. schrieb:>>> Allerdings: dafür stehen wiederum die Default-Werte im DB.>>>> Na dann ist der Drops ja gelutscht und das Verfahren ist anwendbar.>> Jepp.
Das war vielleicht voreilig. Kommt dann noch darauf an, ob das Brenntool
mit fragmentierten Fuse-Bereichen klarkommt. Darauf wetten würde ich
nicht unbedingt.
Thread beobachten
Seitenaufteilung abschalten