kein debugwire wegen USB-Problem?

Jörg H. OP #4233560
Lesenswert?
• ▲
▼ 
Hallo,

bei dem Versuch einen ATtiny13 in den DebugWire Modus zu bringen,
bekomme ich die angehängte Fehlermeldung.

Das Atmel Studio 6 (Version: 6.1.2730 - Service Pack 2)
läuft dabei in einer VirtualBox unter Ubuntu und ist mit einem
JTAGICE MK2 über USB (laptop) verbunden.
Flashen, Fuses lesen/schreiben etc. über ISP funktioniert.

OS ist winXP, gemeldet als:

---------------------------------------------------------

OS Version: Microsoft Windows NT 5.1.2600 Service Pack 3
Platform: Win32NT


Installed Packages: Shell VSIX manifest - 6.1
Shell VSIX manifest
Version: 6.1
Package GUID: 5aa6ea3e-da7b-48c1-9b2a-cab2329d32ac
Company: Atmel Corporation


Installed Packages: Atmel Gallery - 1.3.1
Atmel Gallery
Version: 1.3.1
Package GUID: AtmelStudioExtensionManager
Company: Atmel


Installed Packages: Atmel Kits - 1.2.147
Atmel Kits
Version: 1.2.147
Package GUID: bea809ab-462e-4535-99f1-3f9ced2f09ff
Company: Atmel


Installed Packages: AtmelToolchainProvider - 6.1.0.447
AtmelToolchainProvider
Version: 6.1.0.447
Package GUID: 
AtmelToolchainProvider.Atmel.83804b14-6626-4e13-bfdc-3a0135fa98f1
Company: Atmel


Installed Packages: Visual Assist X for Atmel Studio - 10.7.1930.2
Visual Assist X for Atmel Studio
Version: 10.7.1930.2
Package GUID: 7997A33C-B154-4b75-B2AC658CD58C9510
Company: Whole Tomato Software
---------------------------------------------------------

Ich würde nun gern mit DebugWire debuggen, bekomme aber bei
"Start debugging and break" nur die Meldung s.A. Reset-Leitung
ist frei, Takt intern (Auslieferungszustand)

joh
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jörg H. OP #4233845
Lesenswert?
• ▲
▼ 
Dieter F. schrieb:
> DWEN Fuse gesetzt?

ich habs mit und ohne programmierter DWEN Fuse probiert, gleiche 
Fehlermeldung. Nur das ich 2 13er mit programmierter DWEN Fuse jetzt
nicht mehr zurück zu ISP bekomme...

> Pullup an Reset 10 - 20 KOhm?

ja. Leitungslänge alles original Atmel max 20cm.
> ...
>
> (Datenblatt Kap. 15 gelesen ... ?)

ja, das war die Basis
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter F. Gast #4233970
Lesenswert?
• ▲
▼ 
Hat mich jetzt interessiert, da ich auf einem Tiny13 noch nie ein 
Debugging gemacht habe (und schon gar nicht mit debug wire).

2 Tinys habe ich jetzt auch schon dem direkten Zugriff entzogen :-(

Fehlermeldung bekomme ich keine, kann auch das Debugging starten (und 
werde gefragt, ob ich im SPI-Modus DWEN setzen möchte). Dat tue ich ...

Ich komme dann auch ins Debugging - kann aber den Debug-Modus des Tiny13 
nicht mehr beenden (Menu - Debug - Disable debugWire and Close).

Nutze Atmel Studio 6.2 und einen JTAGICE-Clon.


Ich spiele später nochmal weiter (habe noch ein paar Tiny13)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter F. Gast #4234059
Lesenswert?
• ▲
▼ 
Also - funktioniert jetzt bei mir.

Auslieferungszustand - ABER CH8DIV-Fuse deaktiviert. Dann geht alles 
wunderbar - bei mir zumindest. Man muss das Debuggen aber mit o.g. 
Menu-Punkt beenden. Nach Aktivieren der Fuse startet der Tiny13 nur noch 
im Debug-Mode - erst durch das ausschalten im Debug-Menu kann er wieder 
normal genutzt werden. Geht aber auch nach Restart wieder aus dem 
debuggen heraus.

UND ich habe den Pullup (lt. debug wire Hinweis 
https://www.mikrocontroller.net/articles/DebugWIRE) auf 4,7 KOhm 
gesetzt.

Für die beiden "Opfer" werde ich wohl mal einen "high voltage 
programmer" basteln. Wollte ich sowieso schon immer mal ...


PS: Lt. errata muss man bei debug wire immer die höchste Start-Wartezeit 
fusen (ist im AUslieferungszustand so) - daher kam ich auf die Idee, 
auch mal die CH8DIV-Fuse auszuschalten.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg H. OP #4234545
Lesenswert?
• ▲
▼ 
Dieter F. schrieb:
> Also - funktioniert jetzt bei mir.
>
> ...
> Für die beiden "Opfer" werde ich wohl mal einen "high voltage
> programmer" basteln. Wollte ich sowieso schon immer mal ...
>

dazu würde mich jetzt auch mal ein link oder eine Kaufempfehlung 
interessieren, ich habe auch den dritten und letzten meiner tiny13 
ent-ISP'et. Damit ist nun erst mal Schluß mit probieren.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg H. OP #4236282
Lesenswert?
• ▲
▼ 
Dieter F. schrieb:
> Und - funktioniert es bei Dir (mit vorgenannten Anpassungen) auch?

nein, sowohl mit als auch ohne CKDIV8 fuse bei
SUT_CKSEL: INTRCOSC_4MHZ8_14CK_64MS lässt sich der DW nicht einschalten:
das Studio (extra auf 6.2 upgedatet) fragt erst, ob es die DWEN brennen
soll (bejaht) und fordert dann zum cyclen der targetpower auf.
Danach ist Ruhe, Meldung ist:

------
Failed to enable DM: Failed to enter programming mode. ispEnterProgMode: 
Error status
received: Got 0xc0, expected 0x00 (Command has failed to execute on the 
tool)
------


joh

Danke für den Tip mit dem Fleuromat, der funktioniert  :)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
neuer PIC Freund Gast #4236304
Lesenswert?
• ▲
▼ 
Probier mal den ATtiny13A. Hatte auch schon mal das "A" unterschlagen 
und debugwire versteht dabei kein Spaß. Fehlermeldung wie bei dir. Erst 
setzten der DW-Fuse, danach Ruhe. Got 0xC0 heisst wohlmöglich "dw on". 
Neues Projekt erstellt, derselbe Prozessor als A-Version. Und schon lief 
dW.

Insofern wieder pfui Atmel, wenn der Debugger nicht mal die uc 
identifizieren kann und der User mit so tollen Fehlermeldungen beglückt 
wird.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter F. Gast #4236338
Lesenswert?
• ▲
▼ 
Jörg H. schrieb:
> SUT_CKSEL: INTRCOSC_4MHZ8_14CK_64MS

Standard ist aber 9MHZ6_14CK_64MS mit aktivierter CK8DIV-Fuse. Wenn 
ich bei dieser Einstellung die CK8DIV-Fuse abschalte funktioniert das 
debuggen bei mir.

Tiny13A habe ich nicht probiert - es funktioniert mit dem "normalen" 
Tiny13.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg H. OP #4236603
Lesenswert?
• ▲
▼ 
Dieter F. schrieb:
> Jörg H. schrieb:
>> SUT_CKSEL: INTRCOSC_4MHZ8_14CK_64MS
>
> Standard ist aber 9MHZ6_14CK_64MS mit aktivierter CK8DIV-Fuse. Wenn
> ich bei dieser Einstellung die CK8DIV-Fuse abschalte funktioniert das
> debuggen bei mir.
>
> Tiny13A habe ich nicht probiert - es funktioniert mit dem "normalen"
> Tiny13.

es geht jetzt mit beidem 13 wie 13A bei deaktivierter CKDIV8.
((step over ok, aber run (F5) startet nicht wirklich die Abarbeitung))

Könnte vielleicht ein aktivierter PU an pin5 (MOSI) im Anwenderprogramm
die Probleme bewirkt haben? Nur von der Theorie her..?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dieter F. Gast #4236829
Lesenswert?
• ▲
▼ 
Hast Du die hier

https://www.mikrocontroller.net/articles/DebugWIRE

berschriebenen Einschränkungen beachtet? Ein PU an Pin5 spielt keine 
Rolle, da der Reset-Pin genutzt wird. Hast Du ggf. einen Kondensator am 
Reset-Pin? Der darf da nicht sein ..

Ich konnte (bei 9,6 MHz ohne CLK8DIV) einen Breakpoint setzen und nach 
Stop am Breakpoint mir aktuelle Register etc. ansehen. Intensivere Tests 
habe ich nicht vorgenommen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg H. OP #4236932
Lesenswert?
• ▲
▼ 
Dieter F. schrieb:
> Hast Du die hier
>
> https://www.mikrocontroller.net/articles/DebugWIRE
>
> berschriebenen Einschränkungen beachtet?


Ja, s.o.


> Ein PU an Pin5 spielt keine
> Rolle, da der Reset-Pin genutzt wird. Hast Du ggf. einen Kondensator am
> Reset-Pin? Der darf da nicht sein ..

gewollt nicht, aber es gibt ja offb. ein delta zw. meinem Design und dem 
breadboard Aufbau. Das muß ich jetzt überprüfen.
Erstmal vielen Dank!

joh


> Ich konnte (bei 9,6 MHz ohne CLK8DIV) einen Breakpoint setzen und nach
> Stop am Breakpoint mir aktuelle Register etc. ansehen. Intensivere Tests
> habe ich nicht vorgenommen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren