Hi,
ich experimentiere gerade etwas mit dem PIC16F1936 und habe mir zwecks
dessen zehn dieser Chips und ein original (auf Rat des Forums kein
CLONE!) gekauft.
Beides betreibe ich mit der MPLAB X IDE.
Im Normalfall sieht das dann so aus:
1
ConnectingtoMPLABPICkit3...
2
FirmwareSuiteVersion.....01.28.57
3
Firmwaretype..............EnhancedMidrange
4
5
Targetdetected
6
DeviceIDRevision=8
7
8
Thefollowingmemoryarea(s)willbeprogrammed:
9
programmemory:startaddress=0x0,endaddress=0xfff
10
11
Programming...
12
Programming/Verifycomplete
Nur es kommt immer häufiger nach
Programming...
Programming FAILED
Dabei ändere ich zum Erfolg NICHTS, sondern drücke immer nur erneut auf
"Make and Programm Device"
Daher frage ich mich nun, ob der Chip vielleicht defekt ist?
Wenn ja, wie habe ich das geschafft (Flashe immer mit 5V und auf einem
kleinen Sockel mit 4K7 und sonst nichts. (Kein LVP)
Oder gibt es vielleicht bekannte Macken des Pickit 3 und ich sollte es:
A Zurückschicken
B abkühlen lassen (lol)
Grüße Oekel
D a v i d K. schrieb:> Wenn ja, wie habe ich das geschafft (Flashe immer mit 5V und auf einem> kleinen Sockel mit 4K7 und sonst nichts. (Kein LVP)
Auch keine Kondensatoren von Vcc nach GND?
Seht her. Das ist eine 20Pin Fassung, die für den 28DIP genau ausreicht.
Kabel sind definitiv sehr kurz. Und Kurzschlüsse durch optische
Kontrolle ausgeschlossen.
Das einzige, was ich noch ausprobieren könnte, wäre PIN 8(GND) noch mit
dem PIN 19 (GND und am Pickit3 angeschlossen) zu verbinden.
Jedoch kann ich mir keinen Vorteil dadurch denken.
4K7 habe ich gerade noch Mal nachgemessen. Streut etwas nach unten 4K6.
Habt ihr noch eine Idee?
Grüße Oekel
1. Alle GND verbinden (der 2. GND wird schon seine Berechtigung haben)
2. 100nF zwischen Vss und Vdd
Wahrscheinlich der Grund warum die Programmierung nur sporadisch
gelingt.
Und noch zusätzlich die blauen Kabel entzwirbeln.
Durch das Verzwirbeln rufst du ein Übersprechen auf die Taktleitung
hervor. Lege beide parallel, mit einem Abstand zwischen beiden.
Nee,
sorry für den Kraftausdruck, aber die IDEs MPLAB und MPLAB X sind der
letzte DRECK!
Hab jetzt das Scriptprogramm runtergeladen, welches beim Pickit 3 mit
angeboten wird und es funktioniert!
Und dazu noch rasend schnell.
Dummerweise muss man als erstes über den Bootloader einer alternative
Software auf den Pickit 3 spielen, so dass die IDE nicht mehr
unterstützt wird.
Alles sehr sehr seltsam, da wir ja immerhin von Produkten aus erster
Quelle reden.
Kann mir daher vielleicht noch Jemand eine IDE mit Hand und FUß
empfehlen, die am besten den Pickit 3 incl. Debugmöglichkeiten bietet?
Grüße Oekel
PS: 100nF und zweiter GND schaden zwar nicht, aber es geht auch ohne ;)
Ich nutze MPLAB mit dem Pic-Kit 3 vollkommen ohne jegliche Probleme,
läuft stabil und schnell.
Also wenn du Hardwareseitig die drei Dinge behoben hast (GND,
Kondensator und vor allem die Kabel entzwirbelt!!! da ein twisted-pair
hier, ohne differentielle Signale, keinen Nutzen hat, eher das Gegenteil
bewirkt) und es funktioniert nicht sollte es ein Benutzerfehler von
MPLAB sein, denn MPLAB nutzt auch nur das 'Scriptprogramm'.
Failed to get Device ID hatte ich nur, wenn der Anschluss nicht sauber
war, sollte aber, sofern du alles behoben hattest, bei dir nicht mehr
das Problem sein.
Unter MPLAB kannst du Einstellungen vom PIC-Kit, entweder verwendet als
Debugger oder als Programmer (funktioniert es in beiden Modi nicht?
Schließlich hast du es mit dem Script nur noch als Programmer verwendet
und in MPLAB vermutlich als Debugger) vornehemen, vielleicht hast du
dort etwas falsch eingestellt.
Muss ich wohl noch Mal testen. Jedenfalls tut sich in MPLAB "X"
garnichts.
Angenommen ich bekomme es als Debugger zum laufen, kann ich dann in
echtzeit debuggen? Denn ich habe momentan starke Problemme den UART
richtig zum laufen zu bringen und dessen Baud ist ja von der FOSC
abhängig. Sprich wenn das ganze nicht schnell genug läuft verfälscht es
mir doch die Timings, oder sehe ich da etwas falsch?
Grüße Oekel
Nein, du kannst nicht in Echtzeit Debuggen.
Du wirst Stop-Marken setzen können an der der Code angehalten wird, dann
kannst du dir die Variablen, Register, Ports, ... Inhalte im Watch
Window ausgeben lassen und den Code schrittweise weiter ausführen lassen
um zu sehen ob er das macht was du willst.
Bedeutet du kannst im Interrupt eine Stop-Marke setzen um zu sehen ob
der Interrupt übehaupt ausgeführt wird wie geplant, den UART
Eingangsbuffer dir anzeigen lasse um zu sehen was überhaupt ankommt, ...
Aber in Echtzeit läuft das dann nicht mehr.
Moin Oekel,
ich find das mit dem gesockelten rumgelöte irgendwie unschön, ich würde
dir einfach mal ein Breadboard empfehlen.
Ist auch übersichtlicher!
Die 100nF an beiden Vss/Vdd ist kein "kann man mal machen" sondern eher
ein sollte unbedingt dran sein! Bei mir ein Grund warum ich mit USB
nicht glücklich wurde...man lernt nie aus...
Der Vdd Pin sollte mit dem Vdd auf der anderen Seite des ICs verbunden
sein, genau wie der Vss mit dem Vss auf der andern Seite.
Gruß
Andi
D a v i d K. schrieb:> Denn ich habe momentan starke Problemme den UART>> richtig zum laufen zu bringen und dessen Baud ist ja von der FOSC>> abhängig. Sprich wenn das ganze nicht schnell genug läuft verfälscht es>> mir doch die Timings, oder sehe ich da etwas falsch?
Egal ob zu schnell oder zu langsam:
Wenn du bei der UART Timingprobleme hast, dann hilft dir der Debugger
nix weil durch diesen der interne Oszillator dadurch nicht genauer wird.
Denn der wird das Problem sein, vor allem wenn du (wenn ich mich recht
erinnere) 250 kBaud machen möchtest.
Also PIC mit Quarz betreiben und als Minimalanforderung auf einem
Breadboard und nicht so eine "28-Pin-Controller in
20-Pin-Sockel"-Lösung;-)
D a v i d K. schrieb:> sorry für den Kraftausdruck, aber die IDEs MPLAB und MPLAB X sind der> letzte DRECK
Man gut, dass in solchen Fällen das Problem meist der DAU ist.
Ich arbeite jetzt mittlerweile schon ein paar Jährchen mit der IDE und
bin eigentlich recht zufrieden. Nur weil bei dir mal Probleme auftauchen
soll es jetzt der letzte Dreck sein? Naja.. Es steht dir ja frei zu
wechseln :)
Teo schrieb:> Leute,> Oekel musste doch nur ma Dampf ablassen.>> D a v i d K. schrieb:>> Muss ich wohl noch Mal testen. Jedenfalls tut sich in MPLAB "X">> garnichts.
Danke, so ist es! Wobei die "X" wirklich nicht der Hit zu sein scheint
und die ohne wohl ein paar Stunden Einarbeitungszeit benötigt.
Folgendes ist bereits unterwegs:
http://www.ebay.de/itm/Universal-Programmer-Development-Board-for-Microchip-PICkit-2-PICkit-3-/230860495455?pt=Wissenschaftliche_Ger%C3%A4te&hash=item35c05b9a5f
Ich denke, da ein Klemmsocke bereits 3€ kostet und dort mehrerer drauf
sind, kann man den Preis verkraften.
Was mir jedoch zum Thema Debuggen und Baudrate noch nicht so recht in
den Kopf will ist folgendes.
Der Code läuft bis zum Break-Point, und zum nächsten usw.
Dass ich durch diese Unterbrechung den "Echtzeitprozess" störe ist mir
klar.
Doch damit ein WORD auf der Datenleitung richtig erkannt wird muss die
Abtastrate doch auch richtig sein (Baud).
Ich weiß z.B. dass der ISR für den RX pin ausgelöst wird, da ich eine
LED aufleuchten lasse.
(Aber das ist besser ein Thread für sich...)
Kann mir an dieser Stelle noch Jemand sagen, wie ich das Pickit 3 wieder
mit der richtigen FW für MPLAB versorge?
Also woher beziehen und mit welchem Tool aufspielen?
Das Script-Tool hatte einen Button für die "eine" Richtung über
Bootloader. Ein entsprechendes Menü für die "andere/originale" FW konnte
ich bislang nicht entdecken.
Grüße Oekel
D a v i d K. schrieb:> Der Code läuft bis zum Break-Point, und zum nächsten usw.>> Dass ich durch diese Unterbrechung den "Echtzeitprozess" störe ist mir>> klar.>> Doch damit ein WORD auf der Datenleitung richtig erkannt wird muss die>> Abtastrate doch auch richtig sein (Baud).>> Ich weiß z.B. dass der ISR für den RX pin ausgelöst wird, da ich eine>> LED aufleuchten lasse.
Ein Breakpoint ändert an der Baudratenerzeugung des UART-Blockes nichts!
Es gibt für Controllertakt und Baudratentakt einen gemeinesamen
Oszillatorblock (meistens) - das war es dann schon. Eine laufender
Datentransfer via UART wird weiter abgearbeitet.
Ausserdem:
Beim Erreichene eines Breakpoints wird ja der Takt nicht angehalten und
das Programm bleibt auf der Adresse stehen, sondern verzweigt zu einer
beim Flashen mit übertragenen Routine welche eine Verbindung mit der
Debuggingsoftware am PC via PGC/PGD Leitungten ermöglicht.
Wie sollte es sonst auch möglich sein sich Register und RAM anzeigen zu
lassen!?
Klar, dein UART verbleibt im letzten Zusstnd: Senderegister leer bzw.
Empfangsregister voll ....aber such dir mal die Informationen darüber,
gibt glaube ich hier im Forum auch einen Beitrag über Debugging -
wahrscheinlich für AVR, aber am Prinzip ändert das nix.
D a v i d K. schrieb:> Kann mir an dieser Stelle noch Jemand sagen, wie ich das Pickit 3 wieder>> mit der richtigen FW für MPLAB versorge?>>>> Also woher beziehen und mit welchem Tool aufspielen?>> Das Script-Tool hatte einen Button für die "eine" Richtung über>> Bootloader. Ein entsprechendes Menü für die "andere/originale" FW konnte>> ich bislang nicht entdecken.
Unter MPLAB Programmer ->> Download OS.
Ich habe es noch nie probiert von MPLAB --> Scriptingtool ->> MPLAB....
Aber der PicKit wird wegen der Verwendung mit dem Scriptingtoll sicher
nicht kaputt sein.
Womöglich wird sogar automatisch bei der Auswahl des PicKit3 in
Verbindung mit dem eingstellten Controller die passende Firmware
nachgeladen.
Ausprobieren und Manual lesen!!!! Hier hat keiner 100e Seiten
MPLAB/PICKIT/MPLABX Manuals im Kopf....
Frank M. schrieb:> Ich nutze MPLAB mit dem Pic-Kit 3 vollkommen ohne jegliche Probleme,> läuft stabil und schnell.
Bei mir machen die auch keine Probleme. 8Bitter & 32Bitter laufen
absolut störungsfrei.
@TE: Was hast Du denn am !MCLR Pin noch alles dran ?
Microchip weisst regelmässig darauf hin, dass zu große C's im RC glied,
das man evtl. für den Reset benutzt, zu Problemen bei ICSP führen
können.
Würde auf das beschriebene Fehlerbild passen, oder ?
Grüße
Andreas
Nach dem ich nun doch einige Stunden mit der IDE und dem PICKIT 3
gearbeitet habe, möchte ich noch 2 Dinge für die User nach mir
hinterlassen.
Leider kann ich nicht bestimmt sagen, ob es ein Pickit 3 Problem ist
oder mit der IDE X 1.7 und der dort hinterlegten Treiberlösung zu tun
hat.
Doch ich habe 2 Lösungen, die in meinem Fall immer funktioniert haben.
==============================================================
FLASHEN: geht nicht!
Abhilfe:
Immer mit externer Stromversorgung auf dem Board und PICKIT VOLTAGE =
OFF
==============================================================
DEBUGEN: Nach unbestimmter Zeit Springt die IDE im laufenden Debugging
nicht mehr an die BREAKPOINTS, selbst wenn diese in der main gesetzt
werden.
(Target = pause und Target = play wurde natürlich beachtet)
Abhilfe: IDE neu starten, jedoch vorher ALLE Dateien des Projekts
schließen!
(Vermutlich ließt die IDE erst beim erneuten öffnen des Projekts+Datei
die Punkte wieder ein.)
Grüße Oekel