PIC18F: Programm läuft nicht an - wegen Debug-Build?

[André H. (andrekr)]

Hi,

in einer Schaltung habe ich zwei PIC18F4620 die ich abwechselnd mit dem 
PICkit3 verbinde. Das Programm mache ich mit MPLAB und dem C18-Compiler.

Wenn ich je ein Programm mache, es im Programmer-Modus in den Controller 
schreibe und sie starte, funktioniert alles (zu erkennen an einem 
Heartbeat-Pin, den ich mir gemacht hab).

Wenn ich aber nun wechselweise die Dinger debugge, hab ich das Problem, 
daß die öfter mal einfach nicht loslaufen. Spannungsversorgung, 
Oszillator und Pullups am MCLR hab ich kontrolliert.

Kann es sein, daß ein Debug-Build nicht von selber losläuft, auch wenn 
der Controller frisch resettet und MCLR high ist?

Und wenn ja: Wie kann ich das abstellen, damit ich nicht immer, wenn ich 
zum zweiten rüberwechsle, den ersten zuerst im Programmer-Modus mit nem 
Release-Build neu flashen muß?

Grüße,
André

[Carsten S. (dg3ycs)]

Hi,

Dumme Frage,
aber du hast schon über voreinstellung oder manuellem Start ("Wiedergabe 
Knopf) im Debug Fenster von MPLAB die Programmausführung gestartet, 
oder?

Gruß
Carsten

[André H. (andrekr)]

Voreinstellung? Die kenn ich nicht. Vielleicht die, die ich suche? :)

Um den Wiedergabeknopf gehts nicht, der funktioniert wunderbar.

Ich meine:
- Ich schiebe im Debugger-Modus mit dem "Program"-Knopf einen 
Debug-Build in den Controller
- Ziehe das PICkit ab und resette den Controller (Strom aus, Strom an)
- Es passiert: Nichts. Das Programm wird nicht ausgeführt

Schiebe ich aber im Programmer-Modus einen Release-Build in den 
Controller, fängt das Programm nach dem Reset an zu laufen.

[Carsten S. (dg3ycs)]

Ah so,

du meinst OHNE angeschlossenem PicKit...

Da bin ich momentan auch überfragt... Es ist ja gerade der Sinn des 
Debug-Builds das dieser erst anläuft wenn das Startsignal kommt. Ohne 
PK3 kann aber kein Startsignal kommen. Demzufolge müsste bei 
ausbleibendem Startsignal der Pic immer erst kontrollieren ob überhaupt 
ein PK3 angeschlossen ist. Bei den begrenzten Hardware resourcen in den 
kleinen µC ist das nicht unbedingt immer Sinnvoll für einen so kleinen 
Zusatznutzen im Verhältniss so viel Aufwand zu treiben.
Das lauslaufen im Debug-modus wird ja ebend NICHT über !MCLR 
gesteuert...

Trotzdem will ich aber nicht ausschließen das es vieleicht doch eine 
Möglichkeit gibt. Die kenne ich nicht. Kannst deine Frage ja mal direkt 
an Microchip stellen. Bisher habe ich immer Antwort bekommen.

Was ich meinte war "mit" angeschlossenem PK3. Da gibt es ja die Option 
"Run after Programm", was auch im Debug-Modus funktioniert. Dann läuft 
der µC erst einmal direkt an, auch ohne manuellen Startbefehl.
Aber halt nur mit angeschlossenem PK!

Gruß
Carsten

[André H. (andrekr)]

Also, ich weiß ja nicht, ob das bei meinem PICkit3 anders ist, aber laut
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2123&param=en022522 
(Interessant ist der Abschnitt ab "Next, the Debugger>Run function or 
the Run icon (forward arrow) is usually pressed") wird die Debug 
Executive erst aktiv, wenn der erste Breakpoint getroffen wird.

[Marco S. (sharkman)]

Hi.

Also soweit mir bekannt, ist der Sinn eines Debug build, dass der Code 
so bestehen bleibt, dass er gestartet wird. Zu dem sind die 
Optimierungen deutlich schlechter, die automatisch durchgeführt werden.

Ich selber habe es auch noch nicht erlebt, dass ein Debugbuild von 
alleine Startet auch wenn man es fest einbrennt. Bei mir mault da auch 
schon MPLAB bzw. der C18 wenn ich das versuche.

Das funktioniert genauso wenig wie den Release build im Debug-Mode zu 
starten.

[Loonix (Gast)]

Marco Schulze schrieb:
> Ich selber habe es auch noch nicht erlebt, dass ein Debugbuild von
> alleine Startet auch wenn man es fest einbrennt.

Genau das soll durch die Unterscheidung Debug/Release auch erreicht 
werden. Das AVRStudio z.B. kennt eine solche Unterscheidung nicht und 
deshalb kann der Controller ungewollt starten, obwohl der Debugger 
angesteckt ist - oder startet beim Einschalten das Programm obwohl man 
noch keinen sicheren Stand (Release) erreicht hat. Bei kritischen 
Anwendungen kann das üble Folgen haben und ich finde das MPLAB-Konzept 
in diesem Fall einfach professioneller weil es keine unerwarteten 
Anläufe gibt.