Problem mit Atmel AVRISP MKII --> Busy

[Klaus (Gast)]

Hallo,

folgendes Problem habe ich:

Ich kann aus dem Atmel Studio mittels ARVISP MKII Programmer einmal 
meinen Controller programmieren.
Wenn ich jedoch erneut das Device Programming Fenster aufrufe wird mein 
Programmer immer mit Busy angezeigt.
Ich muss dann den Programmer nochmals vom USB trennen.

Treiber für den Programmer sowie Atmel Studio habe ich bereits 
neuinstalliert. Jedoch ohne Erfolg.

Hat jemand eine Idee?

Danke
 Klaus

[Uwe K. (ukhl)]

Ist das bei allen Schalungen so?

Verwende mal einen anderen USB-Port.

[?!? (Gast)]

Uwe K. schrieb:
> Ist das bei allen Schalungen so?

Reden wir hier von Tiefbau? (Sorry, nur Spaß) :-))

[isidor (Gast)]

Klaus schrieb:
> Hat jemand eine Idee?

Dein Programm im Controller "bearbeitet" (bewusst oder versehentlich)
die SPI Leitungen ?

Zeig dein Programm und deine Schaltung, damit wir nicht mit der
Glaskugel raten müssen.

[Neuling (Gast)]

Hallo

ich habe hier exat das selbe Problem. Allerdings hängt bei mir kein tiny 
sondern ein ATmega32 am mkII. Es ist ganz egal, welches Programm ich 
reinlade oder wie die Schaltung aussieht (schon einiges probiert - immer 
das selbe)

Ich hab beispielsweise nur eine LED mit Vorwiderstand an einem Pin von 
PortD. Dies lasse ich über mein Progamm im Sekundetakt blinken. Der 
Controller wird über ein Labornetzgerät mit 5V versorgt. Das ist alles 
an "Schaltung".

EINMAL kann ich das Ding Programmieren - danach: BUSY. USB abstecken - 
anstecken - geht wieder. Wieder EINMAL....

Jemand eine Idee?

[florian C. (Gast)]

Neuling schrieb:
> Ich hab beispielsweise nur eine LED mit Vorwiderstand an einem Pin von
> PortD.

Wenn dabei eine Programmierleitung benutzt wird und der vorwiderstand 
der LED zu klein ist, kann das zu Problemen führen.
Hatte ich selber schon beim AVRISP MKII.
Nach Vergrößerung auf über 3kOhm ging es wieder.

[Loocee L. (loocee)]

Ds klingt nach einem Masse-Problem das ich schon erlebt habe ....

Wenn der Rechner und das Labor-Netzteil mit ihrer DC-Masse nicht
auf gleichen Potential sind (aus welchem Grund auch immer)
können Masseströme den ganzen Aufbau beträchtlich stören.

Dazu müsste man mal die Spannungsdifferenz auf den Massen
nachmessen (Prozessor im Betrieb und Programmer abgetrennt).
Da sollten sich keine grossen Spannungen nachweisen lassen
da die Versorgung ja sehr niederohmig ist.

Ich habe für solche Eventualitäten zum Potentialausgleich ein
dickes Massekabel vom Rechner zum Testaufbau gelegt .....

[MikeAT (Gast)]

florian C. schrieb:
> Neuling schrieb:
>> Ich hab beispielsweise nur eine LED mit Vorwiderstand an einem Pin von
>> PortD.
>
> Wenn dabei eine Programmierleitung benutzt wird und der vorwiderstand
> der LED zu klein ist, kann das zu Problemen führen.
> Hatte ich selber schon beim AVRISP MKII.
> Nach Vergrößerung auf über 3kOhm ging es wieder.

Beim atmega32 gibt es keine Programmierleitungen auf PortD (die sind bei 
PortB...)

Ein LED-Vorwiderstand mit 3k? Bei 5V Versorgung bleibt bei einer 
typischen LED grad mal 1mA.... Das wird nicht sehr hell... ;-)

[Neuling (Gast)]

Eberhard F. schrieb:
> Ds klingt nach einem Masse-Problem das ich schon erlebt habe ....
>
> Wenn der Rechner und das Labor-Netzteil mit ihrer DC-Masse nicht
> auf gleichen Potential sind (aus welchem Grund auch immer)
> können Masseströme den ganzen Aufbau beträchtlich stören.
>
> Dazu müsste man mal die Spannungsdifferenz auf den Massen
> nachmessen (Prozessor im Betrieb und Programmer abgetrennt).
> Da sollten sich keine grossen Spannungen nachweisen lassen
> da die Versorgung ja sehr niederohmig ist.
>
> Ich habe für solche Eventualitäten zum Potentialausgleich ein
> dickes Massekabel vom Rechner zum Testaufbau gelegt .....

Hmm... Ich habe nun das Netzgerät gegen eine 9V Blockbatterie, einen 
7805 und ein paar Kondensatoren getauscht.... Leider immer noch das 
selbe Problem. Am PC liegst übrigens auch nicht, habe es gerade mit 
einem anderen Rechner getestet....

[Marc V. (Firma: Vescomp) (logarithmus)]

Klaus schrieb:
> Ich kann aus dem Atmel Studio mittels ARVISP MKII Programmer einmal
> meinen Controller programmieren.

 Und Atmel Studio ist Version ?

[Loocee L. (loocee)]

Neuling schrieb:
> Leider immer noch das
> selbe Problem.

- ISP Taktfrequenz korrekt niedrig eingestellt ?
Muss weniger als 1/4 des Prozessortaktes sein.

- Prozessortakt nach der Programmierung stabil?
(Oszilloskop an den XTAL-Pins ...)

Clock Selector Fuses richtig gesetzt?

[namlit (Gast)]

Hallo, gibt es inzwischen neue Erkenntnisse zu dem Thema? Ich habe das 
gleiche Problem und würde mich über eine Lösung freuen.

Ich benutzte den mkII mit der Firmware Version 1.17 und Handware Version 
1.
Ich habe die aktuelle Version von Atmel Studio (6.2.1502) installiert.

Ich glaube zwar nicht, dass es da dran liegt, aber das ganze läuft bei 
mir unter Windows XP in einer virtuellen Maschine.

Das Problem habe ich sowohl mit einem Atxmega32A4U, der per PDI 
programmiert wird, als auch mit einem Atmega8, den ich per ISP 
programmiere. Ich würde deswegen Fehler in der Schaltung oder am 
Controller weitestgehend ausschließen.

Am wahrscheinlichsten scheint mir ein Fehler in der Programmer Firmware 
oder Atmel Studio zu sein.

Hat noch wer eine Idee oder kann den Fehler reproduzieren?

[Zennix (Gast)]

Hi,
das Problem kann ich nachvollziehen seit ich auf den neuesten Patchlevel 
von AVR Studio gewechselt bin.
Studio stellt die Programmierfrequenz auf 1MHz, obwohl 125kHz 
eingestellt sind. Das ist ein Programmfehler.

Ich habe mir so beholfen, dass ich das Programm über das Device 
Programming Tool lade, das funktioniert.

Hoffe dass Atmel schnellstens einen Bugfix bringt.

[Neuling (Gast)]

Zennix schrieb:

>
> Ich habe mir so beholfen, dass ich das Programm über das Device
> Programming Tool lade, das funktioniert.
>

Wie genau meinst du das? Genau dort (unter Tools - Device Programming) 
tritt das Problem ja auf.... ?!?

[Charley (Gast)]

Haben wir uns nun auf einen BUG im aktuellen Amtel Studio geeinigt oder 
gibt's hier neue Erkenntnisse? ;-)

Habe hier nämlich exakt das selbe Problem.

[Zennix (Gast)]

Hi,

das Problem taucht bei mir nur dann auf, wenn ich den ISPMKii als 
Programmer auswähle und dann mit F5 bzw ctrl+Alt+F5 das Programm 
erstelle und direkt auf den Chip lade.

Wenn ich nur das Programm bauen lasse ohne es direkt auf den Chip zu 
laden und anschließend über Tools - Device Programming - Memories das 
*.elf file programmiere, gehts.

Ich denke, wir haben es mit einem Bug zu tun.

Grüße / Zennix

[Stefan S. (sschultewolter)]

Gibt es hier zu schon Neues? Ein Update scheint noch nicht gegeben zu 
haben.

Habe das Problem mit einem Attiny841. Am SPI ist nichts angeschlossen 
ausser die ISCP Buchse.

Gespeist wird der Attiny aus 2x1.2V Zellen mit einem hintergeschalteten 
5V Step Up Wandler. Problem ist aufgetreten als ich die Fuse für CKDIV8 
gesetzt haben (8MHz/8). Den ISP habe ich auf 125kHz stehen(sowohl Device 
Programming als auch in der Projekt Properties), bekomme dennoch das 
Problem

Timestamp:  2014-12-16 19:47:47.473
Severity:    ERROR
ComponentId:  20100
StatusCode:  131101
ModuleName:  TCF (TCF command: Device:startSession failed.)

Unexpected signature 0x00000000 (expected 0x001e9315).

Um wieder etwas beschreiben zu können muss ich den Rechner neustarten 
oder den mkii komplett als Gerät deaktivieren und aktivieren. Entferne 
ich danach wieder CKDIV kann ich mit F5 wieder programmieren.

[Daniel S (Gast)]

Hallo,

selbiges Problem auf zwei verschiedenen Rechnern, ebenfalls Atmel Studio 
6.2.

Einmal flashen, danach Devices Busy.

getestet, mit avr isp mkii, avr jtagice 3, sowie mit dem neusten atmel 
jtag.

nervt!

[franka (Gast)]

Es nervt wirklich!

Ich habe das Atmel Studio (AS) und die USB Treiber (extra!)
deinstalliert. Rechner zur Sicherheit neu starten und das AS 6.1 
installiert.

Studio Archive:
http://www.atmel.com/tools/studioarchive.aspx

Der AVRISP MK II hat wieder wie gewohnt funktioniert.
Wer also (zunächst) auf 6.2 verzichten kann...

LG

[Heiner (Gast)]

Mir scheint es gibt zur Zeit keine Lösung. Ich habe das Problem mit 
AVRISP und ebenfalls mit einem anderen Programmiertool, was über STK500 
läuft.
Eine Möglichkeit ohne ständiges umstecken und neustarten ist, eine 
weitere Instanz von AVR-Studio zu starten und dort die Programmierung 
vorzunehmen. Wenn man dann dort das Programmierfenster offen lässt kann 
man per Taskwechsel weiterprogrammieren und ständig im anderen Task 
programmieren.

[David (Gast)]

Hallo zusammen,
habe das selbe Problem bei mir geht es aber wen ich im
"Device Programming" Tool auf "Memories" gehe und von dort aus Brenne

[SirIsaac (Gast)]

Bei mir funktioniert dies auch, wenn man den Mikrocontroller über 
"Memories" programmiert. Jedoch muss hier die HEX-Datei für den Flash 
verwendet werden. Mit der ELF-Datei bleibt das alte Problem vorhanden.

[seppo (Gast)]

Zennix schrieb:
> Studio stellt die Programmierfrequenz auf 1MHz, obwohl 125kHz
> eingestellt sind.

Habe das auch nachvollziehen können, wenn ich die ISP-Clock auf ganz 
langsam drehe gehts...

[OldMan (Gast)]

David schrieb:
> Hallo zusammen,
> habe das selbe Problem bei mir geht es aber wen ich im
> "Device Programming" Tool auf "Memories" gehe und von dort aus Brenne
Der Tipp war sehr gut!
So funktioniert es einwandfrei!