Hi,
Ich programmiere meine ATmega32U4 schon längere Zeit mit dem folgenden
Setup:
Programmer: Arduino Uno
Kabelverbindung: 6 Pin (5V, GND, RFS, SCK, Mo, MI)
Software: AVRDUDESS 2.13 (avrdude version 6.3)
Mein Ziel ist es jetzt, dass ich mit der hfuse 0xF8 das SPIEN
deaktiviere um die serielle Programmierfunktion zu deaktivieren und den
Controller permanent zu programmieren.
Dabei bekomme ich folgende Fehlermeldung:
1
avrdude.exe: verification error, first mismatch at byte 0x0000
2
0xd8 != 0xf8
3
avrdude.exe: verification error; content mismatch
Programmieren geht weiterhin und das hfuse byte ist weiter 0xD8.
Was mache ich falsch? Warum kann ich die fuse bits nicht setzen?
Ich hoffe auf eure Hilfe.
lG
Fpdragon F. schrieb:> Was mache ich falsch?
Nich richtig ins Datenblatt schauen.
> Warum kann ich die fuse bits nicht setzen?
Weil das so ist. ;-)
Solange ich AVRs kenne, steht folgende Fußnote bei SPIEN:
"1. The SPIEN Fuse is not accessible in serial programming mode."
Bei einigen anderen AVRs kann man effektiv die ISP-Funktion noch dadurch
trotzdem abklemmen, dass man RSTDSBL programmiert, aber der ATmega32U4
hat so eine Fuse nicht.
Ist aber eigentlich auch sinnlos. Wenn du das Ding absichern willst,
programmierst du die Lockbits. Dann geht es nur noch über einen Chip
Erase zurück. Ansonsten ist die Fuse natürlich über JTAG verfügbar.
EAF schrieb:> Der Bootloader kann die Fuses nicht ändern.> Ein ISP oder HV Programmer könnte das.
Ok, zum Verständnis:
Ich programmiere mein ATmega32U4 board mit einem zusätzlichen Arduino
Uno Board.
Sprich, ja ich verwende keinen ISP aber der Bootloader sollte auch nicht
aktiv sein weil ich den ja auch mit programmiere. Und das funktioniert
ja.
Ich vermute daher es ist was anderes.
Jörg W. schrieb:> Fpdragon F. schrieb:>> Was mache ich falsch?>> Nich richtig ins Datenblatt schauen.>>> Warum kann ich die fuse bits nicht setzen?>> Weil das so ist. ;-)>> Solange ich AVRs kenne, steht folgende Fußnote bei SPIEN:>> "1. The SPIEN Fuse is not accessible in serial programming mode.">> Bei einigen anderen AVRs kann man effektiv die ISP-Funktion noch dadurch> trotzdem abklemmen, dass man RSTDSBL programmiert, aber der ATmega32U4> hat so eine Fuse nicht.>> Ist aber eigentlich auch sinnlos. Wenn du das Ding absichern willst,> programmierst du die Lockbits. Dann geht es nur noch über einen Chip> Erase zurück. Ansonsten ist die Fuse natürlich über JTAG verfügbar.
Ok, die schnippische Antwort überlese ich mal...
Danke für den Hinweis. Vl sind die Lockbits ja das was ich brauche. Dazu
muss ich mich jetzt erstmal einlesen.
Letztendlich möchte ich nur verhindern, dass das Gerät nicht mehr
umprogrammiert werden kann und am Besten auch der Flash Speicher nicht
ausgelesen werden kann.
Ich hab mir jetzt die Lockbits angesehen.
Die sind derzeit auf 0x3F gesetzt sprich es gibt keine Restriktionen.
Ich habe versucht sie auf 0xFF zu programmieren aber auch die Lock bits
kann ich nicht programmieren.
Hier steht im Datenblatt aber konkret, dass das über serial gehen
sollte.
Hmmm...
Fpdragon F. schrieb:> Ich habe versucht sie auf 0xFF zu programmieren aber auch die Lock bits> kann ich nicht programmieren.
Wenn ein Fusebit programmiert ist, ist es 0. Im unprogrammierten Zustand
ist es 1. Ja, das ist invers zur normalen Logik, ist bei Fusebits aber
halt so.
Weber schrieb:> Ja, das ist invers zur normalen Logik, ist bei Fusebits aber halt so.
Das liegt einfach an der Art und Weise, wie NOR-Flash funktioniert. Im
gelöschten Zustand sind alle Bits '1'. Daher ist eine gesetzte Fuse '0'.
Gelöschter Flash und EEPROM liest sich ja auch als 0xFF aus.
Fpdragon F. schrieb:> Letztendlich möchte ich nur verhindern, dass das Gerät nicht mehr> umprogrammiert werden kann
Das kannst du übrigens sowieso nicht komplett verhindern: im HV-Modus
lässt sich der Chip immer programmieren. Allerdings muss man ihn
üblicherweise dazu aus dem Gerät entnehmen.
Fpdragon F. schrieb:> EAF schrieb:>> Der Bootloader kann die Fuses nicht ändern.>> Ein ISP oder HV Programmer könnte das.>> Ok, zum Verständnis:> Ich programmiere mein ATmega32U4 board mit einem zusätzlichen Arduino> Uno Board.
Deine Zeile sagt aber:
Fpdragon F. schrieb:> -c arduino
Wenn du "Arduino as ISP" verwendest, würde ich da "-cstk500v1"
erwarten.
-carduino kenne ich nur in Verbindung mit einem Bootloader.
Jörg W. schrieb:> "1. The SPIEN Fuse is not accessible in serial programming mode."
Das ist natürlich ein Hemmnis!
Dann eben HV parallel
EAF schrieb:> Das ist natürlich ein Hemmnis!> Dann eben HV parallelJTAG wäre einfacher …
> Wenn du "Arduino as ISP" verwendest, würde ich da "-cstk500v1"> erwarten.> -carduino kenne ich nur in Verbindung mit einem Bootloader.
Kommentar aus arduino.c:
1
/*
2
* avrdude interface for Arduino programmer
3
*
4
* The Arduino programmer is mostly a STK500v1, just the signature bytes
Da war jetzt einiges dabei, danke für die Inputs.
Ich würde das geschriebene gerne ein wenig sortieren. Bitte korrigiert
mich wenn ich wo falsch liege.
Ich verwende einen Arduino Uno mit dem Arduino Sketch
"File->Examples->ArduinoISP->ArduinoISP" und dem #define
"USE_OLD_STYLE_WIRING"
Am Target ATmega32U4 ist standardmäßig JTAGEN=disabled und SPIEN=enabled
und das lockbyte 0x3F.
1.
Sprich: Ich habe zwar einen ISP aber ich verwende derzeit "nur" eine
normale serielle (SPI?!) Übertragungsmethode?!
2.
JTAG ist mit dem ArduinoISP nicht möglich?!
3.
Wenn doch müsste ich vorher per SPI das entsprechende HFuse.JTAGEN
enablen. Zusätzliche Arbeitsschritte.
4.
Das Wichtigste ist für mich, dass man die Firmware nicht mehr in ein hex
file dumpen kann oder es wenigstens erschwert. Daher ging ich auf bare
metal, ohne bootloader und wollte ich zuerst das serielle
Programmierinterface deaktivieren. Das geht scheinbar nicht weil immer
ein Programmierinterface aktiviert sein muss (SPI oder JTAG)?!
5.
Die eigentliche richtige Methode, um einen "Kopierschutz" zu
implementieren sind die lock bits. Gesetzt verhindern sie, dass das
Flash geschrieben und von der Programmierschnittstelle gelesen werden
kann?!
6.
Um die lock bits wieder rückzusetzen ist ein chip reset nötig und daher
ist ein kopieren der firmware nicht mehr möglich weil sie mit diesem
Vorgang mit gelöscht wird?!
7.
Die SPIEN fuse kann ich nicht disablen weil das nicht über SPI geht. Das
hab ich jetzt verstanden.
Warum kann ich aber die lock bits nicht über meinen SPI ISP ändern? Im
Datenblatt wird explizit geschrieben: "The Boot Lock bits can be set by
software and in Serial or in Parallel Programming mode."
Danke für die Hilfe.
Fpdragon F. schrieb:> Um die lock bits wieder rückzusetzen ist ein chip reset nötig und daher> ist ein kopieren der firmware nicht mehr möglich weil sie mit diesem> Vorgang mit gelöscht wird?!
Korrekt.
> Die SPIEN fuse kann ich nicht disablen weil das nicht über SPI geht. Das> hab ich jetzt verstanden.> Warum kann ich aber die lock bits nicht über meinen SPI ISP ändern?
Du kannst, aber wie überall bei NOR-Flash kannst du sie nur von '1' nach
'0' schreiben. Der Rückweg von '0' nach '1' ist kein Schreiben, sondern
Löschen, halt das, was über den Chip Erase gemacht wird. Daher sind sie
nach dem Chip Erase 0x3F. Wenn du sie setzen willst, must du 0x3C
reinschreiben (die dann noch auf '1' stehenden Bits beziehen sich auf
den Bootloader, die interessieren dich wahrscheinlich nicht weiter, es
sei denn, du hast einen solchen).
Ich glaub jetzt hats geklappt.
Ich hab einfach herumprobiert und dabei hab ich's letztendlich
geschnallt... Ich hab scheinbar die falschen bits im lock byte
beschrieben.
Wenn ich einfach beinhart von 0x3F auf 0x00 geschrieben und siehe da, es
schein zu klappen.
EEPROM dump kann ich zwar immer noch ausführen aber der Inhalt ist nur
noch 0xFF...
Flash dump bricht überhaupt ab und er schreibt, dass der Flash leer ist.
Schreiben kann ich aber noch. Sprich wenn ich das Image erneut
programmiere, dann wird das lock byte wieder zurückgesetzt. Anscheinen
führt AVRDUDESS bzw avrdude automatisch einen chip reset durch wenn das
Flash geschrieben wird.
Wie auch immer... Mit dieser Lösung kann ich leben.
Danke!
Fpdragon F. schrieb:> Schreiben kann ich aber noch. Sprich wenn ich das Image erneut> programmiere, dann wird das lock byte wieder zurückgesetzt. Anscheinen> führt AVRDUDESS bzw avrdude automatisch einen chip reset durch wenn das> Flash geschrieben wird.
Das machen die meisten Flash-Programme per Voreinstellung.
Fpdragon F. schrieb:> Schreiben kann ich aber noch. Sprich wenn ich das Image erneut> programmiere, dann wird das lock byte wieder zurückgesetzt.
Ja klar, ansonsten könntest du ja auch da nur Bits von '1' nach '0'
schreiben. Wenn du also versuchst, ein 0x55 auf ein Byte zu schreiben,
das vorher 0xAA hatte, kommt am Ende 0x00 raus. Daher wird per
Voreinstellung zuerst ein Chip Erase gemacht. Für den EEPROM kann man
dabei festlegen, ob dieser vom Chip Erase mit gelöscht werden soll oder
nicht.
Fpdragon F. schrieb:> Ich programmiere mein ATmega32U4 board mit einem zusätzlichen Arduino> Uno Board.
Dein Zusätzliche Arduino UNO Board ist in diesem Fall der ISP
Programmieradapter. Der folgende Satz stimmt daher nicht:
> Sprich, ja ich verwende keinen ISP> aber der Bootloader sollte auch nicht> aktiv sein weil ich den ja auch mit programmiere
Der Satz ergibt keinen Sinn. Während du über ISP programmierst, ist der
Bootloader jedenfalls nicht aktiv.
Fpdragon F. schrieb:> Ich vermute daher es ist was anderes.
Verstehe ich nicht. Willst du dem Datenblatt widersprechen?
Jörg W. schrieb:> "1. The SPIEN Fuse is not accessible in serial programming mode."
Das steht da wirklich drin.
Thread beobachten
Seitenaufteilung abschalten