Forum: Mikrocontroller und Digitale Elektronik Atmega328P per Atmel-ICE löschen trotz Lock


von fop (Gast)


Lesenswert?

Ich habe hier einen Arduino Pro Mini, den ich per AtmelStudio und 
Atmel-ICE programmieren wollte. Also ohne die Arduino IDE und den 
Bootloader auf dem Chip.
Eigentlich wollte ich den Chip erst ganz zum Schluss gegen Auslesen 
schützen. Durch einen Tippfehler in einem Define sind folgende 
Einstellungen wirksam geworden :
1
#ifndef FUSE_CKSEL0
2
#define FUSE_CKSEL0 FUSE_SUT_CKSEL0
3
#endif
4
#ifndef FUSE_CKSEL1
5
#define FUSE_CKSEL1 FUSE_SUT_CKSEL1
6
#endif
7
#ifndef FUSE_CKSEL2
8
#define FUSE_CKSEL2 FUSE_SUT_CKSEL2
9
#endif
10
#ifndef FUSE_CKSEL3
11
#define FUSE_CKSEL3 FUSE_SUT_CKSEL3
12
#endif
13
#ifndef FUSE_SUT0
14
#define FUSE_SUT0 FUSE_SUT_CKSEL4
15
#endif
16
#ifndef FUSE_SUT1
17
#define FUSE_SUT1 FUSE_SUT_CKSEL5
18
#endif
19
FUSES =
20
{
21
    .low = (FUSE_SUT0 & FUSE_CKSEL0),
22
    .high = (FUSE_SPIEN & FUSE_WDTON),
23
    .extended = (FUSE_BODLEVEL0 & FUSE_BODLEVEL1)
24
};
25
26
LOCKBITS = (LB_MODE_3 & BLB0_MODE_1 & BLB1_MODE_1);

Jetzt würde ich den Chip gerne wieder neu beschreiben. Früher hat man 
die Lockbits bei Atmel durch komplettes Löschen des Chips wieder 
gelöscht bekommen. Das will mir jetzt aber hier nicht gelingen.
Auf dem Board ist der Mikrocontroller mit einem 16 MHz Resonator 
verbunden.
Ich habe alle Signale des 6-poligen Debug Steckers angeschlossen, so 
dass ISP möglich sein sollte. Bzw. es ist möglich gewesen, da die 
DebugWire Schnittstelle im Auslieferungszustand deaktiviert war.

Es geht mir nur darum, den Chip wieder nutzen zu können. Das Programm, 
das drinne ist kenne ich sowieso. Ausserdem ist es Schrott.
Der Arduino Bootloader ist nicht mehr im Chip.

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


Lesenswert?

fop schrieb:
> Auf dem Board ist der Mikrocontroller mit einem 16 MHz Resonator
> verbunden.

Hast du mal verifiziert, dass der auch schwingt?

Nicht, dass da irgendwas kaputt ist.

von Oliver S. (oliverso)


Lesenswert?

fop schrieb:
> Früher hat man
> die Lockbits bei Atmel durch komplettes Löschen des Chips wieder
> gelöscht bekommen.

Auch wenn dein ganter Text keine direkte Frage enthält, hier trotzdem 
mal eine Antwort auf eine der nicht gestellten Fragen:

Nein, da hat sich nichts geändert.

Und uabhängig daqvon, ob Atmel bzw. Microchip das Verhalten dieses 
Prozessormodells gegenüber einem "früher" mal geändert hätten, steht 
alles dazu im aktuellen Datenblatt.

Oliver

von fop (Gast)


Lesenswert?

Ok, ganz direkte Frage :
Wie bekomme ich den Chip in einen Zustand, in dem ich wieder mit dem 
Debugger darauf zugreifen kann, so dass ich die Software auf dem Chip 
wieder ändern und debuggen kann ?

So besser.......

Also, das Programm, das drinne ist lässt eine Led blinken. Das Timing 
stimmt.
Ausserdem habe ich mehr als eine Platine in dem Zustand.
Gleich nachdem AtmelStudio anbietet, die DWEN-Fuse zu brennen, um 
debuggen zu können geht der Spaß los.

von Oliver S. (oliverso)


Lesenswert?

fop schrieb:
> Gleich nachdem AtmelStudio anbietet, die DWEN-Fuse zu brennen, um
> debuggen zu können geht der Spaß los.

debugWire ist mit gesetzten Lockbits deaktiviert, wofür willst du DWEN 
setzen? Chip Erase geht nur über ISP oder Parallel.

ISP-Frequenz passt zur Prozessorfrequenz?

Oliver

von Einer K. (Gast)


Lesenswert?

fop schrieb:
> Wie bekomme ich den Chip in einen Zustand, in dem ich wieder mit dem
> Debugger darauf zugreifen kann, so dass ich die Software auf dem Chip
> wieder ändern und debuggen kann ?

Wenn das mein Problem wäre....
Dann würde ich versuchen mit der Arduino IDE und dem Atmel ICE den 
Bootloader neu zu brennen, um eine definierte Startposition zu haben.
Gelingt das nicht, würde ich den Chip als verfused ansehen.
Also dann mit einem HVPP den Chip in den Auslieferungszustand versetzen, 
oder gleich die gewünschten Fuses setzen.

Beim HVPP aufpassen, denn ein Pullup geht von Reset zu Vcc.
Der kann die 12V zu Vcc übertragen. Das muss unterbunden werden.
Auch hängt da ein Kondensator dran, welcher dir (wenn DTR verbunden) 
einen Streich spielen kann.

https://www.arduino.cc/en/uploads/Main/Arduino-Pro-schematic.pdf

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


Lesenswert?

Oliver S. schrieb:
> debugWire ist mit gesetzten Lockbits deaktiviert

Wenn das dW tatsächlich aktiv ist, könnte das das k.o. sein bzw. die 
Notwendigkeit, zur Parallelprogrammierung zu greifen.

Ansonsten ist dW natürlich immer pusselig, was die zusätzlichen Lasten 
an /RESET angeht: keine kapazitive Last (abseits der 
Schaltungskapazitäten), Pull-up von 4,7 bis 10 kΩ kann zuweilen die 
Situation verbessern.

von fop (Gast)


Angehängte Dateien:

Lesenswert?

Wenn ich Tools/Device Programming direkt anwähle, gibt es wenigstens 
eine Warnung.
Also quasi ein Denkfehler im Konzept. Sobald man Debug Wire aktiviert 
ist ISP tot.

von Georg M. (g_m)


Lesenswert?

fop schrieb:
> Sobald man Debug Wire aktiviert ist ISP tot.

Ja.
https://de.wikipedia.org/wiki/DebugWIRE

Beitrag #6113930 wurde von einem Moderator gelöscht.
von Axel S. (a-za-z0-9)


Lesenswert?

fop schrieb:
> Also quasi ein Denkfehler im Konzept. Sobald man Debug Wire aktiviert
> ist ISP tot.

Das ist das dokumentierte Verhalten. RTFM!

von fop (Gast)


Lesenswert?

Kann es sein, dass dieses DebugWire ein absoluter Denkfehler ist ?
Sobald man nicht haargenau den Anweisungen von Atmel Studio folgt, oder 
auch nur der Debugger zufällig abkackt, ist der Chip für die Tonne.
Das kann doch nicht sein, dass man in Zeiten von Flash-Speicher wieder 
ICs tauschen muss :-(((( Damals, als die noch zum Löschen und neu 
Programmieren aus der Schaltung raus mussten, waren sie wenigstens 
gesockelt.
Das ich anfangs DWEN und JTAGEN durcheinander geworfen habe, war mein 
Fehler. Aber es bleibt trotzdem Murks. Der Chip hat immerhin das Mega im 
Namen. Da erwartet man doch kein dermasen sinnfrei abgespecktes 
Debug-Interface.

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


Lesenswert?

fop schrieb:
> Kann es sein, dass dieses DebugWire ein absoluter Denkfehler ist ?

Es ist halt eine Variante, überhaupt ein Online-Debugging realisieren zu 
können bei kleinen Devices, ohne zusätzliche IO-Pins opfern zu müssen.

Es ist auf jeden Fall ein Kompromiss, und er ist bekannt dafür, dass er 
ein bisschen fragil ist.

Andererseits: Online-Debugging braucht man während der Entwicklung, 
nicht „im Feld“. Die Fragilität beeinträchtigt also nicht das fertige 
Gerät, und während der Entwicklung kann man halt auch mal Kompromisse 
eingehen (bspw. eben keinen zusätzlichen Abblock-C an /RESET, den man 
dort sonst zur Verbesserung der Störsicherheit vorsehen würde).

> Sobald man nicht haargenau den Anweisungen von Atmel Studio folgt, oder
> auch nur der Debugger zufällig abkackt, ist der Chip für die Tonne.

Nein.

Erstens hast du natürlich immer noch die Option der HV-Programmierung, 
damit ist er schon mal nicht für die Tonne. Gut, bei einem ATmega328 ist 
das HVPP, das ist in der Schaltung natürlich schwierig. (Bei den kleinen 
ATtinys, wofür debugWIRE entwickelt worden war, ist es HVSP, das kann 
man sogar zur Not in der Schaltung hinbekommen.)

Zweitens kann man natürlich auch nachträglich das einmal aktivierte 
debugWIRE wieder abschalten. Müsste sogar mit Atmel Studio irgendwie 
gehen, aber damit kenne ich mich nicht aus. AVRDUDE wirft bei den Chips, 
die debugWIRE haben, bei einem Fehlversuch der ISP-Aktivierung 
automatisch die Sequenz zur Außerbetriebnahme von debugWIRE an. Das ist 
allerdings eine vorübergehende Außerbetriebnahme: um sie permanent zu 
machen, muss man in diesem Modus die DWEN-Fuse dann löschen. (Das ist 
letztlich die Sequenz, die auch Atmel Studio intern beim 
Außerbetriebnehmen des debugWIRE abarbeitet.)

> Aber es bleibt trotzdem Murks. Der Chip hat immerhin das Mega im
> Namen.

Ist aber halt in dieser Hinsicht ein Tiny.

> Da erwartet man doch kein dermasen sinnfrei abgespecktes
> Debug-Interface.

Nicht „sinnfrei abgespeckt“, sondern „nachgerüstet“. Der Vorgänger war 
der ATmega8, der hatte kein Debugging, und der wiederum stammte vom 
AT90S4433 ab. Vermutlich hat man den Namen "ATmega" für den ATmega8 
gewählt, weil er den AVR-Core mit den Multiplikationsbefehlen bekommen 
hat.

Es gab aber anfangs auch andere ATmegas ohne Debug-Interface (ATmega103, 
der zweite AVR überhaupt; ATmega163). Die Ergänzung mit der JTAG Engine 
kam erst später (ATmega128, ATmega16).

: Bearbeitet durch Moderator
von Stefan F. (Gast)


Lesenswert?

fop schrieb:
> Sobald man Debug Wire aktiviert ist ISP tot.

Wenn man zwischen den Zeilen liest, ist das logisch. Denn Debug Wire und 
RESET teilen sich einen Pin. Und ISP ist nur während des RESET aktiv.

> Sobald man nicht haargenau den Anweisungen von Atmel Studio folgt, oder
> auch nur der Debugger zufällig abkackt, ist der Chip für die Tonne.

Nein, man kann den Debugger immer nachträglich verbinden und in den ISP 
Modus wechseln. Dann kann man über ISP die Debug-Wire Fuse wieder 
abschalten.

Nachtrag: Sorry Jörg, ich wollte dir nicht nachplappern. Ich habe 
voreilig geantwortet bevor ich deinen Beitrag las.

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


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich habe voreilig geantwortet bevor ich deinen Beitrag las.

Hat sich beim Schreiben überschnitten, dafür musst du dich nicht 
entschuldigen.

Ggf. kannst du ja noch posten, wie das mit Atmel Studio geht.

Die einzige Einbahnstraße ist es übrigens, wenn das Boarddesign zwar ISP 
aber nicht debugWIRE gestattet (üblicherweise wegen ungünstiger 
Beschaltung des /RESET-Pins): dann kann man DWEN setzen, aber danach 
kein debugWIRE aktivieren und damit auch nicht das debugWIRE-Kommando 
zur Rückkehr in den Normalmodus absetzen ("Reset with MonCon disabled" – 
MonCon ist der ursprüngliche Name von debugWIRE, der drückt auch recht 
genau aus, was das Ganze ist: ein ROM-Monitor-Programm).

von Axel S. (a-za-z0-9)


Lesenswert?

fop schrieb:
> Kann es sein, dass dieses DebugWire ein absoluter Denkfehler ist ?
> Sobald man nicht haargenau den Anweisungen von Atmel Studio folgt, oder
> auch nur der Debugger zufällig abkackt, ist der Chip für die Tonne.

Wenn du schon reden mußt, dann rede doch wenigstens nicht so einen 
Blödsinn. Der Chip ist nicht für die Tonne. Wenn DebugWire 
eingeschaltet wurde, dann bleibt es so lange aktiv, bis es wieder 
ausgeschaltet wird.

> Das kann doch nicht sein, dass man in Zeiten von Flash-Speicher wieder
> ICs tauschen muss

Muß man nicht. Wenn ISP nicht funktioniert, dann ist wohl DW aktiv. Also 
verbinde dich einfach mit dem Debugger per DW und schalte es aus. Danach 
geht ISP auch wieder. Du tauschst dein Auto ja auch nicht um, wenn der 
Aschenbecher voll ist. Oder doch?

von Stefan F. (Gast)


Lesenswert?

Jörg W. schrieb:
> Ggf. kannst du ja noch posten, wie das mit Atmel Studio geht.

Keine Ahnung, ich habe das Atmel Studio nach einem kurzen Test weg 
gelegt, weil es mir zu träge war. Den Debugger (im AVR Studio) habe ich 
auch schon ewig nicht mehr mit Hardware benutzt (sondern nur mit 
Simulator). Ich komme mit seriellen Log-Meldungen besser klar.

von Oliver S. (oliverso)


Lesenswert?

Axel S. schrieb:
> Muß man nicht. Wenn ISP nicht funktioniert, dann ist wohl DW aktiv. Also
> verbinde dich einfach mit dem Debugger per DW und schalte es aus.

Auf dem Prozessor sind die lock bits gesetzt, damit ist der Zugriff über 
das debugWire-Interface deaktiviert (der Pin wird im Prozessor nur 
durchgeschaltet, wenn keine lock bits gesetzt sind). ISP geht 
anscheinend auch nicht, und HV-Prgrammierung kann der ICE nicht.

Oliver

: Bearbeitet durch User
von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Stefan ⛄ F. schrieb:
> Keine Ahnung, ich habe das Atmel Studio nach einem kurzen Test weg
> gelegt, weil es mir zu träge war.

Och,
dabei ist das für meinen niedrigsten Intelligenzquotienten genau das 
Richtige, wüsste garnicht, was ich ohne machen sollte.

Merke:
Da gibt es noch mehr Fallstricke bezüglich Fuses und wie man die 
vermurksen kann. Ckdiv8 zum Beispiel.

ciao
gustav

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


Lesenswert?

Oliver S. schrieb:
> Auf dem Prozessor sind die lock bits gesetzt

Ach ja, stimmt ja.

Dann bleibt nur HVPP. Kann man unter Lehrgeld abbuchen: mit Lockbits 
fummelt man erst herum, wenn der Rest funktioniert.

In den Sourcecode gehören meiner Meinung nach die Lockbits sowieso nie 
rein, aber wie sagen die Amis so schön: YMMV.

von Axel S. (a-za-z0-9)


Lesenswert?

Oliver S. schrieb:
> Axel S. schrieb:
>> Muß man nicht. Wenn ISP nicht funktioniert, dann ist wohl DW aktiv. Also
>> verbinde dich einfach mit dem Debugger per DW und schalte es aus.
>
> Auf dem Prozessor sind die lock bits gesetzt, damit ist der Zugriff über
> das debugWire-Interface deaktiviert

Ah, das hatte ich schon wieder verdrängt.
Na dann - SDS (selbst dran schuld).
Und LDS (Lernen durch Schmerz). Brauchen manche wohl :)

: Bearbeitet durch User
von Beo Bachta (Gast)


Lesenswert?

Axel S. schrieb:
> Und LDS (Lernen durch Schmerz). Brauchen manche wohl :)

Ja, so ein Controller kostet ja wirklich viel Geld. Das
tut richtig weh wenn man einen neuen kauft.

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.