Forum: Mikrocontroller und Digitale Elektronik PIC18F46K20 + Pickit3 Debuggen geht nicht


von Dirk F. (dirkf)


Lesenswert?

Hallo,
ich weiss nicht mehr weiter.
Habe o.g. PIC am PICKIT3 hängen.
Der u.g. Programmcode läuft problemlos, wenn ich den Chip im Programer 
modus programmiere.  Blinklicht Duo-LED.

Wenn ich aber den Chip im Debug modus brenne, und anschließend im 
Einzelschritt abarbeite, dann gehen die LEDs nicht mehr an und beim 
zweiten mal wenn die while Stelle erreicht wird, kommt eine 
Fehlermeldung.

Wer weiss einen Rat ?

------------------------------------------------
#include <htc.h>

void main(void)
{
TRISD = 0;
LATD0 = 1;
LATD1 = 0;

while (1)    // loop
  {

  LATD0 = 1;
  LATD1 = 0;
   _delay (100000);
  LATD0 = 0;
  LATD1 = 1;
   _delay (100000);

  }    // End loop
}      // End main

von Carsten (Gast)


Lesenswert?

Hi,

Es währe sinnvoll die Fehlermeldung die du erhälst anzugeben - Sonst ist 
das nur eine Rumraterei. Auch ob du "MPLAB 8.??" oder "MPLABX"

Auch Sprichst du nur von "Normal Brennen" und "debug mit Einzelschritt".
Interessant ist aber auch was im Debugmodus passiert wenn du statt 
Einzelschritt einfach auf "Programm Ausführen" gehst. Funktioniert es 
dann wie beim Programmieren im Programming Mode oder auch überhaupt 
nicht?

Und als genereller Hinweisnicht nur im Bezug auf dein Aktuelles Problem.
Der Einzelschrittmodus ist wie der "Verlangsamte Modus" ist NUR dann 
Sinnvoll wenn du die Problematische Stelle halbwegs eingrenzen kannst, 
da Einzelschritt wirklich einzelschritt und nicht Einzelzeile bedeutet.

Bei deinem Code müsstest du daher ab erreichen der Zeile _Delay(1000000) 
mindestens jeden Befehl in der Funktion _Delay einhunderttausendmal 
bestätigen... Ein einmaliges Durchlafen der While Schleife würde damit 
schätzungsweise 1 000 000 Tastenklicks bedeuten. (Es sei denn du 
verwendest das MPLABX und da ist es anders als bei dem von mir noch 
verwendeten MPLAB 8)

Daher setzt man den Einzelschrittmodus normalerweise immer in 
Kombination mit Breakpoints ein. Also Breakpoint kurz vor erreichen der 
"Problematischen" Stelle setzen, normal starten und ab dem Breakpoint 
dann im Einzelschritt weiter.

Gruß
Carsten

AchJa: So sehe ich im Code auf Anhieb nichts verdächtiges, aber ich 
kenne den Inhalt deiner Includes ja nicht...

von Dirk F. (dirkf)


Lesenswert?

HI Carsten,
danke für die Antwort. Ich dachte schon, es gibt keine PICler hier.
Ich benutze MPLAB 8.88 zusammen mit dem HITECH C Compiler.

>>>>Einzelschritt einfach auf "Programm Ausführen"
RUN:  nach ca. 5 sekunden kommt die Meldung : Target halted. LED bleiben 
aus.

Step over:  Wenn das zweite mal die While Stelle erreicht wird, 
Fehlermeldung "Falsche Parameter"

Animate:  Laüft auch bis zum while, bleibt dann stehen.

Und immer tut sich nix an den LEDs !

Wenn ich wie gesagt den Debugger PICKIT3 deaktiviere und den Programmer 
PICKIT3 wähle, läuft alles bestens.

Beschaltung: Wie im Datenblatt Pickit3 angegeben. MCU Versorgung 3.3 V 
extern. Pin2 vom Pickit also nicht verbunden. MCLR über 10 K Pullup an 
+3.3V und auch an Pin 1 Pickit3.

Das Include ist der Standard von HITECH.

Gruss Dirk

von Carsten (Gast)


Lesenswert?

Hi,

also PICler gibt es hier schon einige ;-)

Also die Meldungen des MPLAB passen zu den Fehlermeldungen die ich 
erhalte wenn irgendetwas in der Kommunikation zwichen PIC (bzw. PICKIT) 
und dem PC schiefläuft. Im Debugmodus ist die ja deutlich 
Empfindlicher...

VERBINDE MAL PIN2 des PK3 mit Vdd!
Der Pin dient nicht nur zur Versorgung der Schaltung sondern auch zur 
Spannungsdetektion um die Programmierspannung an die Betriebsspannung 
anzupassen! Ich hatte schon mal damit zu kämpfen bis ich herausfand das 
die Lötstelle am Pin2 der ICSP-Stiftleiste kalt war...
Allerdings lief da mir gar nichts!

Ansonsten weiß ich mir da leider auch keinen Rat, der Code sieht 
zumindest soweit ich das beurteilen kann OK aus - Allerdings habe ich 
schon EWIGKEITEN nicht mehr mit HI-TECH Compiler gearbeitet. Die 16er 
habe ich immer in ASM Programmiert, da war der HI-Tech nur mal spielerei 
zum Ausprobieren...
Und Beruflich habe ich dann direkt mit dem Microchip C Compiler 
losgelegt.

Der HiTech Compiler ist aber auch obsolet, ich könnte mir daher auch 
vorstellen das sich da vielleicht bei MPLAB ein Bug eingeschlichen hat 
der beim Debug Probleme macht, kann ja auch auf nur wenige µC beschränkt 
sein und ist deshlab noch nicht weiter aufgefallen...
Oder die interne DEBUG Hardware des PICs selber hat einen Schuss - den 
Fall hatte ich auch schon mal... Da lief die normale Programmierung 
sauber, nur Debuggen wollte der nicht. nach längerem Suchen in der 
Software einfach ratlos mal den nächsten aus der Stange genommen und 
plötzlich lief es - Wie gesagt, aus derselben Stange direkt vom Distri!

Die "warnmeldungen" des Compilers wirst du ja wohl nicht abgestellt 
haben, oder? Nicht das deine Fuseeinstellungen nicht Debugkompatibel 
sind und die Warnung nur nicht angezeigt wird. (Normalerweise warnt 
MPLAB dann und bietet das temporäre Ändern an). Insbesondere der 
LEseschutz verhindert Debuggen, je nach Pic auch noch weiteres.

Wenn nicht jemand anderes noch eine gute Idee hat bliebe es nur beim 
Eingrenzen des Fehlers...
Also vorrausgesetzt die Möglichkeiten bestehen mal testweise jeweils ein 
Element tauschen. Je nachdem was dir möglich ist. (anderer PC, anderer 
PIC und ggf. auch mal sehen was mit dem Microchip C Compiler passiert)

Gruß
Carsten

von Dirk F. (dirkf)


Lesenswert?

Hallo Charsten,
habe den Chip geauscht. Leider keine  Verbesserung.
Warnmeldunge von falöschen Config Bits setting kommen auch, wenn die 
falsch stehen.
Pin 2 vom Pickit an die +VDD verbunden, keine verbesserung.

Jetzt hab ich den Compileroptimierungen mal rumgespielt, jetzt geht gar 
nichts mehr im Debug Modus.

Im Programmiermudus immer noch alles gut.

Kommt der Debugger mit dem internen Taktgeneratur nicht zurecht ?

Gruß dirk

von Carsten (Gast)


Lesenswert?

Dirk F. schrieb:
> Kommt der Debugger mit dem internen Taktgeneratur nicht zurecht ?

Kann ich mir nicht vorstellen, den verwende ich auch häufig wenn ein 
genauer Takt nicht notwendig ist...

Lade doch einfach mal den Microchip C18 (die freie LiteVersion oder halt 
die Evalversion - nur bei der Evalversion kommt dann nach 60Tagen beim 
immer der nervende Hinweis, funktioniert aber trotzdem bis Ultimo mit 
geringerer Optimierung) runter und probiere ob Debuggen mit diesem geht.

Die beiden Compiler können ja parallel Installiert sein, musst nur 
jeweils in MPLAB Umstellen welcher verwendet werden soll. Allerdings 
muss dein code dann etwas angepasst werden.

Läuft es mit dem C18 ist es ein Softwareproblem und du kannst dann 
entweder beim C18 bleiben oder schaust mal ob mit einer älteren MPLAB 
version der Fehler dann nicht mehr auftritt bei verwendung des HiTech 
Compilers.
(zwei verschiedene MPLAB Versionen parallel Installiert zu ahben ist 
deutlich umständlicher als nur zwei Compiler - deshalb der Test auf SW 
Probleme über den Umweg C18 anstelle bunt drauf Los jetzt verschiedene 
MPLAB vversionen zu Installieren und wieder deinstallieren...)

Allerdings musst du beim C18 deinen Code anpassen, aber noch ist das 
Projekt ja klein ;-)

Gruß
Carsten

von Dirk F. (dirkf)


Lesenswert?

Hallo Carsten,
also ich hab auch son MPLABX installiert.
Werde es damit und dem anderen Compiler mal versuchen, sage dann 
Bescheid über das Ergebnis.

Aber noch ne Frage an den Experten :
Ich komme aus der SPS Welt. Da geht man halt zur Steuerung online und 
sieht sich im normalen Betrieb gewisser Werte an.

So eine Funktion habe ich bisher zumindest im alten MPLAB immer 
vermisst:

1.  Programm laufen lassen in Echtzeit bis zu einem Breakpoint
2.  Update des Watch Windows mit neuen Werten.
3.  Automatisch weiterlaufen lassen, 1 Programmzyklus bis er wieder zum 
selben Breakpoint kommt.

Geht so etwas mit MPLABX ?

von Carsten (Gast)


Lesenswert?

Dirk F. schrieb:
> Geht so etwas mit MPLABX ?

Also ich bin gerade erst dabei mich mit dem MPLABX 
auseinanderzusetzen...
Als Produktivarbeit mache ich noch mit dem MPLAB8 bis ich in X wirklich 
Fit bin.

So eine Funktion gibt es natürlich!

Unter MPLAB 8 ist das Fenster unter VIEW -> WATCH zu finden.
Dann öffnet sich ein Fenster wo du auswählen musst welche Register du 
überwachen willst.

Ich glaube bei MPLABX ist das Fenster über DEBUG -> NEW WATCH, dann 
Auswahl des Registers, zu finden.

Gruß
Carsten

von Dirk F. (dirkf)


Lesenswert?

Hallo C.
Ja das ist klar.
Aber die Funktion, dass der Chip immer zyklisch mit voller 
Geschwindigkeit läuft, und nur einmal im Zyklus kurz anhält, die Daten 
über den Pickit3 zum PC schaufelt, und dann weiter läuft.

Bisher ist es im Debugger modus so, dass beim Erreichen des Breakpoints 
dann das Watchwindow geupdated wird, aber dann muss man mmer wieder 
einen Mausklick machen,  damit die Kiste weiterrennt.

Ich weiss nicht, ob klar geworden ist, weche Funktion ich meine.
Also die Schaltung läuft ganz normal, und irgendwo in einem fenster kann 
man hat eine  Varriable beobachten.
LG Dirk

von Stefan (Gast)


Lesenswert?

Im Debugmodus soll ja nur überprüft
werden ob ein bestimmter Wert oder Funktion,
richtig läuft.
Wenn man kontinuierlich was überwachen will,
dann kann man sich das per UART oder USB zum
PC senden lassen und dort in Echtzeit anschauen,
ohne das das laufende Programm unterbrochen wird.

von Carsten (Gast)


Lesenswert?

Dirk F. schrieb:
> Ich weiss nicht, ob klar geworden ist, weche Funktion ich meine.
> Also die Schaltung läuft ganz normal, und irgendwo in einem fenster kann
> man hat eine  Varriable beobachten.

Ach so, das meinst du!
Also was es gibt die wirkliche Überwachung in Echtzeit! Allerdings 
bietet diese Funktion nur der Emulator!

Die Debugger können nur während der PIC hält die Registerwerte auslesen.
Natürlich würde hier das von dir geschilderte Prinzip auch 
funktionieren, im Prinzip geht es ja nur um einen "automatisierten" 
Mausclick zum wiederstarten. Technisch kein Problem (Ist halt keine 
wirkliche Echtzeit mehr) ICh wüsste allerdings nicht das so eine 
Funktion Implementiert ist. Bei MPLAB 8 sicher nicht - bei MPLABX 
vermutlich nicht.

Gruß
Carsten

von Dirk F. (dirkf)


Lesenswert?

Hallo zusammen,
ja danke für die bisherigen Antworten.

Bin mit MPLABX auch nicht so richtig weiter gekommen. Habe jetzt erst 
gemerkt, das sman bei MPLABX die Config Bits im Code definieren muss. 
Die Änderungen im Config Fenster sind nur als Hilfestellung zur 
Erzeugung des Codes für Config Setting gedacht.

Jetzt hat er folgende Probleme (mit dem HITECH C18) :

HI-TECH C PRO for the PIC18 MCU Family (Lite)  V9.63PL3
Copyright (C) 1984-2009 HI-TECH SOFTWARE
Serial number: xxxxxxxxxxxxx
make[2]: *** [dist/default/production/MPX-Projekt.X.production.hex] 
Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
C:\DOKUME~1\Dirk\LOKALE~1\Temp\s1vs.:256: error: undefined symbol 
"EBTR3_OFF"
C:\DOKUME~1\Dirk\LOKALE~1\Temp\s1vs.:256: error: undefined symbol 
"EBTR2_OFF"
C:\DOKUME~1\Dirk\LOKALE~1\Temp\s1vs.:256: error: undefined symbol 
"EBTR1_OFF"
C:\DOKUME~1\Dirk\LOKALE~1\Temp\s1vs.:256: error: undefined symbol 
"EBTR0_OFF"

von Dirk F. (dirkf)


Lesenswert?

Hi zusammen,
also ich hab es jetzt zum laufen (debuggen) bekommen.
MPLABX  + XC8 Compiler. Config Bits im Code.

Nochmals Danke. Gruss Dirk

Bitte 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
Noch kein Account? Hier anmelden.