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).
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.
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.
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.
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.
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)
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.
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.
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.
Für den Fall, dass in Zukunft noch jemand mit derselben Frage diesen Thread findet, nachfolgend eine Anleitung, wie es wohl am einfachsten geht:
Snap + MCU anschließen, in MPLABX /IDE/ (also nicht IPE) ein (Wegwerf-) Application Project mit der entsprechenden Ziel-MCU und dem angeschlossenen Snap als Tool erstellen (C oder Assembler, ist egal) und auf /Production/ → /Set Configuration Bits/ klicken. Dann öffnet sich unten ein Fenster wie im angehängten Screenshot; dort zuerst links oben auf /Read Configuration Bits/ klicken, danach kann man rechts in der Tabelle die gewünschten Änderungen vornehmen und schließlich mit Klick auf den linken grünen nach unten zeigenden Pfeil /Program Configuration Bits/ die geänderten Fuses zurückschreiben.
