debugging PIC16F1503 Release Step2

[Ben K. (keller_ben)]

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

[kyrk.5 (Gast)]

MPLAB oder MPLABX?

[Ben K. (keller_ben)]

kyrk.5 schrieb:
> MPLAB oder MPLABX?

MPLAB X IDE v4.05

[X4U (Gast)]

Sieht nach Simulation aus. Schau mal ob der Pick it als Debugger 
ausgewählt wurde.

[Ben K. (keller_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.

[fchk (Gast)]

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

[Ben K. (keller_ben)]

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

[Lars R. (larsr)]

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!

[Ben K. (keller_ben)]

> 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. (teoderix)]

Meines Wissen nach kann man register nur bei HW-Breakpoints 
verändern/lesen!?

[Ben K. (keller_ben)]

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.

[Teo D. (teoderix)]

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.

[Ben K. (keller_ben)]

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) :(

[Teo D. (teoderix)]

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.

[Ben K. (keller_ben)]

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

[Teo D. (teoderix)]

Habs nur überflogen, event. hilfts ja weiter.
https://www.microchip.com/forums/m658918.aspx

[Volker S. (vloki)]

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.

[Volker S. (vloki)]

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...

[Ben K. (keller_ben)]

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.

[Ben K. (keller_ben)]

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

[Teo D. (teoderix)]

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. (keller_ben)]

Drück da mal auf 'Reset', event. lauft das asynchron, weil er eben
sofort losläuft

Auch das habe ich schon probiert.

[Teo D. (teoderix)]

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. (vloki)]

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;)?

[Ben K. (keller_ben)]

@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