www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik debugWIRE mit JTAG ICE mkII


Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat damit schon jemand gearbeitet? Ist mit debugWIRE auch programieren
der Chips in kleinen Serien praktikabel? Leider Schweigen die
Datenblätter zu den Details wie z.B. Können Fuses und Locks gesetzt und
gelöscht werden?

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist mit debugWIRE auch programieren der Chips in kleinen Serien
> praktikabel?

Ganz und gar nicht. debugWIRE eignet sich ausschließlich zum Debuggen.
Zum Programmieren brauchst Du nach wie vor ISP. Atmels mkII beherrscht
das Programmieren über ISP übrigens nicht (nur zum Enablen/ Disablen
von debugWIRE), da braucht es zusätzlich ein zweites Gerät. Ich habe
keine Ahnung, ob sich Atmel dabei etwas gedacht hat oder nicht.

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade,

aber irgendwie habe ich so was befürchtet, obwohl die Featureliste des
Mega88 klar was anderes behauptet...

Jetzt wäre nur noch interesant ob es zum fuse unbd lock Handling auch
noch den parallel Modus braucht. Laut doku löscht ein chip erase, der
auch seriell möglich ist, alle locks und fuses.

Da hilft wohl nur ausprobieren...

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber irgendwie habe ich so was befürchtet, obwohl die Featureliste
> des Mega88 klar was anderes behauptet...

Nicht das wir aneinander vorbeireden: Der Debugger ist schon in der
Lage, das Programm über debugWIRE in den Controller zu jagen (anders
wäre das Ganze auch reichlich sinnfrei).

Das nützt Dir aber in der Serie nichts, und so sagt es dann auch die
Hilfe zum mark2: "Note that debugWIRE is a debugging interface only
and not a programming interface."

Zum Fusen und Locken bin ich bislang seriell ganz gut klargekommen
(ATmega168). Ich habe mich aber auch noch nicht wirklich 'verfused'.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie bekommt man denn wieder "Originalzustand" wenn man sich mal
"verfused" hat.... ?!

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@René
ist schon klar. Ich begreif allerdings nicht warum man nicht ein
einheitliches Interface pflegt, statt 3e die alle teilweise
überlappende Funktionssets haben. Man könnte je wenigstens eine Tabelle
spendieren was mit welchem Interface geht bzw. nicht geht.


@Wolfgang
laut datenblatt mit einem Chip erase command. Ob er das natürlich im
LB3 Mode noch versteht? So steht es im Datenblatt, Zitat:
"Further programming and verification of the Flash and EEPROM
is disabled in Parallel and Serial Programming mode. The Boot
Lock bits and Fuse bits are locked in both Serial and Parallel
Programming mode."

Die LB1 und LB2 werden dort als "Memory Lock Bits" bezeichnet.

Jetzt darf spekuliert werden...

Autor: Armin Kniesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir ziemlich sicher dass man mit dem debugWire auch Fuses setzen
und flashen kann, ALLERDINGS wenn man zuerst per SPI die
debugWire-Enable-Fuse gesetzt hat. Danach ist kein SPI mehr möglich,
bis man nicht wieder per debugWire diese Fuse setzt.

Alles klar?

Armin

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Alles klar?

Ganz und gar nicht. Ich kann per debugWIRE keine Fuses setzen, selbst
für DWEN brauche ich ISP ("The debugWIRE interface itself cannot
enable this fuse."). Wie also machst Du das?

@Robert
Beim ChipErase werden EEPROM, FLASH und die LockBytes gelöscht. Das
funktioniert prima.

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BTW: Vermieden werden sollte die Kombination DWEN und LockBits gesetzt.
"Always be sure that the lockbits are cleared before programming the
DWEN fuse and never set the lockbits while the DWEN fuse is programmed.
If both the debugWIRE enable fuse (DWEN) and lockbits are set, one can
use High Voltage Programming to do a chip erase, hence clear the
lockbits."

Autor: marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der grund für das debugwire ist, ganz einfach, dass man den chip in der
fertigen schaltung lassen kann und innerhalb dieser schaltung (wo der
chip dann auch zum einsatz kommt) zu debuggen und nicht etwa den chip
beim debuggen herauszunehmen. auch werden dann keine funktionalen Pins
verschwendet (Reset resetten halt nur).

wegen den einheitlichen programmier-interface:
kann nicht jtag auch debuggen?

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Grund für debugWIRE ist schon klar. Nicht klar ist, warum der mkII
nur solch halbherzige ISP Fertigkeiten hat. Der JTAGICE (der Erste) ist
doch schliesslich auch in der Lage, die Controller über ISP zu
programmieren, AFAIK.

> wegen den einheitlichen programmier-interface:
> kann nicht jtag auch debuggen?

Ja, aber das kostet, wie Du selbst festgestellt hast, viele PINs.

Autor: marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo wir gerade bei mangelhaft geplanten isp's sind:
avrisp (über spi) ist auch recht gut gelungen...
bei den AT90S hat fast jeder Typ einen neuen Befehl für die Lock Bits
bekommen. Und außerdem ist ein nachträgliches emulieren von chips, die
in der firmware nicht drin sind, (noch) nicht möglich...
was besonders schon ist, wenn man neue Chips hat...

Autor: Armin Kniesel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DWEN setzt man per SPI
und
DWEN löscht man per debugWire.

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, so sehe ich das auch. Man kann per debugWIRE keine Fuses
setzen. Man hat lediglich Einfluss auf DWEN, und dieses Bit lässt sich
auch nur löschen. Du schriebst aber:

> ... auch Fuses setzen ...

Ein Fuse-Bit haben wir jetzt ja geklärt. Und weiter? Ich für meinen
Teil brauche immer noch ein weiteres Gerät, um vor der Debug-Sitzung
die (anderen) Fuses wie gewünscht zu setzen/ löschen.

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
JTAG ICE MKII kann im Prinzip alle Bereiche der Controller
programmieren. Leider ist das AVR Studio einmal mehr nicht aktuell.
Deshalb ist es, wie Rene schon sagt, nur mit einem "anderen"
Programmer möglich, die Fuses zu setzen.

MfG

Koopi

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an alle,

da steckt ja jede Menge Information drin. Nur eines ist mir nicht ganz
klar, schliessen sich SPIEN und DWEN gegenseitig aus? Im Datenblatt des
Mega88 steht davon nichts drin, die einzige Einschränkung ist, dass
SPIEN im seriellen Modus nicht erreichbar ist.

Oder anders gefragt, muss DWEN wirklich gelöscht werden bevor man LB1
und LB2 setzt (per SPI). Externer Reset ist dann natürlich im Target
nicht möglich. Aber warum ist dann in diesem Zustand kein serieller
ChipErase mehr möglich?

Robert

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Help me please!!

So nun habe ich einen Aufbau mit STK500 und JTAG-ICE MKII und natürlich
AVR Studio. Und der Ärger fängt gleich an... dabei sollte alles so
simple sein.

Ist das normal?
1.
Der Versuch einen Mega88 zu programmieren klappt nur im SPI Mode, aber
nicht im HV-Parallel Mode!? Dieser Mode erlaubt nur Fuse settings zu
verändern oder z.B. die Signatur zu lesen. Ein Versuch zu flashen
scheitert. (Ja ich habe die Kabel alle so gesteckt wie in der htm hilfe
beschrieben)

2.
ISP über SPROG2 man kann das flash normal programmieren, aber der
Versuch die Debugwire Fuse zu setzen führt direkt in den Abgrund. (->
nächster MEGA88 bitte oder zurück zum HV Mode..)

3.
DebugWire über JTAG-ICE MKII klappt. Debuggen und reprogrammieren
klappt gut. So aber jetzt werde ich die DWEN Fuse nicht mehr los. Der
beschriebne Weg über das debug menue klappt nicht. Wenn man trotzdem
irgendwie den dialog mit dem button zum löschen der dwen fuse
hochkriegt kratzt AVR Studio einfach mit Schutzverletzung ab. Wieder
hilft nur: (-> nächster MEGA88 bitte oder zurück zum HV Mode..)


Hat da jemand gute tipps wie man mit dieser Konfiguration einigermassen
rationell arbeiten kann?

Robert

Versionen:

AVR Studio    4.11.410  Service Pack 3
GUI Version    4, 11, 0, 403
JTAGICE mkII    1, 0, 1, 119
ATmega88    156

Operating System
Major      5
Minor      0
PlatformID    2
Build      2195
Service Pack 4

Plugins:

Stk500Dll  1, 0, 0, 44

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert,

zu1.
Parallelmode klappt mit Mega168 und Mega8 wunderbar. Habe noch keinen
Mega88 getestet.
Hast Du die Jumper für z.B. reset auf dem STK500 überprüft?

zu3.
Über Menü "Debug  JTAGICE MKII OPTIONS  Connection / Disable Debug
Wire" kann man das Bit zurücksetzen. Leider nur wenn ein Projekt
geladen ist.

Koopi

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Koopi,

zu 1.
ja Jumper sind gesetzt. Man kann auch fuses setzen / rücksetzen, oder
die Signatur lesen. Aber eben kein flash lesen oder schreiben.

zu3.
ja mittlerweile bin ich draufgekommen, nicht nur ein Projekt laden
sondern auch eine debugsession muss laufen, dann erscheint der
Menuepunkt im AVR Studio...

Robert

Autor: fuzzy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls jemand diesen alten Thread findet: Was auch immer das Problem mit 
dem mkII und programmieren über ISP gewesen ist, mittlerweile scheint es 
zu gehen (siehe [1]). Zumindest behauptet Atmel: "In addition to using 
the JTAGICE mkII as an On-Chip Debugger, it can also be used as a 
programmer through both the JTAG and ISP interface." Allerdings hab ich 
es nicht getestet ...

[1] 
http://support.atmel.no/knowledgebase/avrstudiohel...

Autor: GAST (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ISP und debugWire funktionieren biede einwandfrei über JTAGICE mkII 
beides getestet!

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Es ist schon ein etwas älterer Beitrag aber ich versuche es hier einmal!

Ich habe so meine Erfahrungen mit dem Atmega168 (DIL).
Wenn ich über das mkII ein Programm debuge wird ja das "DWEN" Fuse 
gesetzt.
Danach ist kein Zugriff per SPI mehr möglich. Das "SPIEN" ist auch 
gesetzt.

Den DIL habe ich dann einfach in einen Galep4 Programmer gesteckt und 
das DWEN gelöscht. Danach ist der Zugriff per SPI wieder möglich.

Nun habe ich den Atmega168 aber in 32 Pin SMD:
Ich habe ohne Probleme mit dem mkII das DWEN gesetzt beim Debug.

Nun habe ich nach einem Powerreset aber das Problem, dass das debuggen 
nicht mehr geht und auch die SPI nicht geht. Am einfachsten wäre es halt 
per Programmer wieder zu löschen um die SPI wieder zu aktivieren.
Das ist mit SMD und fehlendem Programmieradapter für den Galep aber 
nicht so einfach.

In AVR Studio v5 finde ich keine Möglichkeit das DWEN temporär wieder zu 
deaktivieren um die Fuses dann per SPI wieder einstellen zu können.

Kann mir jemand eine Anleitung geben wie ich mit dem mkII und AVR Studio 
v5 das DWEN wieder weg kriege!?

Autor: Hugo Portisch (portisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EDIT:

Ich habe mir nun die Beta 5.1 installiert. Jetzt gibt es ein Command 
Tool und ein "Disable DebugWire" option.

Das gab es bei der 5.0 noch nicht...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.