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?
> 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.
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...
> 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'.
Wie bekommt man denn wieder "Originalzustand" wenn man sich mal "verfused" hat.... ?!
@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...
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
> 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.
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."
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?
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.
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...
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.
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
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
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
@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
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
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/avrstudiohelp/mergedProjects/JTAGICEmkII/mkII/Html/JTAGICE_mkII_Programming_with_JTAGICE_mkII.htm
ISP und debugWire funktionieren biede einwandfrei über JTAGICE mkII beides getestet!
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!?
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...
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.