Hallo, ich arbeite mit einem Atmega328P. Ist es möglich den DebugWire Modus durch eine interne Ansteuerung wieder zu deaktivieren? Also das, was normalerweise durch einen AVR Dragon von extern gemacht wird, jetzt intern im Program zu erledigen. Mir schwebt folgendes vor: Laut http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=113120&start=0 erwartet DebugWire die Char-Sequenz 0x00,0x55,0x06 am Reset Pin. Kann ich eine Software-1-Wire Lösung mit Rx und Tx auf dem Reset Pin aufbauen und dann die obige Sequenz sozusagen "intern" im Microcontroller erzeugen um den DebugWire Modus zu verlassen und wieder ISP zu enablen? Es geht darum, den ISP temporär zu umgehen um mit einem normalen Programmer Daten an den uC zu senden und diese direkt auf dem uC zu verarbeiten. Dies ist notwendig, da keine USB-SPI Bridge vorhanden ist. Völliger Humbug oder vielleicht möglich? Danke!
Fuses kann man nur per Programmer ändern, nie im Programm. Die DWEN Fuse wirst du also im Programm nicht umstellen können. Soviel ist mal sicher. Ob man DebugWire auch noch anders lahmlegen kann weiß ich nicht. gruß cyblord
Ja das ist klar. Normalerweise wird DebugWire ja auch nicht durch das brennen der Fuse deaktiviert, denn auf die Fuses kann man im DebugWire-Modus gar nicht zugreifen. Sondern eben durch eine spezielle Sequenz auf der Resetleitung... ...Aber kann man diese statt von Außen auch von Innen erzeugen?
Oskar K. schrieb: > Völliger Humbug oder vielleicht möglich? Der Begriff 1-wire ist anderweitig definiert und in diesem Zusammenhang "völliger Humbug"
Tempsensor schrieb: > Der Begriff 1-wire ist anderweitig definiert und in diesem Zusammenhang > "völliger Humbug" Ich dachte DebugWire sei eine 1-Wire Kommunikationsschnittstelle. Diese kann man ja softwaremäßig implementieren. Welcher Begriff wäre denn richtiger? Oder wird nicht ersichtlich, was genau ich vorhabe?
Oskar K. schrieb: > Tempsensor schrieb: >> Der Begriff 1-wire ist anderweitig definiert und in diesem Zusammenhang >> "völliger Humbug" > > Ich dachte DebugWire sei eine 1-Wire Kommunikationsschnittstelle. Diese > kann man ja softwaremäßig implementieren. 1-Wire ist ein definiertes Eindrahtprotokoll von Dallas/Maxim. Nicht jedes andere Protokol welches nur eine Leitung benutzt ist deshalb gleich 1-Wire. gruß cyblord
Oskar K. schrieb: > Ich dachte DebugWire sei eine 1-Wire Kommunikationsschnittstelle. Keine Schlamperei bei Fachbegriffen! Das führt zu Missverständnissen und kann auch schon mal richtig teuer werden. Wenn man DebugWire benutzt dann heisst das DebugWire. Es gibt keinen Grund neue/ähnliche Begriffe einzuführen.
Oskar K. schrieb: > ich arbeite mit einem Atmega328P. Ist es möglich den DebugWire Modus > durch eine interne Ansteuerung wieder zu deaktivieren? Also das, was > normalerweise durch einen AVR Dragon von extern gemacht wird, jetzt > intern im Program zu erledigen. Vorab: ich habe noch nie mit dW gearbeitet, nur mal im Datenblatt überflogen, wie es funktionieren soll. Ich nehme an was du vorhast, geht nicht. Und zwar aus folgendem Grund: Henne-Ein-Problem. Wenn die DWEN Fuse gesetzt ist, wird der µC nach dem power-on-reset wohl nicht einfach loslaufen, sondern auf ein GO vom dW-Host warten. Insbesondere kann sich der µC dieses Signal nicht selber senden. > Es geht darum, den ISP temporär zu umgehen um mit einem normalen > Programmer Daten an den uC zu senden und diese direkt auf dem uC zu > verarbeiten. Dies ist notwendig, da keine USB-SPI Bridge vorhanden ist. Das verstehe ich nicht. Was ist ein "normaler Programmer"? Inwiefern unterscheidet der sich vom ISP? Und wie kommt USB ins Spiel? XL
Hi >Henne-Ein-Problem. Wenn die DWEN Fuse gesetzt ist, wird der µC nach dem >power-on-reset wohl nicht einfach loslaufen, sondern auf ein GO vom >dW-Host warten. Insbesondere kann sich der µC dieses Signal nicht selber >senden. Nein, der läuft auch mit eingeschaltetem DW ganz normal. Der Knackpunkt ist, das DW nicht mit DW abgeschaltet werden kann. Über DW kann das Interface nur zeitweise deaktiviert werden damit über ISP die DW-Fuse gelöscht werden kann. MfG Spess
Spess53 schrieb: > >>Henne-Ein-Problem. Wenn die DWEN Fuse gesetzt ist, wird der µC nach dem >>power-on-reset wohl nicht einfach loslaufen, sondern auf ein GO vom >>dW-Host warten. > Nein, der läuft auch mit eingeschaltetem DW ganz normal. Hmm. Dann verstehe ich das Problem nicht. Wenn der µC ganz normal losläuft, dann kann er auch (was der TE mußmaßlich will) einen Bootloader ausführen und seine Firmware selber updaten. > Der Knackpunkt ist, das DW nicht mit DW abgeschaltet werden kann. Klar. Aber das einzige was mit aktiviertem dW nicht geht, ist ja wohl ISP. Und das will der TE explizit nicht benutzen. XL
Hi >Klar. Aber das einzige was mit aktiviertem dW nicht geht, ist ja wohl >ISP. Und das will der TE explizit nicht benutzen. Der TO schrieb: >am Reset Pin. Kann ich eine Software-1-Wire Lösung mit Rx und Tx auf dem >Reset Pin aufbauen und dann die obige Sequenz sozusagen "intern" im >Microcontroller erzeugen um den DebugWire Modus zu verlassen und wieder >ISP zu enablen? Allerdings ist der Eröffnungspost, wie du schon bemerkt hast, recht widersprüchlich. MfG Spess
Hallo, Spess53 schrieb: > Allerdings ist der Eröffnungspost, wie du schon bemerkt hast, recht > widersprüchlich. Ich versuche das Problem und die angedachte Lösung mal etwas genauer zu erklären. Problem: * Als Programmer-Werkzeug steht einzig und allein ein MySmartUSB light zur Verfügung, der über die SPI Schnittstelle per ISP genutzt werden kann. * Am UART des ATMEGA328P sitzt ein Chip, dessen Firmware geupdated werden muss. Dies geschieht durch eine definierte Kommunikationssequenz auf dem UART. * Diese Kommunikationssequenz umfasst ca. 250kB daten, passt also nicht in den Speicher des MC und liegt auf einem PC. Erdachte Lösung: Wenn man eine SPI Verbindung zum MC aufbauen könnte, dann wäre es kein Problem, die Kommunikation einfach vom SPI auf den UART "zu schaufeln" und so die Firmware des zweiten Chips zu updaten. MySmartUSB light kann jedoch nur im AVR ISP Protokoll daten über die SPI Schnittstelle senden. Wenn man nun per DWEN Fuse beim MC die Interpretation dieser Daten abstellt (da im DebugWire Modus ISP deaktiviert ist), könnte man (vermutlich) die Roh-Daten wieder aus dem ISP-Datenstrom herausfiltern und so weiter an den UART leiten. Am Ende ist es jedoch notwendig, dass man per MySmartUSB light oder durch den MC selber den DebugWire Modus wieder verlässt. Klar? Möglich? Danke Oskar.
Spess53 schrieb: > Der Knackpunkt ist, das DW nicht mit DW abgeschaltet werden kann. Über > DW kann das Interface nur zeitweise deaktiviert werden damit über ISP > die DW-Fuse gelöscht werden kann. Wenn das ginge, könnte man ja in diesem Zeitfenster durch den mySmartUSB light die Fuse wieder löschen. Meine Frage bleibt, ob man DW intern überhaupt ansprechen kann.
Oskar K. schrieb: > Klar? Möglich? Ja. Nein. Warum machst du dich nicht einfach an den Reset heran. ISP ist eingeschaltet, wenn Reset auf Gnd gezogen ist. Wenn du verhinderst, durch einen Jumper z.B., der nur zum Programmieren des Avr gesteckt wird, daß der Programmer den Controller auf Reset zieht, kann dieser dem Programmer über Spi vorgaukeln, daß er bereit ist zum Programmieren. Dann kann der Programmer die Daten rüberschaufeln. mfg.
Spess53 schrieb: > Der Knackpunkt ist, das DW nicht mit DW abgeschaltet werden kann. Jein. > Über > DW kann das Interface nur zeitweise deaktiviert werden damit über ISP > die DW-Fuse gelöscht werden kann. Was andererseits allerdings für den angedachten Zweck (neues Programm flashen) völlig ausreichend wäre. Niemand schreibt einem vor, dass man nach der disable-debugWIRE-Sequenz nun unbedingt als nächstes die DWEN-Fuse löschen müsste. Nach dieser Sequenz ist /RESET wieder ganz normal für ISP verfügbar. Der Pferdefuß ist ein anderer: von da kommt man in den debugWIRE-Modus nur über einen power-on-Reset zurück, der dann die (noch gesetzte) DWEN-Fuse neu bewertet. Der genannte temporäre Zustand hält nämlich bis zum nächsten power cycle an. ich dachte ... schrieb: >> Ich dachte DebugWire sei eine 1-Wire Kommunikationsschnittstelle. > > Keine Schlamperei bei Fachbegriffen! Die Schlamperei ist es, "Dallas (oder von mir aus Maxim) 1-Wire" auf "1-Wire" zu verkürzen. Sowohl Dallas 1-Wire als auch debugWIRE sind nun einmal Eindraht-Protokolle, und wie willst du das sonst auf Englisch allgemein beschreiben wenn nicht durch "one-wire"?
Danke für alle bisherigen Beiträge - sehr hilfreiche Anmerkungen! Thomas Eckmann schrieb: > ISP ist > eingeschaltet, wenn Reset auf Gnd gezogen ist. Wenn du verhinderst, > durch einen Jumper z.B., der nur zum Programmieren des Avr gesteckt > wird, daß der Programmer den Controller auf Reset zieht, kann dieser dem > Programmer über Spi vorgaukeln, daß er bereit ist zum Programmieren. Das ist auf jeden Fall relevant für mich - ich werde das ausprobieren. Danke Jörg Wunsch schrieb: > Was andererseits allerdings für den angedachten Zweck (neues Programm > flashen) völlig ausreichend wäre. Niemand schreibt einem vor, dass > man nach der disable-debugWIRE-Sequenz nun unbedingt als nächstes > die DWEN-Fuse löschen müsste. Nach dieser Sequenz ist /RESET wieder > ganz normal für ISP verfügbar. > > Der Pferdefuß ist ein anderer: von da kommt man in den debugWIRE-Modus > nur über einen power-on-Reset zurück, der dann die (noch gesetzte) > DWEN-Fuse neu bewertet. Der genannte temporäre Zustand hält nämlich > bis zum nächsten power cycle an. Auch das wäre kein Problem in meinem Fall. Da ich ja tatsächlich vor dem Power Cycle, die Fuse löschen kann (per Programmer) Was mir noch nicht ganz klar ist: Ist es unerheblich, dass ich die disable-debugWIRE-Sequenz intern generieren möchte? Also, kann es gelingen eine debugWIRE-software-Implementierung mit dem RESET PIN (PC6 beim ATMEGA328) als RX/TX Port zu definieren und dadurch das debugWire des eigenen µC zu steuern? Bisher ging die Diskussion ja nur darum, ob das grundsätzlich (also zB. mit einem 2. µC von außen) möglich ist. Aber entstehen da irgendwelche Probleme dadurch, dass ich per Software den RESET Pin "bespiele"?
Oskar K. schrieb: > Bisher ging die Diskussion ja nur darum, ob das grundsätzlich (also zB. > mit einem 2. µC von außen) möglich ist. Aber entstehen da irgendwelche > Probleme dadurch, dass ich per Software den RESET Pin "bespiele"? Du kannst sicherlich per Software (Transistor an einen anderen Port) am Reset spielen. Jedoch wird dein Spielzeug dann auch einen Reset auslösen. Dann ist sofort schluss mit dem Spiel. Du brauchst dazu also einen zweiten Prozesser, der mitspielen darf.
Oskar K. schrieb: > Ist es unerheblich, dass ich die disable-debugWIRE-Sequenz intern > generieren möchte? Mir ist der Sinn dessen nicht ganz klar. Anders gesagt: gut möglich, dass du das kannst. Aber was nützt es dir? Danach ist den /RESET ja kein debugWIRE-Pin mehr, sondern wieder /RESET, und sowie ein Programmer daran zieht, ist der Controller im Reset. Da kann doch auch gleich der Programmer selbst die disable-dW-Sequenz erzeugen. Die dort genannte Sequenz ist übrigens keineswegs irgendwas "offizielles", sondern die hat offenbar jemand reverse engineert. Damit du das benutzen kannst, müsstest du dich also überhaupt erst einmal mit dem (völlig undokumentierten) debugWIRE befassen um zu sehen, dass dir die Protokollsynchronisation auch zuverlässig gelingt.
Jörg Wunsch schrieb: > Da kann doch auch gleich der Programmer selbst > die disable-dW-Sequenz erzeugen. Ja, wenn der Programmer das könnte. Ich meine aber der mySmartUSB light kann das nicht. Oder, weiß jemand was anderes? Jörg Wunsch schrieb: > Damit du das benutzen kannst, müsstest du dich also überhaupt erst > einmal mit dem (völlig undokumentierten) debugWIRE befassen um zu > sehen, dass dir die Protokollsynchronisation auch zuverlässig > gelingt. Das stimmt auch. Ist auch noch ein ungelöstes Problem. Danke!
Oskar K. schrieb: > Ja, wenn der Programmer das könnte. Dann nimm doch einen, der es kann: JTAGICEmkII, JTAGICE3, AVR Dragon.
Jörg Wunsch schrieb: > Dann nimm doch einen, der es kann: JTAGICEmkII, JTAGICE3, AVR Dragon. Ja na klar. Ich habe ja auch einen, der DW kann. Aber ich möchte eben wissen, ob man es auch ohne könnte, nur mit einem mySmartUSB light zB. Das würde mir einige Zusammenarbeit mit Kollegen, die keinen haben und nicht gerade bei mir im Nachbarzimmer sitzen, deutlich vereinfachen!
Dann würde ich aber eher versuchen, das disable-dW eben diesen Tools beizubiegen, statt auf Krampf den Zielcontroller sich an den Haaren aus dem Sumpf ziehen zu lassen.
Oskar K. schrieb: > Das würde mir einige Zusammenarbeit mit Kollegen, die keinen haben und > nicht gerade bei mir im Nachbarzimmer sitzen, deutlich vereinfachen! Das verstehe ich nicht. Worin liegt der Sinn, einen Controller mit aktiviertem DW unter die Leute zu bringen? Ich benutze auch DW, allerdings nur sehr selten, denn meist finde ich die Fehler ohne Debugger. Wenn ich DW brauche, dann wird es aktiviert, dann wird debuggt, und wenn der Fehler gefunden ist, dann wird die Debug-Sitzung (mit Deaktivieren des Debug-Modus) beendet und sofort darauf per ISP die DW-Fuse deaktiviert. Alles Andere wäre auch kontraproduktiv, denn was nützt mir (oder jemand Anderem) ein Controller oder eine Schaltung mit Controller, der/die nur am Debugger funktioniert? ...
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.