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
Sieht nach Simulation aus. Schau mal ob der Pick it als Debugger ausgewählt wurde.
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.
Meines Wissen nach kann man register nur bei HW-Breakpoints verändern/lesen!?
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.
:
Bearbeitet durch User
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.... :(
Drück da mal auf 'Reset', event. lauft das asynchron, weil er eben sofort losläuft Auch das habe ich schon probiert.
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;)?
:
Bearbeitet durch User
@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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.