Warum muss ich den Microchip ICD3 nach jeder Programmierung trennen und wieder anschließen?

Ich habe ein Problem mit dem Programmiergerät Microchip ICD3.

Ich bekomme Verbindungsprobleme beim Herstellen einer Verbindung zum Programmiergerät selbst, selbst wenn ich den Selbsttestmodus mit der von Microchip bereitgestellten Selbsttest-Hardwarekarte verwende.

Nachdem ich den ICD3 an meinen Laptop angeschlossen habe, funktioniert er immer, wenn ich den Selbsttest zum ersten Mal durchführe.

Beim zweiten Mal bekomme ich diese Fehlermeldung:

„Konnte keine Verbindung zum ausgewählten Hardware-Tool herstellen. Bitte stellen Sie sicher, dass das Tool nicht von einem anderen Projekt in MPLAB X verwendet wird.“

Wenn ich den ICD3 vom Laptop trenne und wieder stecke, funktioniert es wieder einmal.

Ich verwende Linux Mint Qiana. Ich habe es in Windows 7 ausprobiert, und dort funktioniert es jedes Mal zuverlässig. Ich habe es auch in Debian Jessie versucht, und dort scheitert es wie in Linux Mint Qiana. Ich habe es auch auf Redhat Fedora Core 22 ausprobiert, und dort hängt sich der Computer am Ende der MPLabX-Installation auf (Bildschirm wird schwarz, Computer reagiert nicht mehr).

Ich habe MPLabX Version v3.05 verwendet (ich habe es auch mit Version 2.x-irgendwas versucht, aber es schlägt auf die gleiche Weise mit einer etwas anderen Fehlermeldung fehl).

Das Obige beseitigt also die folgenden Ursachen:

  • Mein PIC-Programm/PIC (da es nicht einmal beteiligt ist)
  • Meine ICD3-Hardware (da sie unter Windows funktioniert)

Das Problem muss also in meiner Linux-Installation liegen. Ich gehe davon aus, dass Microchip als großes und qualitätsbewusstes Unternehmen seine Software vor der Veröffentlichung testen muss. Ich gehe also davon aus, dass der ICD3 einmal für einen Microchip-Mitarbeiter funktioniert hat. Meine Frage ist also im Grunde, welche Linux-Distribution sie verwendet haben, und was unterscheidet sich zwischen dieser und meiner, sodass meine nicht funktioniert?

Haben Sie den Microchip-Support kontaktiert oder in den Microchip-Foren nachgefragt ?
Nein, vielleicht ist das ein besserer Anfang.
Wie Sie sagen, "Microchip ist ein großes und qualitätsbewusstes Unternehmen" , war der telefonische Support von Microchip meiner begrenzten Erfahrung nach, als ich ähnliche Probleme mit einem PICKit3 hatte, schnell und effizient.
Microchip kontaktierte mich mit einigen Folgefragen und Ideen zum Ausprobieren! Ich bin bisher sehr zufrieden mit ihrer Unterstützung.

Antworten (4)

Derzeit möchten Sie bei 2.15 bleiben, wenn Sie möchten, dass Ihr Debugger unter Linux funktioniert. Der USB-Treiber war vor dieser Version fehlerhaft, dann wurde er von MC behoben und dann rückgängig gemacht. Es funktioniert definitiv auf 64-Bit-Jessie mit 32-Bit-Bibliotheken, an zwei Stellen, die mir bekannt sind.

Bekommst du das gleiche Problem wie ich, wenn du MPLabX 3.x ausprobierst?
Ich versuche im Moment nichts - meiner nicht ganz so bescheidenen Meinung nach ist das eine dumme Sache. Ein Kollege hat ein offenes Ticket mit MC und hilft ihnen beim Testen (er ist mehr Unix-Person als EE). Im Gegenzug sollen sie ihn auf eine stabile Version hinweisen, sobald diese verfügbar ist.
Was ich fragen wollte war, ob du das gleiche Problem hast. Ich nehme an, dass die von Ihnen erwähnte Unix-Person das tut? Vielleicht warte ich dann einfach ab.
AFAIK es begann mit der Version nach 2.15. Ich habe nur 2.20 und 2.30 versucht, sie zeigten den Debugger, gaben aber einen Fehler aus, sobald ich versuchte, ihn zu verwenden.

Ich habe das Problem nicht wirklich gelöst, aber ich habe eine ziemlich hässliche Problemumgehung gefunden, die kaum besser ist als nichts.

Ich habe das folgende Python-Skript geschrieben, um den USB-Port zurückzusetzen. Dadurch funktioniert der ICD 3 wieder, wenn er nicht mehr funktioniert, ohne ihn aus- und wieder einstecken zu müssen.

import os
import sys
import fcntl
import re
lsusb=os.popen("lsusb -d 04d8:9009").read().strip()
if not lsusb:
    print "No ICD3 seems to be connected."
    sys.exit(0)
bus,busid,device,deviceid=re.split(r'[\t :]',lsusb)[:4]
if bus.lower()!="bus" or device.lower()!="device": raise Exception("Unexpected output from lsusb command. Maybe it doesn't work as is expected by this program, any longer")
dev="/dev/bus/usb/%s/%s"%(busid,deviceid)
print "Resetting USB ICD3 device at",dev
fd=os.open(dev,os.O_WRONLY)
USBDEVFS_RESET = ord('U') << (4*2) | 20 
fcntl.ioctl(fd,USBDEVFS_RESET,0)
os.close(fd)

Stackexchange ist nicht das optimale Format, um Python-Programme bereitzustellen, aber ich glaube, das Obige in eine Datei namens fixicd3.py zu kopieren und einzufügen und es dann auszuführen mit:

python fixicd3.py

wird funktionieren. Dies gilt nur für Linux und funktioniert möglicherweise nicht mit USB-Hubs (ich habe es nicht versucht). Außerdem ist das Programm ein vollständiger und absoluter Hack.

Das Hinzufügen des obigen Skripts als "Run after build"-Befehl in MPLabX funktioniert fast ok für die Programmierung des Boards. Beim Debuggen löst es das Problem jedoch nicht, da das Zurücksetzen des USB-Geräts bei einem Verbindungsverlust während einer Debugging-Sitzung nichts nützt (Sie können dann nicht mit derselben Debugging-Sitzung fortfahren).

Es gibt eine Einstellung in MPLabX:

„Aktive Verbindung zum Hardware-Tool aufrechterhalten“ unter Tools->Optionen->Embedded->Allgemeine Einstellungen

Wenn Sie dieses Kontrollkästchen aktivieren, wird das Problem behoben.

Gelegentlich bekomme ich das in der MPLAB-IDE-Konsole in Ubuntu. Es ist irreführend, weil es Ihnen sagt, dass das Problem auf der Zieltafel liegt. Es ist nicht. Es ist ein Berechtigungsproblem mit dem USB-Treiber.

Transmission on endpoint 2 failed
The target circuit may require more power than 
the debug tool can provide. An external power 
supply might be necessary.
Connection Failed.
If the problem persists, please disconnect and 
reconnect the ICD 3 to the USB cable. If this 
does not fix the problem verify that the proper 
MPLAB X USB drivers have been installed.

Dies behebt es.

$ cd /dev/bus/usb
$ sudo chmod 777 *