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.
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.
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
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.
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
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
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.
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.
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.
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).
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.
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).
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?
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.
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
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
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.
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 :)
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.