Bootloader brennen: Falsche Signatur

Hallo!

Mir ist ein Leonardo abgeschmiert, dessen Bootloader ich jetzt von einem Uno neu brennen lassen will. Verkabelt habe ich Old-Style, also pin10-13. Das hat für einen Uno auch schon ein Mal problemlos geklappt, jetzt bekomme ich leider folgende Fehlermeldung:

avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "/home/benutzer1n/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9/etc/avrdude.conf"
User configuration file is "/home/benutzer1n/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/ttyACM0
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega32U4
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack


eeprom 65 20 4 0 no 1024 4 0 9000 9000 0x00 0x00
flash 65 6 128 0 yes 32768 128 256 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Fehler beim Brennen des Bootloaders.
Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x010000
avrdude: Expected signature for ATmega32U4 is 1E 95 87
Double check chip, or use -F to override this check.

avrdude done. Thank you.

Was kann ich tun? :smiley:

Wie kommst du da drauf, die Signatur wäre falsch ?
Ich lese nur, es fehlt eine Datei.

HotSystems:
Wie kommst du da drauf, die Signatur wäre falsch ?
Ich lese nur, es fehlt eine Datei.

Sorry, hatte nur die halbe Fehlermeldung kopiert. Dass die Datei fehlt ist mir auch aufgefallen, da ohne verbose-mode allerdings lediglich die Signatur bemängelt wird war meine Vermutung, dass es daran hakt. Über Hinweise zu der Datei freue ich mich trotzdem!

Über Hinweise zu der Datei freue ich mich trotzdem!

Da fehlt keine Datei!

avrdude: Device signature = 0x010000

Problem mit Verkabelung oder Stromversorgung.

Keine Zweifel, ich habe!

Ich glaube nicht, daß der Bootloader neu zu brennen ist, sondern daß Du einen Sketch draufgeladen hast, der den ATmega32U4 blockiert und somit er nicht mehr einen reset macht, wenn Du einen neuen Sketch raufladen willst.
Lade den Blink Sketch und mache einen manuellen Reset (Resetknopf solange drücken bis er nach dem Kompilieren den Upload machen will; dann loslassen.
Grüße Uwe

Danke für die Antworten! Es lag tatsächlich an der falschen Verkabelung. Die Reset-Lösung hatte ich vorher schon erfolglos probiert. Also noch mal danke!

Die Resetlösumg mußt Du mehrmals versuchen da der richtige Zeitpunkt nicht leicht zu erwischen ist.
Grüße Uwe

uwefed:
Die Resetlösumg mußt Du mehrmals versuchen da der richtige Zeitpunkt nicht leicht zu erwischen ist.
Grüße Uwe

Das hab ich auch, bei einem vorangegangenen Problem hatte das auch funktioniert, jetzt leider nicht mehr.

Ja, man kriegt das wohl hin, dass sich die Dinger nur noch so wieder programmieren lassen.

Deswegen haben Boards, die mehr für USB-Entwicklung gedacht sind, meist Sicherheitsvorkehrungen. Beim Due sind ja "Programming Port" und "Native Port" zwei getrennte USB-Busse. Die Teensy Boards haben diese Taste, die kein Resetbutton ist, sondern das externe Bootloader IC startet, außerdem setzt 15 s Gedrückthalten das Board auf den Blink-Sketch zurück.

Ja, man kriegt das wohl hin, dass sich die Dinger nur noch so wieder programmieren lassen.

Wie soll das gehen?

Man sieht bei der normalen Arbeit mit Micro oder Leonardo unter Windows ja öfter, dass die nach dem Hochladen des Programms eine neue COM-Port Nummer bekommen, bzw. beim Hochladen immer zwischen zwei COM-Port Nummern wechseln.

So was sehe ich weder beim Due noch beim Teensy. So tief stecke ich auch nicht in der USB-Materie drin, da schein beim Reset auf dem Bus irgendwas anders zu laufen, als bei den anderen.

Das führt anscheinend dazu, dass die Reset-Methode manchmal nicht funktioniert, weil der Arduino dann nicht mehr das USB-Gerät ist, das als Ziel in der IDE eingestellt ist.

ArduFE:
Ja, man kriegt das wohl hin, dass sich die Dinger nur noch so wieder programmieren lassen.

Deswegen haben Boards, die mehr für USB-Entwicklung gedacht sind, meist Sicherheitsvorkehrungen. Beim Due sind ja "Programming Port" und "Native Port" zwei getrennte USB-Busse. Die Teensy Boards haben diese Taste, die kein Resetbutton ist, sondern das externe Bootloader IC startet, außerdem setzt 15 s Gedrückthalten das Board auf den Blink-Sketch zurück.

Nein.
Das sind Boards mit Controller die ganz eine andere Architetktur haben. Deshalb ist das Uploaden über serielle Schnittstelle bzw das ISP anders.
grüße Uwe

uwefed:
Das sind Boards mit Controller die ganz eine andere Architetktur haben.

Den Satz verstehe ich nicht ganz. Die älteren Teensy haben einen Atmega32u4 genau wie Arduino Micro und Leonardo.

Deswegen habe ich formuliert

Deswegen haben Boards, die mehr für USB-Entwicklung gedacht sind, meist Sicherheitsvorkehrungen.

Denn die Programmierung erfolgt auch da anders, als bei Arduino.

Ich stecke nicht wirklich ganz tief in der Materie drin, aber um das mit dem USB zu verstehen, habe ich es mir mal parallel auf Micro und Teensy (da allerdings 32 Bit) angesehen.

uwefed:
Deshalb ist das Uploaden über serielle Schnittstelle bzw das ISP anders.

Das ist wahrscheinlich wirklich die Stelle, wo das Problem auftritt, dass sich die Micros manchmal nur noch schwer neu programmieren lassen.

Auch bei den 32u4 basierten Arduinos funktioniert die Programmierung, soweit ich das verstehe, seriell. Jedenfalls muss man ja in der IDE den COM-Port auswählen.

Nun ist aber die Implementierung von Serial im Arduino Core in CDC.cpp und PlugableUSB.h / .cpp also in Code der ins Arduino Programm einkompiliert wird.

Damit die Methode mit dem Reset überhaupt funktioniert, muss es also noch eine USB-Implementierung im Bootlader geben, der das Teil online bringt, um es zu programmieren.

Damit sind wir wieder beim Thema: Wenn man es geschaft hat, das Arduino Programm so zu verwurschteln, dass das Teil gar kein gültiges USB-Gerät mehr darstellt, dann hat man auch keinen Port mehr, der in der IDE erscheint. Das Board wird erst wieder als USB-Gerät erkannt, wenn man den Reset-Button loslässt und der USB-Code im Bootlader ausgeführt wird ...

Oder ist da kein USB-Code im Bootlader und man verlässt sich auf die Serial-Implementierung in einem vorhandenen Arduino Programm ? Dann wäre es klar, dass man nicht mehr programmieren kann, wenn man die einmal kaputt gekriegt hat.

Damit sind wir wieder beim Thema: Wenn man es geschaft hat, das Arduino Programm so zu verwurschteln, dass das Teil gar kein gültiges USB-Gerät mehr darstellt, dann hat man auch keinen Port mehr, der in der IDE erscheint. Das Board wird erst wieder als USB-Gerät erkannt, wenn man den Reset-Button loslässt und der USB-Code im Bootlader ausgeführt wird ...

Falsch!

Meine Frage:

Wie soll das gehen?

Ist mit deinen Beiträgen nicht beantwortet.

Oder ist da kein USB-Code im Bootlader und man verlässt sich auf die Serial-Implementierung in einem vorhandenen Arduino Programm ? Dann wäre es klar, dass man nicht mehr programmieren kann, wenn man die einmal kaputt gekriegt hat.

Der erste Halbsatz ist ok, der Rest nicht.

Also:
Der Bootloader implementiert eine virtuelle Serielle.

Es gibt 3 Möglichkeiten den Bootloader zu starten

  1. Power on
  2. Resetknopf
  3. Falls ein Anwendungsprogramm Serial nutzt, einmal für kurze Zeit auf 1200 Baud umstellen

bzw. beim Hochladen immer zwischen zwei COM-Port Nummern wechseln.

Das ist normal und richtig so.
Der Bootloader implementiert eine andere Serielle, als Serial im Anwendungsprogramm das tut.
Darum sind sie verschieden.

combie:
Ist mit deinen Beiträgen nicht beantwortet.

Für mich jetzt schon hinreichend. Danke.