Hallo liebe Gemeinde,
ich versuche mich grad am debuggen des PIC16F1503 mit debug-header
AC244051.
-Programmer PICkit3
-verwendeter Compilerversion XC8 1.44.
-Target Device wird extern mit 5V versorgt
In Anhang die Verbindungen wie ich diese Aufgebaut habe.
-config Bits:
#pragma config FOSC = INTOSC
#pragma config WDTE = OFF
#pragma config PWRTE = OFF
#pragma config MCLRE = ON
#pragma config CP = OFF
#pragma config BOREN = OFF
#pragma config CLKOUTEN = OFF
#pragma config WRT = OFF
#pragma config STVREN = ON
#pragma config BORV = LO
#pragma config LPBOR = OFF
#pragma config LVP = OFF
In der IDE habe ich schon den PICkit3 samt header AC244051 auusgewählt.
Debug Project funktioniert ohne Fehlermeldung, das Programm wird ohne
Fehler compiliert und geflasht und geht in den Debug Mode.
Jetzt mein Problem :(
Augenscheinlich funktioniert das Debuggen, ich kann step by step mich
bewegen, jedoch haben Änderungen an den Hardware I/O´s KEINE
Auswirkungen auf die Register bzw. Variablen oder in der Watchlist.
Gemessen mit einem Oszi gehen auch über den Header AC244051 Signale an
PGC und PGD an den PIC.
Was mich zum grübeln bringt:
Das Target-Device mit dem PIC16f1503 läuft auch schon komplett an, bevor
ich mich in der main-routine vorwärts bewege.
Es kommt mir so vor als fehlt eine Snycronisierung, etc,
Startvector,...??
Theoretisch darf doch mein PIC16f1503 erst dann die Befehle ausführen,
sobald ich mich im Debug-Mode step by step vorwärts bewege.
Ich bedanke mich schon mal im Vorraus.
Ben
X4U schrieb:> Sieht nach Simulation aus. Schau mal ob der Pick it als Debugger> ausgewählt wurde.
Da hast du recht, dachte ich zu erst auch, aber
PICKIT3 ist als Debugger eingestellt inkl. option Debugheader.
Hast Du die Analogfunktionen abgeschaltet? Die sind nach einem Reset
nämlich an.
Ist ein beliebter Anfängerfehler.
Such nach Registern ADCON... im ADC.
fchk
fchk schrieb:> Hast Du die Analogfunktionen abgeschaltet?
Natürlich nicht! Den ADC benötige ich doch, da macht das Abschalten ja
wenig Sinn.
Im Datenblatt steht das PGD und PGC höchste Priorität bei den Pinconfis
haben, demnach auch beim Reset.
Immerhin funktionieren diese Datenleitungen ja auch, sonst könnte ich
keine Verbindung mit dem Debugger herstellen.
Hat eventuell noch jemand Erfahrung beim Debuggen, speziell mit diesem
Debug-Header?
Gruß Ben
Ben K. schrieb:> fchk schrieb:>> Hast Du die Analogfunktionen abgeschaltet?>> Natürlich nicht! Den ADC benötige ich doch, da macht das Abschalten ja> wenig Sinn.
Das musst du für jeden Pin mit den ANSELx-Registern separat einstellen!
> Das musst du für jeden Pin mit den ANSELx-Registern separat einstellen!
Für meine benötigten ADC-Channels habe ich freilich das Register
entsprechend beschrieben.
Und du denkst/hoffst das das der Grund für den Debugfehler ist?
Da ich nicht lernresistend bin, werde das gern morgen mal testen und bin
mal gespannt ob das funktioniert.
Teo D. schrieb:> Meines Wissen nach kann man register nur bei HW-Breakpoints> verändern/lesen!?
Auch das hatte ich schon getestet, ich habe breakpoints gesetzt aber da
ging leider nichts.
Ben K. schrieb:> Auch das hatte ich schon getestet, ich habe breakpoints gesetzt aber da> ging leider nichts.
Vor dem Compilieren gesetzt, sonst sinds SW-BPoints!
Die Anzahl der HW-BPoints ist je nach µC begrenzt.
Hallo zusammen,
ich habe die Vorschläge eurerseits getestet und kann über keinen
positiven Erfolg berichten.
1. Beim ADC habe ich die Peripherie abgeschaltet ADON-Bit = 0
2. ANSELx-Bits alle gelöscht (0x00)
3. Hardware BP vor dem Compilieren gesetzt (es steht hier auch nur einer
zur Verfügung) :(
OK....???
Wo bzw. in welchen Fenstern lässt du das anzeigen und veränderst da
Register.
'Windows>Debugging>xxx' oder eventuell bei 'PICMemorie Views>xxx'?
Sorry ich muss so dämlich fragen, sonst fällt mir nämlich nix mehr ein.
Hallo Teo Derix,
anbei ein Auszug vom Dashboard und Watchlist von den Registern.
Register ändere/schreibe ich nicht per Software beim debuggen, sondern
ändere NUR meine I/O´s am PIC.
Wie gesagt kommt es einen so vor als ob der Simulator läuft.
Ich muss nochmal darauf hinweisen, ich habe 100%ig den Debugger als
PICKIT3 samt Header ausgewählt.
Eventuell ist ja die Hardwarebeschaltung zwischen Header und PIC
falsch??
Viele Grüße
Ben
Ben K. schrieb:> Was mich zum grübeln bringt:> Das Target-Device mit dem PIC16f1503 läuft auch schon komplett an, bevor> ich mich in der main-routine vorwärts bewege.
Woher weißt du das?
Ben K. schrieb:> Theoretisch darf doch mein PIC16f1503 erst dann die Befehle ausführen,> sobald ich mich im Debug-Mode step by step vorwärts bewege
Kommt drauf an, wie das konfiguriert ist. Kann auch sofort los laufen...
Ben K. schrieb:> Register ändere/schreibe ich nicht per Software beim debuggen, sondern> ändere NUR meine I/O´s am PIC.
Das Programm läuft, du änderst einen Input, drückst auf Pause,
oder wie machst du das?
Welchen Input genau?
Wie sieht die Änderung genau aus?
Ben K. schrieb:> Eventuell ist ja die Hardwarebeschaltung zwischen Header und PIC> falsch??
Was steht denn im Output Fenster für das PK?
Wenn da am Ende "running" steht, kann es keine Verbindungsprobleme
geben.
Ben K. schrieb:> 3. Hardware BP vor dem Compilieren gesetzt
Das ist egal, ob vor oder nach dem Compilieren. Das Programm darf nur
nicht laufen, sondern muss angehalten sein.
Teo D. schrieb:> Ben K. schrieb:>> Auch das hatte ich schon getestet, ich habe breakpoints gesetzt aber da>> ging leider nichts.>> Vor dem Compilieren gesetzt, sonst sinds SW-BPoints!> Die Anzahl der HW-BPoints ist je nach µC begrenzt.
Seh ich anders ;-)
Softwarebrakepoints (void __debug_break(void))
muss man vor dem Compilieren setzen,
indem man sie in das Programm schreibt...
Teo D. schrieb:> Habs nur überflogen, event. hilfts ja weiter.> https://www.microchip.com/forums/m658918.aspx
@Teo, danke für den Link.
Der letzte Kommentar beschreibt die Vorgehensweise/Aufbau des Headers,
war zumindest schon mal sehr interessant, zumal sich alle verfügbaren
Datasheets von MC über Headers sehr in Grenzen halten.
Was mich zum grübeln bringt:
Das Target-Device mit dem PIC16f1503 läuft auch schon komplett an,
bevor
ich mich in der main-routine vorwärts bewege.
> Woher weißt du das?>>im MPLABX git es eine Einstellung bei der man den Startpunkt des >>Debuggens
wählen kann. Dies ist ab "MAIN" konfiguriert. Alle Inits der Peripherie werden
nach diesem Punkt ausgeführt(PWM,ADC,...)
>>Da die PWM schon vor Abarbeitung der der Routine läuft, muss der PIC also schon
"weiter", bzw. angelaufen sein.
> Das Programm läuft, du änderst einen Input, drückst auf Pause,> oder wie machst du das?> Welchen Input genau?> Wie sieht die Änderung genau aus?>>>richtig, genauso ist meine aktuelle Vorgehensweise, Änderung des Zustandes an
einem Input(über Hardware), dann "PAUSE". Die Hardware in Verbindung der Firmware
verarbeitet auch alle Befehle ordnungsgemäß, jedoch werden im Debug-Mode diese
Änderungen nicht auf der "PC-Oberfläche"(Watchlist, Variables, Register,...)
dargestellt, bzw. falsch dargestellt, so das man denken könnte, man befindet sich
im SIM-Mode.
> Was steht denn im Output Fenster für das PK?> Wenn da am Ende "running" steht, kann es keine Verbindungsprobleme> geben.>> ja genau, erfolgreiches Programmieren, und Running
Ben K. schrieb:> Was mich zum grübeln bringt:> Das Target-Device mit dem PIC16f1503 läuft auch schon komplett an,> bevor> ich mich in der main-routine vorwärts bewege.
Wenn nicht 'Hold in Reset' aktiviert ist das normal.
Las mal Goockl un Co. außen vor und arbeite dich durch 'PicKit3 Help'
durch, die is es wert!
Wenn die Schriftgröße nich so poplig unter Win wäre :(
Ben K. schrieb:> Änderungen nicht auf der "PC-Oberfläche"(Watchlist, Variables,> Register,...)> dargestellt, bzw. falsch dargestellt, so das man denken könnte, man> befindet sich> im SIM-Mode.
Drück da mal auf 'Reset', event. lauft das asynchron, weil er eben
sofort losläut....
PS: Ich muss mich da auch immer wieder neu anlernen, arbeite damit max
1x im Jahr.... :(
Ben K. schrieb:> Auch das habe ich schon probiert.
Tja, die Hoffnung...
Ich bin dann mal raus. Ende der Fahnenstange. :(
Viel Glück noch beim Suchen.
MfG
Teo
Volker S. schrieb:> Welchen Input genau?> Wie sieht die Änderung genau aus?
<edit>
Ben K. schrieb:> Die Hardware in Verbindung der Firmware> verarbeitet auch alle Befehle ordnungsgemäß, jedoch werden im Debug-Mode> diese Änderungen nich....
Sorry, habe ich überlesen. Es funktioniert also eigentlich alles, nur
PORTX wird im Debugger nicht richtig aktualisiert?
IIRC habe ich so was schon mal gehört. Was passiert, wenn du PORTX in
deiner Hauptschleife einliest? (dummy = PORTX;)?
@Volker
gute Idee,ja das werde ich als easy Step einmal probieren.
Leider komme ich aber erst gegen ende der Woche dazu.
Ich melde mich sobald es neue Erkenntnisse gibt.
Gruß Ben
2.jpeg
(180 KB)
