Brennen mit PicKit3

die gnd-leitung hast auch angeschlossen?

also vss?

genau, pins 1-5 wie auf dem beiliegendem poster angeschlossen?

jap hatte vergessen die spannung vom usb einzuschalten.
nun aber ein neues Problem, wenn ich das programm laden will kommt:
Address: 0 Expected Value: 73 Received Value: 0
Failed to program device

Das ist die genaue Meldung, weiss nicht wo der Fehler ligen könnte...?

Connecting to MPLAB PICkit 3...
Firmware Suite Version.....01.26.92
Firmware type..............PIC18F

Target detected
Target Device ID (0x0) does not match expected Device ID (0x7e0).

Programming...
program memory
Address: 0 Expected Value: 73 Received Value: 0
Failed to program device

Das ist meist, wenn doch irgendwie eine Leitung nicht passt, z.B. Clock 
und Data vertauscht worden sind, aber auch (ist mir schon öfter 
passiert), wenn du versehendlich das PICKIT falschrum draufgesteckt 
hast.

die leitungen sind richtig angeschlossen.
Muss ich einen widerstand zwischen MCLR und VDD haben?

JA!!!
Zwischen 4k7 und 10 k

Muss du im Datenblatt schauen. Manche haben auch einen Weak Pullup 
intern.

Aber Fehler ist es auf jedenfall keiner...

Martin S. schrieb:
> Muss du im Datenblatt schauen. Manche haben auch einen Weak Pullup
> intern.
>
> Aber Fehler ist es auf jedenfall keiner...

JAIN...
Wenn er ausser dem PK3 NICHTS weiter am !MCLR angeschlossen hat (Den 
PullUp komplett weggelassen hat) oder MCLR gar nicht nutzen will, dann 
dürfte dies diesen Fehler NICHT verursachen.

Wenn er aber statt des PullUPs einfach eine Brücke (oder einen zu 
niederohmigen) Widerstand von !MCLR nach VDD gelegt hat, DANN würde das 
genau diesen Fehler verursachen. (Gibt aber noch andere Möglichkeiten, 
z.B. das an den ICSP PIns neben dem Programmierstecker auch externe 
Peripherie hängt die verhindert das die Signale ordentlich ankommen - 
insbesondere C sind da kritisch!

Fall !MCLR ausser an dem ICSP Stecker aber nirgendwo angeschlossen ist 
kommt es wie geschrieben zwar nicht zu diesem Fehler, aber bei der 
Späteren Programmausführung wird der PIC eventuell lustige Effekte 
zeigen, mal laufen, mal unvermittelt halten usw- Natürlich nur wenn die 
MCLR Fuse gesetzt ist.

Gruß
Carsten

Carsten Sch. schrieb:
> Wenn er ausser dem PK3 NICHTS weiter am !MCLR angeschlossen hat (Den
>
> PullUp komplett weggelassen hat) oder MCLR gar nicht nutzen will, dann
>
> dürfte dies diesen Fehler NICHT verursachen.

Ich habe den MCLR nicht angeschlossen und benötige ihn auch nicht. Am 
MCLR ist nur der ICSP Stecker angeschlossen.

Also, Angeschlossen wie auf dem Poster:

!MCLR auf Pin 1
VSS auf Pin 3
PGD auf Pin 4
PGC auf Pin 5

Zusätzlich hab ich eine externe Speisung von 5 Volt durch einen L78L05, 
auf VDD und VSS.

PGM auf Pin 6 hab ich nicht angeschlossen.

Die fehlermelung ist immer noch da.

Erich schrieb:
> Es fehlt   Pin 2   VDD Target
>
>
>
> JA, doch, das wird AUCH gebraucht wenn man extern versorgt !
>
> Denn darüber muss dann der Programmer seine Versorgung zum treiben der
>
> anderen Leitungen (Clock, Data) entnehmen.
>
> Dies wenn "externe" Spannung gewählt ist.
>
> Sieha dazu Postermitte rechts,
>
> "PICkit 3  Internal Circuitry (simplified)"

Okej vielen dank. Dann versuch ichs einmal, wenns nicht klapt meld ich 
mich wider.

Das Programieren hat geklapt. Vielen dank

Doch nun ein neues Problem.

Die Idee war eine RGB-LED zu steuern. Wenn ich den Ausgang auf 0 setze 
sollte die LED leuchten wenn der Ausgang 1 ist sollte sie aus sein. 
wennn ich jetzt jedoch den Setze passiert garnichts.
Habe ich einen überlegungsfehler gemacht?

Deine Ausgänge haben nichts an dem Emitter verloren. Du willst ja die 
Transistoren damit an oder aus schalten, also müssen die mit dem 
Widerstand an die Basis. An der Basis hast du aktuell dauerhaft 5V, was 
ziemlich Sinnlos ist. Also die Ausgänge an die Basis (über den 
Widerstand) und den Emitter auf Masse.

Doch: Deine LED-treibenden Transistoren sind doch schon 
Darlington-Transistoren. BRAUCHST du denn einen zusätzlichen 
Treiber-Transisor?

Die idee war das wenn ich ein high am ausgang habe kein

Michael Skropski schrieb:
> Deine Ausgänge haben nichts an dem Emitter verloren. Du willst ja die
> Transistoren damit an oder aus schalten, also müssen die mit dem
> Widerstand an die Basis. An der Basis hast du aktuell dauerhaft 5V, was
> ziemlich Sinnlos ist. Also die Ausgänge an die Basis (über den
> Widerstand) und den Emitter auf Masse.

Die idee war das wenn ich ein high rausgebe kein Basisstrom mehr 
fliessen kann beim darlington, da 0V über dem widerstand vor dem Ausgang 
sind.
Wenn ich low am Ausgang habe kann ein basisstrom von ca. 4,7 mA 
fliessen.

Ich brauche ca. 10 V an der LED da die blaue LED 4,5 V benötigt, 5V sind 
daher zuwenig, darum die zwei transistoren

Erich schrieb:
> Funktioniert das denn ohne uC, indem du dann an die jeweilgen Sockelpins
>
> abwechselnd mal +5V oder Masse anlegst, mit Drähtchen?

Jap das funktioniert.

Erich schrieb:
> Und hast du überhaupt Meßgeräte wie ein Multimeter und Scope ?

Hab ich, also ein Multimeter, ein Scope in der Schule und bei der Arbeit

Florian V. schrieb:
> Die Ansteuerung der BC337 geht schon in Ordnung. So sehen Transistoren
>
> aus, die in Basisschaltung eingesetzt werden. In Basisschaltung hat man
>
> keine Stromverstärkung, nur Spannungsverstärkung. Hier machen sie den
>
> Levelshift von 5V auf 12V.

Das heisst das Problem liegt nicht bei der Schaltung?

Was misst du denn für eine Spannung bei logisch 1 und 0 an den 
Ausgängen?

Martin S. schrieb:
> Was misst du denn für eine Spannung bei logisch 1 und 0 an den
>
> Ausgängen?

Ich messe egal ob 0 oder 1 -> 2.1 V

Erich schrieb:
> Vor allem muss man bei den PICs die Funktionalität "Analogeingang A/D
> Wandler" ABSCHALTEN. Das geht über ANSEL oder ANSELA / ANSELB etc.
> Wenn man das nicht macht, sind die Pins nach Reset automatisch
> Analogeingänge!
> Und dann die von Vorschreiber genannten Output Konfiguration, über TRIS
> bzw. TRISA TRISB .
> Datenwert zur Ausgabe über PORT  oder PORTA  PORTB etc.

Ich bin noch anfänger und habe mit dem Pickit 3 geübt, da wird ein 
18f45k20 verwendet, der auch analog eingänge hat ebi den übungen werden 
die jedoch nicht umgestellt.
Ist das bei allen pics so?
Kann ich auch einzelne pins als output definieren und ein paar als 
analoger eingang am gleichen port? z.B: port a 0-2 analog und 3-7 
digital output?

Also bei allen bisher von mir benutzen PICs waren die AD-Eingänge 
aktiviert und mussten deaktiviert werden, zumindest, wenn man den PIN 
als Eingang benutzen will. Beim Ausgang ist der AD-Eingang automatisch 
aus bzw unbenutzt.

Ich hätte jedoch einen anderen, einfacheren Vorschlag. Wieso gehst du 
nicht von den 12V über den Widerstand an die LED und schaltest die 
Kathode per NPN (falls wirklich nötig Darlington) zur Masse. Ist pro LED 
ein Transistor und ein Widerstand. Nachteil: Die LED ist an, wenn der 
Ausgang 1 ist, Vorteil: Wenn du die Standard-PWM-Module vom PIC benutzen 
willst (was bei einer per PWM einstellbaren LED Sinn ergibt), ist es 
sowieso so, dass du einstellst, wie lange der Ausgang auf High ist, 
sprich wie lange deine LED an sein soll. 0 -> LED aus, 255(8bit) bzw 
1023(10bit) -> LED voll an.

Erich schrieb:
> Möglicherweise ist es beim 18f45k20 anders, aber die "einfachen" Pics
>
> haben definitiv ohne Einstellung die Funktion A/D Eingang.

Ich möchte Ra6 und Ra 7 verwenden die sdind keine A/D Eingang, das sind 
OSC1 und OSC2.

Beni W. schrieb:
> Erich schrieb:
>> Möglicherweise ist es beim 18f45k20 anders, aber die "einfachen" Pics
>>
>> haben definitiv ohne Einstellung die Funktion A/D Eingang.
>
> Ich möchte Ra6 und Ra 7 verwenden die sdind keine A/D Eingang, das sind
> OSC1 und OSC2.

Aha, hast Du denn die Config-Bits auch entsprechend gesetzt? Als IntOSC 
mit RA6 und RA7 als I/O Pins? Das wäre dann die Option INTIO2 beim 
18F1220.

Grüße,

Chris

Ich möchte Ra6 und Ra7 einfach als normale output pins nutzen

Beni W. schrieb:
> Ich möchte Ra6 und Ra7 einfach als normale output pins nutzen

Da Du scheinbar das Datenblatt zu dem Chip nicht lesen willst oder 
kannst, kann ich meine Frage und den Hinweis nur wiederholen:

Aha, hast Du denn die Config-Bits auch entsprechend gesetzt? Als IntOSC
mit RA6 und RA7 als I/O Pins? Das wäre dann die Option INTIO2 beim
18F1220.

Grüße,

Chris

Lesen kann ich es schon es ist nur schwer als anfänger auf 300 seiten 
immer das richtige zu finden
Vielen dank aber für eure hilfe

Naja. Das Datenblatt ist gut unterteilt, hat einen Index, etc. Gleich im 
Kapitel zwei "Oscillator Configurations" steht es auch direkt am Anfang.

Da die Pins, die Du nutzen willst, ja OSC1/OSC2 sind, sollte es 
eigentlich klar sein das man dann eben auch bei den OSC Sachen schauen 
muss. 300 Seiten hin oder her, sowas sind Basics, das man ungefähr weiss 
in welchem Bereich des DB man gucken muss.

Du blätterst ja auch nicht das gesamte Telefonbuch durch wenn Du eine 
Nummer suchst, sondern startest Daumen mal Pi an ungefähr der richtigen 
Stelle, oder?

Also, nochmals. Du musst den internen OSC benutzen, und dabei die beiden 
OSC pins so konfigurieren, das sie eben auch als I/O nutzbar sind. Und 
das eben INTIO2 bei den Configbits.

Grüße,

Chris

Christian Klippel schrieb:
> Also, nochmals. Du musst den internen OSC benutzen, und dabei die beiden
>
> OSC pins so konfigurieren, das sie eben auch als I/O nutzbar sind. Und
>
> das eben INTIO2 bei den Configbits.

Ich habe das ganze mal so konfiguriert.
Vor der Konfiguration leuchtete die LED die ganze zeit und lies sich 
nicht ausschalten, jetzt leuchtet sie beim brennen kurz auf erlischt 
dann aber und lässt sich nicht mehr einschalten.

Ich habe ein kleines Programm gemacht um das zu testen.

Ist im Programm noch ein Fehler das es nicht funktioniert?

#pragma config OSC = INTIO2    //Interne Taktquelle Ra6 und Ra7 I/O 
Pins.
#pragma config WDT = OFF       //WatchdogTimer aus
#pragma config PWRT = ON       //Power up Timer an
#pragma config BOR = OFF       //Brown-out Detection aus


#include <p18f1220.h>
#include "delays.h"



void main (void)
{

  TRISA = 0b00000000;   // PORTA 7-0 output
  LATA = 0b00000000;  // Schreibt in LATA 0 (LED leuchtet)

        while (1);
        {
            LATA = 0b11111111;
            Delay10KTCYx(100);
            LATA = 0b00000000;
            Delay10KTCYx(100);
        }
        }

Beni W. schrieb:
> void main (void)
> {
>
>   TRISA = 0b00000000;   // PORTA 7-0 output
>   LATA = 0b00000000;  // Schreibt in LATA 0 (LED leuchtet)
>
>         while (1);
>         {
>             LATA = 0b11111111;
>             Delay10KTCYx(100);
>             LATA = 0b00000000;
>             Delay10KTCYx(100);
>         }
>         }

Ja, klar geht das nicht. Und zwar wegen dem ; nach dem while(1). Damit 
ist für den Compiler dort die Schleife zu Ende, der Rest danach wird 
nicht mehr ausgeführt. Also, das Semikolon da weg, und schon sollte es 
gehen.

Kleiner Tip: Anstelle von

1

#include <p18f1220.h>

besser dies inkludieren:

1

#include <p18cxxx.h>

Somit wählt der Compiler dann automatisch die richtige .h für den Chips 
aus, den Due in der Projekt-Konfiguration angegeben hast. Ein weiterer 
Vorteil ist das man den Code dann auch ggf. für andere PIC's nehmen 
kann, ohne das man dieses include ändern müsste. Klar, dazu muss man 
auch den Code entsprechend Modular aufbauen, so das bis auf spezifische 
Ausnahmen der Code vom Chip unabhängig ist.

So kann man z.B. eine .h anlegen in der die Pin-Zuweisungen drinstehen. 
Bespiel:

1

#ifndef PINDEFS_H

2

#define PINDEFS_H

3

4

#define PIN_IN              1

5

#define PIN_OUT             0

6

7

#define PORT_IN             0xFF

8

#define PORT_OUT            0x00

9

10

#define LED_1               LATAbits.LATA7

11

#define LED_1_DIR           TRISAbits.TRISA7

12

13

#endif

Beim init der Pins sowie dem Schalten der LED kann man dann ganz einfach 
die dort definierten Bezeichnungen nehmen:

1

LED_1_DIR = PIN_OUT;

2

3

while(1)

4

{

5

    LED_1 = 1;

6

    pause();

7

    LED_1 = 0;

8

    pause();

9

}

Wenn man das ganze konsequent durchzieht mus man später, wenn man mal 
einen anderen PIC verwenden will, lediglich die .h Datei anpassen, die 
diese definitionen enthält. Der eigentliche Code aber bleibt dann der 
gleiche.

Entsprechend dann auch z.B. den Hardware-Init in eine eigene .c datei 
packen, und in der main.c dann einfach diese init-Funktion aufrufen.

Grüße,

Chris

Christian Klippel schrieb:
> Ja, klar geht das nicht. Und zwar wegen dem ; nach dem while(1). Damit
>
> ist für den Compiler dort die Schleife zu Ende, der Rest danach wird
>
> nicht mehr ausgeführt. Also, das Semikolon da weg, und schon sollte es
>
> gehen.

Habe das Semikolon weg gemacht, bei der LED passiert immer noch nichts 
am ausgang habe ich konstant 4.13V. Der Pic ist mit 4.5V gespiesen.

Hmm,

mal eine Frage. In dem Schaltbild ganz oben. Sollen da die Pinpositionen 
des Schaltbildes 1:1 mit denen des echten PIC übereinstimmen, oder hast 
Du die nur aus Versehen so eingezeichnet? Denn die Pins auf der rechten 
Seite sind "kopfüber". Du hast dort von Oben nach Unten:

RB4, RB5, RB6, RB7, AVDD, VDD, RA6, RA7, RB2, RB3

Muss aber genau umgekehrt sein.

Hast Du das ganze auch mal nur mit PIC versucht, also ohne den Rest der 
Schaltung? Und wieso 4.5V beim PIC, wenn Du doch einen 5V Regler 
benutzt? Ach ja, und es kann auch nicht schaden AVSS mit VSS und AVDD 
mit VDD zu verbinden.

Grüße,

Chris

Edit: Und vom MCLR sollte auch ein PullUp Widerstand nach VDD gehen, 47k 
oder ähnliches. Wenn der offen ist kann es sein das er garnicht erst aus 
dem Reset kommt.

Christian Klippel schrieb:
> mal eine Frage. In dem Schaltbild ganz oben. Sollen da die Pinpositionen
>
> des Schaltbiled 1:1 mit denen des echten PIC übereinstimmen, oder hast
>
> Du die nur aus Versehen so eingezeichnet? Denn die Pins auf der rechten
>
> Seite sind "kopfüber". Du hast dort von Oben nach Unten:

Angeschlossen sind sie richtig, dieses Schaltbild kommt so von Electina

Christian Klippel schrieb:
> Hast Du das ganze auch mal nur mit PIC versucht, also ohne den Rest der
>
> Schaltung? Und wieso 4.5V beim PIC, wenn Du doch einen 5V Regler
>
> benutzt? Ach ja, und es kann auch nicht schaden AVSS mit VSS und AVDD
>
> mit VDD zu verbinden.

Nein ich habe leider nicht so viele möglichkeiten, ich habe zur zeit nur 
das eine Board.

Christian Klippel schrieb:
> Hast Du das ganze auch mal nur mit PIC versucht, also ohne den Rest der
>
> Schaltung? Und wieso 4.5V beim PIC, wenn Du doch einen 5V Regler
>
> benutzt? Ach ja, und es kann auch nicht schaden AVSS mit VSS und AVDD
>
> mit VDD zu verbinden.

Ich hatte einen 5V Regler, der ging leider beim ersten Versuch kaputt. 
(nächstes mal bestelle ich mehr)
Ich habe mir dann mit einem LM317 und verfügbaren Widerständen einen 
4.5V Regler gelötet.

Christian Klippel schrieb:
> Edit: Und vom MCLR sollte auch ein PullUp Widerstand nach VDD gehen, 47k
>
> oder ähnliches. Wenn der offen ist kann es sein das er garnicht erst aus
>
> dem Reset kommt.

Kann man den MCLR nicht einfach ausschalten?

Ja, MCLR lässt sich über die Config-Bits abschalten. Allerdings ist das 
nicht immer hunderprozentig. Zwar floatet der Reset dann nicht mehr, 
aber ein ausreichender Impuls kann den PIC dann trotzdem noch resetten.

Du sagst das der originale Regler kaputt gegangen wäre. Da ist dann ja 
natürlich die Frage warum, und ob dabei nicht der PIC ebenfalls 
gestorben ist. Denn vom Code her sollte das eigentlich gehen.

Was komisch ist: Du sagst das direkt ein Hig-Pegel an den Pins liegt, 
obwohl ja zuerst LATA komplett auf 0 gesetzt wird?

Füge mal als ersten Befehl in der Main folgendes ein:

OSCCON = 0b01110000;

Das setzt das OSCCON Register auf 8 MHz internen Takt. Nach dem Reset 
steht das nämlich auf 31 kHz, da kannste dann lange warten bis sich was 
tut in der Schleife, durch die langen Delay-Zeiten.

Grüße,

Chris

Ganz vergessen das in der while() Schleife ja der ganze Port sofort auf 
1 gesetzt wird, dann könnte das natürlich schon passen das nach dem 
Start alles auf High-Pegel liegt.

Christian Klippel schrieb:
> Du sagst das der originale Regler kaputt gegangen wäre. Da ist dann ja
>
> natürlich die Frage warum, und ob dabei nicht der PIC ebenfalls
>
> gestorben ist. Denn vom Code her sollte das eigentlich gehen.

Da war noch ein fehler auf der Schaltung drauf, wenn der PIC kaput wäre 
könnte ich ihn dann noch brennen ohne das MPLAB es merkt das er kaputt 
ist?

Die Schaltung ist auch richtig aufgebaut, ich habe das ganze mit 
Drähtchen (als der pic noch nicht drin war) versucht, hat ohne probleme 
geklapt.

Kommt immer drauf an. Der ICSP benutzt ja andere Pins. Wenn nun durch 
irgendwas die Pins, die für das Schalten verwendet werden sollen, 
kaputtgegangen sind kann es natürlich sein das der PIC sich zwar noch 
lesen/schreiben lässt, aber halt eben diese Portpins dann nicht mehr 
funktionieren.

Hast Du das denn jetzt mal mit dem OSCCON probiert?

Als einfach Test kannst Du ja mal folgende zwei main() Routinen 
probieren. Zuerst eine die Port A komplett abschaltet:

1

void main(void)

2

{

3

    TRISA = 0x00;

4

    LATA = 0x00;

5

6

    while(1)

7

    {

8

        _asm NOP _endasm;

9

    }

10

}

Dann eine die ihn komplett einschaltet:

1

void main(void)

2

{

3

    TRISA = 0x00;

4

    LATA = 0xFF;

5

6

    while(1)

7

    {

8

        _asm NOP _endasm;

9

    }

10

}

Sachen wie Config-Bit setzten etc. natürlich wie beim alten Code davor. 
Ist hier nur die reine main() die ich als Beispiel zeige.

Dabei dann mal auch alle Pins an Port A nachmessen, um zu sehen ob es 
nicht vielleicht doch geht und nur einige Pins nicht wollen weil diese 
evtl. jetzt Defekt sind.

Je nach Ergebnis kann man dann mal weiterschauen.

Grüße,

Chris

Edit: Beim Messen der Pins unbedingt an das Pin-Diagram im Datenblatt 
halten. Wie schon gesagt, das Schaltplansymbol ist ganz offensichtlich 
falsch gezeichnet. Nicht das Du dich an dem Symbol orientierst, und 
somit an den falschen Pins misst. Gilt auch für das Überprüfen der 
Versorgungsspannung, etc.

Wenn LATA = 0xFF

Ra0= 0V
Ra1= 0V
Ra2= 0V
Ra3= 1.3V
Ra4= 1.8V
Ra5= 1.3V
Ra6= 1.2V
Ra7= 4.2V

Wenn Lata = 0x00

Ra0= 0V
Ra1= 0V
Ra2= 0V
Ra3= 1.3V
Ra4= 1.8V
Ra5= 1.3V
Ra6= 1.2V
Ra7= 4.2V

Bei beiden also gleich

Am Pic kanns auch nicht liegen hab in Ausgewechselt, immer noch gleich.

Dann muss da noch irgendwas anderes Faul sein. Das kann ja nicht sein.

Ohne das Du den PIC mal einzeln, z.B. auf einem Steckbrett, ausprobierst 
macht das keinen Sinn mehr da so weiter zu "suchen". Das ist nur noch im 
Nebel rumstochern.

Also, PIC auf's Steckbrett. GND an VSS und AVSS, +5V an VDD und AVDD. 
Programmer Ordnungsgemäß anschließen. Einfaches Testprogram rein, mit 
Config für internen OSC, OSCCON wie oben beschrieben setzen. Alle Ports 
auf Ausgang, dann alle Ports auf 0x00 setzen, nochmal das gleiche mit 
0xFF. Schauen was sich tut. Solange der PIC alleine nicht auf dem 
Steckbrett läuft, wird es auch auf der Platine nicht machen.

Apropos Platine. Gibt es davon mal ein Bild, von beiden Seiten? 
Vielleicht ist da ja was Faul. Wie schon mal gesagt, AVDD und AVSS 
sollten eigentlich nicht offen sein. Spätestens wenn Du den ADC nutzen 
willst geht es ohne nicht mehr. Aber auch sonst ist es eine sehr 
schlechte Idee.

Grüße,

Chris

So das brennen hat geklappt. Es hat am fehlenden Widerstand an MCLR 
gelegen.

Nun ist was neues aufgetaucht. Sobald ich denn Brenner wegnehme bleibt 
der Pic stehen und es geht garnichts mehr.

Erich schrieb:
> Dumme Frage vorweg: Externe Spannungsversorgung ist noch dran,
>
> hoffentlich?

jap die ist dran.

Erich schrieb:
> Wenn ja, dann nächste Frage klären: Haste dein Projekt bisher im
>
> "Debugger" Modus bearbeitet bzw. laufen lassen?

Nein ich verwende MPLAP X1.00 und habe den run (programmer modus) 
benuzt.



Was komisch ist wenn das Programm geladen ist kann ich den USB anschluss 
des PicKit3 ausstecken und es läuft normal weiter sobald ich jedoch das 
PicKit von den Pins meiner Platine wegziehe bleibt der Pic stehen.

Erich schrieb:
> Falls immer noch nicht: Watchdog prüfen (Debuggermodus überschreibt ggf.
>
> die vorgegebenen Einstellungen, Programmmodus nimmt diese ernst).

Watchdog hab ich auf OFF

Hier das simple Programm.


#pragma config OSC = INTIO2    //Interne Taktquelle, Ra6 und Ra7 I/O 
Pins.
#pragma config WDT = OFF       //WatchdogTimer aus
#pragma config PWRT = ON       //Power up Timer an
#pragma config BOR = OFF       //Brown-out Detection aus



#include <p18cxxx.h>
#include "delays.h"



void main (void)
{
         OSCCON = 0b01110000;
  TRISA = 0x00;
         LATA = 0xFF;
         TRISB = 0x00;
  LATB = 0xFF;

        while (1)
        {
            LATA = 0b01111111;
            Delay10KTCYx(250);
            LATA = 0b11111111;
            LATB = 0b11111011;
            Delay10KTCYx(250);
            LATB = 0b11111101;
            Delay10KTCYx(250);
            LATB = 0b11111111;
        }
        }

Beni W. schrieb:
> as komisch ist wenn das Programm geladen ist kann ich den USB anschluss
> des PicKit3 ausstecken und es läuft normal weiter sobald ich jedoch das
> PicKit von den Pins meiner Platine wegziehe bleibt der Pic stehen.

Das klingt für mich sehr komisch. Zumindest so, dass es nicht mit dem 
Programm direkt, sondern eher mit Hardware oder Settings zutun hat.

Schreib das mit dem MCLR nochmal in die Konfig und stell mal den LVP 
explizit aus.


Und ja. Schaltplan und evtl Foto wäre nicht schlecht.