Hallo, ist jemandem von euch schon einmal die Problematik bekannt geworden, dass das Debuggen mit dem PICkit3 nicht möglich ist. Ich kann zwar in der MPLAB X IDE Breakpoints setzen (diese sind beim PICkit3 auf eine Zahl von 2 limitiert). Ich habe hier einen Clone des PICkit3 und und auch einen originalen.... bei beiden tritt das Problem auf.. Ich versuche einen PIC16LF1527 zu debuggen MPLAB X habe ich sowohl in der Version 3.35 und Version 5.05 auf einem Windows 10 64Bit System ausprobiert. In beiden Fällen gibt es ausschließlich broken breakpoints. das betrifft ein umfrangreiches Projekt also auch ein Projekt, das da nur eine "leere main.c" enthält! Ich habe gelesen, dass dieses Problem beim PICkit3 durch einfügen von "NOP" behoben bzw. als workaround umgangen werden kann? Ist dieses Problem auch mit dem ICD3 bzw. dem PICkit4 bekannt? Oder tritt das bei einem dieser Debugger nicht auf? VG
Also ich kenne das Problem von daher, wenn der Code nicht mit dem Inhalt des PIC übereinstimmt. In dem Fall bekomme ich diese "broken" Breakpoints. Beim PICkit4 gibt es das gleiche "Problem". das Problem scheint es aber häufiger zu geben. Ich empfehle daher einen Blick ins Microchip-Forum. Beispiel: https://www.microchip.com/forums/m1021613.aspx?high=breakpoint+broken https://www.microchip.com/forums/m1005227.aspx?high=breakpoint+broken Such auch dor mal nach "broken Breakpoints". Ich empfehle sowieso dort zu fragen, wenn du englisch kannst. Mir wurde schon ziemlich kompetent geholfen. Du hast hoffentlich die aktuellste IDE? Hast du die Compileroptimierungen eingeschaltet?
Gerd. L. schrieb: > Ich kann zwar in der MPLAB X IDE Breakpoints setzen (diese sind beim > PICkit3 auf eine Zahl von 2 limitiert). Die Anzahl der Breakponts richtet sich nach dem Prozessor. Da der Code ja aus dem Flash läuft braucht der Prozessor dazu extra Hardware und da gibt es Grenzen. Broken Breakpoints kenne ich nur, wenn einer Zeile C-Code keine physikalische Adresse zugeordnet werden kann. Einfachster Fall ist, der Code im Codefenster wurde geändert aber im µC ist noch die vorige Version. Oder der Optimizer hat alles durcheinandergewirbelt. Da mach ich dann gerne ein NOP() rein. Das ist volatile und die Adresse findet der Debugger leicht. MfG Klaus
Ein Problem kann es auch geben, wenn der Pfad zu deinem Projekt ein Neztwerkpfad ist, oder auch wenn er Leerzeichen, Umlaute, etc. enthält. Ist für den Compiler evtl. kein Problem, aber der Debugger zickt dann. Bekommst du eine dementsprechende Warnung beim Laden/Öffnen des Projekts?
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.