PIC 18F4420 schaltet FET, mal nicht

Hy,

ich hab eine relativ komplexe platine für den Raspberry PI entwickelt. Ich hab alle aufgetretenen fehler gelöst, bis auf einen:

Ich nutze den PIC unter anderem, um den Raspberry und andere Stromverbraucher zu schalten. Für tests hab ich eine einfaches Programm geschrieben das einfach nur die nötigen PINs schaltet, welches funktionieren sollte (wüsste nicht warum nicht).

Das ganze funktioniert am anfangs schön und gut, wenn ich mich aber an einer bestimmten stelle mit dem Finger der platine nähere, und wieder entferne schaltet der FET nicht mehr, nur wenn ich den finger an einer bestimmten stelle über der Platine habe (muss sie nicht berühren, der effekt ist vermutlich kapazitiver natur).

Ich nutze keinen externen quarz, sondern den internen takt mit 8 MHz. Die Stromversorgung ist ein selbstgebauter Step-Down wandler mit etwa 70KHz, ohne besondere siebeschaltungen, wodurch der PIC mit spikes von etwa 0,5V konfrontiert ist. Abblockkondensatoren sind vorhanden. Der PIC ist sehr nahe am StepDown (an einer seite des PICs ist auf dem anderen layer bereits die Spule (geschirmt). MCLR ist deaktiviert.

Die Frage ist jetzt, was könnte den fehler verursachen?

• Das Problem wird mithilfe einer (kapazitiven, oä.) Änderung ausgelöst, und bleibt auch nachher bestehen
• Um dem Chip am laufen zu halten muss der finger an einer bestimmten stelle der Platine gehalten beleiben. Die FETs laufen dann aber nicht dauernd, sondern werden mit etwa 50Hz geschalten (einstreuen der Netzspannung über den Finger).

Ich vermute mal den Step Down, ich hab aber auch schon komische probleme mit PICs gehabt, die ohne StepDown schon gesponnen/oder gar nicht angelaufen sind. Deshalb frage ich hier nochmal, ob villeicht irgendjemand von euch bereits solche probleme gehabt hat, oder welche arten von probleme es sein könnten. Besonders die Frage, wie viele störungen ein PIC auf der Versorgung verträgt, bzw. direkte/indirekte Magnetische/Kapazitive einwirkungen auf den Chip er verträgt, wäre für die problemlösung vermutlich von interresse.

mfg, pointhi

Vielleicht liegt das Problem in der Beschaltung des Transistors. Mit welchem Pin wird er geschaltet? Kannst du bitte eine Skizze von der Beschaltung des Leistungsteils machen? Ist das ein Logic Level MOSFET, welcher Typ?

Anhang 26848Die Schaltung ist erprobt, und das problem liegt bereits beim steuersignal (schaltet nicht mehr auf high, bzw. im 50Hz takt). Bei +5V/1 liegt die versorgungsspannung an. Geschalten wird mit PIND0, bzw. der 2. Fet mit PIND1, laut datenblatt entweder für IO oder paralelle schnittstelle konfigurierbar, also passend.

mfg, pointhi

Hallo pointhi.

Zitat:

---

Zitat von pointhi

...das problem liegt bereits beim steuersignal (schaltet nicht mehr auf high, bzw. im 50Hz takt)

---

Dann schau nochmal ganz genau, was du mit den TRIS-Bits von Port D und vor allem von Port E machst.
50Hz am führerlosen FET: das sieht nach fehlender bzw. zu hochohmiger Ansteuerung aus.

Ansatz zur Fehlersuche:
Ich hatte mir schon mal bei einem 16F87x selber mit dem PSP ein Bein gestellt:
Weil ich die TRISE-Bits der nicht implementierten PORTE-Leitungen leichtfertig abweichend vom default gesetzt hatte,
(((im Stil von: sämtliche 3 PORTE-Leitungen als Inputs? Dann TRISE gleich durchgängig 0xFF, weil's schöner aussieht)))
war plötzlich der PSP aktiv und PORTD lief vermeintlich Amok.

rate mal was das problem war :)

Code:

---

TRISA  = 0xFF;      // 1... Input
    TRISB  = 0x00;      // 0... Output
    TRISC  = 0xFF;
    TRISD  = 0b11111100;
    TRISE  = 0xFF;

---

Tja, und da glaubt man das die TRIS register nur für die Einstellung ob Ein oder Ausgang da sind.

Werd den Teil in das ändern:

Code:

---

TRISE = 0x0F;

---

Morgen teste ich's, sollte aber das problem gewesen sein.

Danke, ich arbeite schon über ne woche an dem problem (hab dabei auch masseschleifen entfernt die bei anderen sachen probleme gemacht haben). Wäre wohl aber nie darauf gekommen das das TRISE register auch den Paralellport aktiviert.

mfg, pointhi

- - - Aktualisiert - - -

Scheint wohl nicht das ganze problem gewesen zu sein :(. Ich kann den PIC noch immer mit dem Finger ausschalten.

Ich hab dann auch noch testweise eingestellt, das der FET immer ein und ausschaltet, es funktioniert so lange, bis mein finger wieder in die nähe des chips kommt, und von da an nicht mehr (wobei ich dabei meistens schon sehr nahe am chip bin)

Ich schreib hier mal meinen Testcode hin, villeicht hilft er ja:

Code:

---

/*
 * @file  main.c
 * @author thomas
 *
 * Created on 24. März 2013, 18:36
 */

//############### DEFINE CONSTANT

#include <pic18.h>
#include <xc.h>

#define __OSC_INTOSC 1          // nutze Internen Oszillator

#define o_FET_SPC_Vp        LATDbits.LATD0
#define o_FET_SPC_5V        LATDbits.LATD1

//############### END OF DEFINE CONSTANT


#define _XTAL_FREQ 8000000

#ifdef __OSC_INTOSC
    #pragma config IESO = OFF, OSC = INTIO67, FCMEN = OFF              // CONFIG 1H        // Internal Oscilator
#else
    #pragma config IESO = OFF, OSC = HS, FCMEN = OFF                    // CONFIG 1H        // External Oscillator
#endif
#pragma config BOREN = OFF, PWRT = OFF                                  // CONFIG 2L
#pragma config WDT = OFF                                                // CONFIG 2H
#pragma config CCP2MX = PORTC, PBADEN = OFF, LPT1OSC = OFF, MCLRE = OFF // CONFIG 3H
#pragma config STVREN = OFF, XINST = OFF, DEBUG = OFF                  // CONFIG 4L
#pragma config CP0 = OFF, CP1 = OFF                                    // CONFIG 5L
#pragma config CPD = OFF, CPB = OFF                                    // CONFIG 5H
#pragma config WRT0 = OFF, WRT1 = OFF                                  // CONFIG 6L
#pragma config WRTB = OFF, WRTC = OFF, WRTD = OFF                      // CONFIG 6H
#pragma config EBTR0 = OFF, EBTR1 = OFF                                // CONFIG 7L
#pragma config EBTRB = OFF                                              // CONFIG 7H

void main() {
    #ifdef __OSC_INTOSC          // PLL Disabled, 8MHz
        OSCCONbits.IRCF2    = 1;
        OSCCONbits.IRCF1    = 1;
        OSCCONbits.IRCF0    = 1;
        OSCTUNEbits.PLLEN  = 0;
    #endif

    TRISA  = 0xFF;      // 1... Input
    TRISB  = 0xFF;      // 0... Output
    TRISC  = 0xFF;
    TRISD  = 0b11111100;
    TRISE  = 0x0F;

    LATA = 0x00;
    LATB = 0x00;
    LATC = 0x00;
    LATD = 0x00;
    LATE = 0x00;



    while(1) {
        for(char i=0;i<10;i++)
            {
            __delay_ms(50);
            }
        o_FET_SPC_Vp = 1;
        o_FET_SPC_5V = 1;
        for(char i=0;i<10;i++)
            {
            __delay_ms(50);
            }
        o_FET_SPC_Vp = 0;
        o_FET_SPC_5V = 0;
    }
}

---

Ich hoffe mal es ist noch immer ein Softwareproblem, EMV probleme zu finden ist meiner meinung ungleich schwerer.

mfg, pointhi

Ist der abgeschaltete Zustand des FET instabil (oder der eingeschaltete Zustand)? Im ersteren Falle würde ich es mit der Reduzierung des GS-Ableitwiderstandes R18 probieren, vllt. ist der OFF-Zustand bisher nicht niederohmig genug angesteuert.

Zur Abgrenzung:
Tritt der Effekt auch dann auf, wenn die Ansteuerschaltung keine Verbindung zum Controller hat? (z.B. Controller rausgezogen, Basis von T1 über R17 nach GND gebrückt). Hintergrund der Frage ist, dass es bei den PIC16Fxxx ja die Read-Modify-Write-Falle gibt, wo der Controller bei einer PORTx-Bitmanipulation einen von außen temporär übersteuerten/verbogenen/umgepolten/verzerrten Logikpegel dauerhaft übernimmt. Das sollte aber bei den Typen mit LATx-Ausgangsregister Schnee von gestern sein.

Du kannst auch versuchen, mit LED + Vorwiderstand zu prüfen, ob der T1=OFF und IC3=OFF wirklich durch ein aktives LOW herbeigeführt wird oder noch immer nur ein HiZ-Zustand des Portpins ist.

Vielleicht sagst du auch noch ein Wort zur Funktion, die hinter dem FET IC3 steckt, wie sich der Controller selbst abschaltet, aktiver und passiver Zustand am FET. Ich habe bisher nur auf Basis von Vermutungen geratschlagt (wenngleich nicht ganz erfolglos).

Nicht vergessen: auf eine minimale Fläche des Gatesteuerstromkreises achten, sofern das nicht unter "Beseitigung von Masseschleifen" bereits abgehandelt ist.

Hallo pointhi,

Etwas ungeschickt ist die Ansteuerung des BC847.
Wenn SPC_5V hochohmig wird, hast du keine Ahnung was der Transistor macht!

Ein zusätzlicher Widerstand zwischen Basis und Emitter, würde dies beheben.

Zudem könnt man R17 und den zusätzlichen Widerstand problemlos auf etwa 10k erhöhen.

Hast du am Drain von IC3 eine Last dran beim Messen?
Schliesse an J2 mal so 1k als Last an.

MfG Peter(TOO)

wenn ich es richtig einschätze ist der fet im eingeschalteten zustand innstabil (weil er sich beim auftreten des problemes ausschaltet). Der FET an sich ist nur dazu da, die Betriebsspannung zu schalten (Tiefentladeschutz, kaltstart des restlichen Systems). Schaltzeiten sind daher irrellevant.

Ich hab den pic auch mal umprogrammiert dass der Ausgang wechselseitig high/low wird (500ms), es hat so lange funktioniert, bis ich wieder das system mit dem finger außer gefecht gesetzt habe (wobei es sich hin und wieder nach ein paar sec. regeneriert hat, aber nur hin und wieder).

Der FET wird bei meinen Tests entweder mit einer LED, oder mit einem ganzen Raspberry Pi belastet (0,5A leerlauf sind realistisch), bei beiden tritt das problem auf.

Die Modifikationen am board werde ich morgen durchführen, wenn ich bessere möglichkeiten für SMD-Arbeiten habe.

Damit ihr euch etwas darunter vorstellen könnt hab ich mal ein foto vom aktuellen layout dranngehängt:

Anhang 26858
Das wichtigste hab ich noch einmal eingezeichnet, meine version ist leicht abgeändert, weil ich noch ein paar kondensatoren mehr für den StepDown benötigt habe, und die masseschleifen entfern habe (die aber erst auftreten, wenn der Raspberry Pi bzw. das Display eingesteckt werden.)

Meine therorie ist, da das register problem weg ist, dass ich mithilfe des fingers störungen des step downs ( oder vom netz) auf ein kritisches niveau bekomme, und so die schaltung zu spinnen beginnt. Was mich dabei aber wundert ist dass die schaltung danach nicht wieder normal weiterarbeitet.

Ich werde jetzt dann mal die basis des transistors mit einem wiederstand auf masse ziehen, sodass bei einem offenen ausgang ein stabiler pegel vorhanden ist.

mfg, pointhi

Hallo!

Zitat:

---

Zitat von pointhi

Was mich dabei aber wundert ist dass die schaltung danach nicht wieder normal weiterarbeitet.

---

Das ist für mich ein sicherer Beweis für Softwarefehler, der deiner "theorie" widerspricht. ;)

tja, das programm ist minimalistisch. Also muss es irgendein register sein was ich übersehe habe. Oder der PIC hat an sich ein problem.

Falls der PIC am anfang korrekt funktioniert, wenn ich die basis mit einem widerstand nach GND erweitere, und dann wieder probleme bereitet wenn ich ihn irgendwie mit dem Finger beeinflusse, ist das aber mit sehr großer warscheinlichkeit ein hardware-problem. Weil dann schickt der PIC ein korrektes signal, und ich hab im Programm keinerlei funktionen die irgendwas einlesen oder an den registern verstellen.

Zitat:

---

Zitat von pointhi

Weil dann schickt der PIC ein korrektes signal, und ich hab im Programm keinerlei funktionen die irgendwas einlesen oder an den registern verstellen.

---

Woher weisst du es ? Ich kann leider ohne kompletten und verständlichen Schaltplan nix konkretes sagen. ;)

Ich hab jetzt mal einen widertstand von der steuerleitung zur masse (12K), und eine led zur masse mit widerstand geschlossen.

Ergebnis: LED leuchtet, bis der fehler auftritt, oft (aber nicht immer) regeneriert sich das system aber nach ein paar sekunden.

Hier sind die Eagle-Dateien des projekts, villeicht wird man hier fündig:

Anhang 26862

Es sind ein paar modifikationen auf der platine, die sich aber nicht auswirken sollten. (Ein paar kondensatoren mehr,...)

Ein lehrer hat mir den tipp gegeben, dass der pic mit den Störungen auf der Spannungsversorgung nicht zurechtkommen könnte, eine spule hat nichts gebracht, also werde ich den pic testweise mal mit einer eigenständigen Versorgung ausstatten (Linearregler, 5V).

Beim Thema softwareproblem fällt mir nichts ein was nicht funktionieren könnte. Den Code hab ich ja schon ein paar threads vorher gepostet, und die Steuerpins schalten auf high, sonst würde die LED nicht genügend strom bekommen.

mfg, pointhi

Zitat:

---

Zitat von pointhi

Ich nutze keinen externen quarz, sondern den internen takt mit 8 MHz. Die Stromversorgung ist ein selbstgebauter Step-Down wandler mit etwa 70KHz, ohne besondere siebeschaltungen, wodurch der PIC mit spikes von etwa 0,5V konfrontiert ist.

---

0,5 V sind zuviel, da funktioniert der Regler nicht richtig. Eine "besondere Filterschaltung" braucht man, um die letzten mV zu entfernen.

MfG Klebwax

glaube ich auch, ich werde deshalb einen linearregler versuchsweise mal benutzen (natürlich von versorgungsspannung auf 5V, der strom ist ja nicht sehr hoch).

Hallo pointhi,

ändere mal deinen Code in " __delay_ms(500); ". Dann geh mal mit dem Multimeter drann.
Oder sogar in 1000 ms.

Taktet der PIC-Pin zwischen 5V und 0V?

Wenn nicht, dann suchen wir weiter.

Oder hast du zwischenzeitlich den Fehler gefunden?

Gruß

Eine IDee hätte ich noch:
Den MCLR Pin hast Du ja ausgeschaltet in der Konfiguartion. Ich weis aber aus Erfahrung, daß dieser PIN trotzdem extrem empfindlich auf Störungen reagiert.
300mV über Vcc löst einen Reset aus, obwohl der PIN eigentlich abgeschaltet wurde. Vielleicht streut hier etwas rein.
Ich habe eine Shottky Diode zwischen VCC und MCLR Pin eingebaut um hier Spannungsspitzen, woher auch immer, auszuschalten. Das hat sich sehr bewährt. Problem ist nur beim Programmieren muss die Diode erstmal wieder raus
wegen der gewollten höheren Programmierspannung.
Das Anlaufen der PIC's ohne Brown Out Enabled ist immer wieder problemeatisch nach meinen Erfahrungen her. Zumal DIESER PIC generell ein Problem mit der Brown Out Schaltung hat, laut Errata Sheet.
Es klingt eindeutig nach einem Hochohmigen Problem. Also niemals den MCLR in der Luft lassen, auch wenn dieser Softwaremässig abgeschaltet wurde.

Ich denke mal wie ossy schrieb: lange Warteschleife und den Pin sich anschauen. Wenn er plötzlich nichts mehr tut nachdem Du mit dem Finger das Problem ausgelöst hast,
würd ich auf den Reset Pin tippen.

ich hab mal einen linearregler rangehängt, der step down hat aber wild in die versorgung hineingestrahlt (ca. 50mV Brummspannung auf 5V vom Linearregler, mit den typischen schwingungen des step Down). Den Test ob die Versorgungsspannung das problem ist konnte ich also nicht wirklich durchführen. Das Problem ist noch immer bestanden.

Das mit dem MCLR Pin könnte wirklich das problem sein. Villeicht geht der PIC in den Programmiermodus, und verlässt ihn mit ein wenig glück wieder. Ein Widerstand (5k6) nach masse, und ein 100nF kondensator sollte meiner meinung ausreichend sein um das zu probieren, und sollte so auch ohne diode den Pin auf einem sauberen pegel halten. Und das Programmiergerät schafft sowieso genügend strom um den pin wenn nötig nach oben zu ziehen.

Zitat:

---

ändere mal deinen Code in " __delay_ms(500); ". Dann geh mal mit dem Multimeter drann.
Oder sogar in 1000 ms.

---

Durch die for-schleife sind es (sichtbare) 500ms, leider aktzeptiert mir der compiler keine hohen delay werte, deshalb musste ich ein wenig tricksen :). Das Blinken hat funktioniert, bis der fehler auftrat. Er hat auch auf der Steuerleitung den LED mit genügend strom versorgt (hab ich glaub ich schon geschrieben).

Brown Out Enabled werde ich auch mal aktivieren, wobei ich mir nicht vorstellen kann das das das problem ist (weil der pic ja schon sauber läuft wenn das problem auftritt)

thx für die bisherigen ideen.

mfg, pointhi

- - - Aktualisiert - - -

ich hab jetzt den mclr pin so beschalten, dass ein spannungsteiler auf 2,5V gemacht wird. Also 100nF Kondensator und 5k6 Ohm Widerstand von MCLR auf masse, und seriell ein 5K6 Ohm Widerstand und eine Schottky Diode (Seriell) von +5V auf MCLR. Vorher hatte ich teilweise spitzen von +- 100-200mV auf MCLR, welche sich ein wenig minimiert haben, aber noch immer existent sind (jetzt aber auf einem sichern Pegel).

Das Problem existiert noch, aber ist gefühlt abgeschwächt worden. Auch hab ich herausgefunden das der problem z.b. beim programmierstecker meistens nur auftritt, wenn ich den MCLR Pin berühre. Es wird also vermutlich das problem sein. Meiner meinung könnten die hochfrequnte störungen an sich bereits probleme bei der programmierschaltung hervorrufen, da diese ja auf wenige nm an anderen wichtigen teilen davon im IC heranreichen.

Ich glaub ich werde die Platine soweit neu designen, dass der Step Down mehr abstand zum PIC hat, einen Filter erhält und das die MCLR leitung incl. dem Programmierinterface auf störungsärmere bereiche verschoben wird. Dann wird man sehen ob das reicht, oder das problem noch immer vorhanden ist.

Hallo,

Zitat:

---

Zitat von pointhi

Falls der PIC am anfang korrekt funktioniert, wenn ich die basis mit einem widerstand nach GND erweitere, und dann wieder probleme bereitet wenn ich ihn irgendwie mit dem Finger beeinflusse, ist das aber mit sehr großer warscheinlichkeit ein hardware-problem..

---

Du solltest besonderes Augenmerk auf die Masseführung richten. Ganz besonders bei den Leitungen des Wandlers.
Aber bei deinem Bild des Layouts kann man nichts erkennen. Dazu baucht man das Schema um die kritischen Pfade zu erkennen.

Stell dir einfach immer vor, dass jede Leiterbahn auch ein Widerstand ist! Bei einem Schaltregler muss man die Spannung unbedingt direkt am Elko angreifen.
Greifst du z.B. die Masse direkt am Spannungseingang der Schaltung ab, hast du die ganzen Spannungsabfälle, welche beim laden des Elkos anfallen, mit auf deiner Betriebsspannung :-(

MfG Peter(TOO)

MCLR mit 10k auf +5V dann gehts!


Gruß

Zitat:

---

Zitat von pointhi

Anhang 26862

---

Ich hab die eagle-Datei schon hier veröffentlicht. Massepfade des schaltreglers sind sehr bewusst gelegt (möglichst kleine schleifen, masseknoten) (http://www.lothar-miller.de/s9y/cate...t-Schaltregler), in der aktuellen platine sind die eingangs/ausgangskondensatoren mindestens verdoppelt worden, und jeweils noch ein 100nF paralell. Davor hat der regler nicht sauber gearbeitet.

Die Masseführung darüber hinaus ist aber noch nicht optimal gelöst, muss ich also auch noch ändern. (Auf dem Prototypen hab ich zur widerstandsverminderung alle wichtigen leiterbahnen verzinnt, sollte also nicht das ursächliche problem sein)

Zitat:

---

MCLR mit 10k auf +5V dann gehts!

---

MCLR ist deaktiviert, und derzeit auf 2,5V gelegt. Wenn ich auf 5V lege und die störungen zu stark sind hab ich wesentlich schneller VCC+0,3V erreicht. Glaube nicht das das hilft.

mfg, pointhi

Zitat:

---

Zitat von pointhi

MCLR ist deaktiviert, und derzeit auf 2,5V gelegt. Wenn ich auf 5V lege und die störungen zu stark sind hab ich wesentlich schneller VCC+0,3V erreicht. Glaube nicht das das hilft.

---

Nicht glauben, probieren! Bau dir ggf. einen steckbaren Terminierer für den ICSP-Anschluss mit Brücke +5V --> /MCLR.
Aber warum in aller Welt den /MCLR auf die halbe Versorgungsspannung legen? Das erscheint mir maximal unplausibel: Entweder hat das elektrische Geschehen am deaktivierten/MCLR keine Wirkung auf das Innenleben des Controllers, oder aber (Vcc - Vss)/2 haben an dieser Stelle nichts zu suchen.

Zitat:

---

Zitat von ossy

MCLR mit 10k auf +5V dann gehts!Gruß

---

So halte ich es mit meinen PIC-Schaltungen ja auch, mit enger Bauweise auf Lochraster; die /MCLR-"Antenne" ist dann ca. 2-3cm kurz.
Das scheint i.d.R. auch ganz gut zu funktionieren. Allerdings kann ich zumindest bei einer meiner Anwendungen mit einem 10cm-Stück Aluprofil in der Hand zuverlässig einen Reset bewirken, wenn ich den /MCLR am ISCP-Anschluss berühre: Ergo ist der Tip zwar Microchip'sches PICkit-Kulturgut, aber auch nicht der Weisheit letzter Schluss.
Allerdings gibt es m.E. in diesem Punkt in der Microchip-Doku eine Diskrepanz zwischen der Soll-Beschaltung für ICSP-Betrieb mit PICkit und der allgemeinen Beschaltungsempfehlung für den /MCLR-Anschluss: das entstörende RC-Glied am /MCLR, das für PICkit-Betrieb wiederum tabu ist.

Ich würde also für den Test mit dem 0,0Ohm-Terminierer plädieren.

Nochmal zur Klärung, weil die Frage soweit ich weiß unbeantwortet blieb:
Gibt es bei den PIC18F-Typen die Read-Modify-Write-Falle, und wenn ja, ist sie in deinem Programm geschlossen? Du solltest Bitmanipulationen an den Ausgängen nie auf der Basis der vom Port gelesenen Bits sondern immer auf der Basis der Post-Latches ausführen.

Zitat:

---

Zitat von RoboHolIC

das entstörende RC-Glied am /MCLR, das für PICkit-Betrieb wiederum tabu ist.

---

Ein Kondensator an einem Prozessorreset ist eigentlich kein Entstörglied, sondern sollte den Reset solange verzögern, bis der Takt und die Spannung(en) stabil sind, so eine Art Resetdelay für Arme. Bevor es Resetbausteine gab, war das ein gängiges Verfahren. Heute ist das alles nicht mehr erforderlich, Resetdelay und Brown Out sind im Prozessor eigebaut. Die 10k sind also ganz oK. Wenn man sich Störungen im Reseteingang einfängt, tut man das auch an anderen Eingängen, die Wirkung ist dann nur nicht so einfach zu sehen (und wird einem dann auf die Füße fallen, wenn man es garnicht gebrauchen kann).

MfG Klebwax

Ich denke, dass per Konfiguration erstellte innere Verbindung von /MCLR mit +VCC das unempfindlichste auf Störungen ist. ;)

@pointhi
... aber bitte zuvor prüfen, ob eine solche Chipkonfiguration den Controller nicht dauerhaft unprogrammierbar macht!

@pointhi
@alle

Am PIN MCLR darf kein Kondensator dran.

Gruß

Laut Datenblatt muss zwischen Kondensator und MCLR ein Widerstand >= 1kOhm.
Mal 'ne andere blöde Idee: im Quellcode fand ich keine explizite Sperrung der Interrupt's. Könnte es vielleicht sein, dass unbeabsichtigt externe Interrupts im INTCON freigegeben sind, die mit dem bösen EMV Finger ausgelöst werden?

Zitat:

---

Zitat von witkatz

im Quellcode fand ich keine explizite Sperrung der Interrupt's.

---

Die müssen üblicherweise nach Reset explizit _freigegeben_ werden.

Zitat:

---

Zitat von RoboHolIC

Die müssen üblicherweise nach Reset explizit _freigegeben_ werden.

---

Das stimmt, aber zu dem C-Projekt gehören noch weitere Projektbestandteile, Header-Dateien, Compiler-Direktiven in den Projekteigenschaften vielleicht noch weitere C-Dateien usw. Ich denke in der Richtung, dass vielleicht wenn nicht Interrupts, so vielleicht andere Peripherie-Module wie In-Circuit-Debugging oder etwas ähnliches unbeabsichtigt aktiviert sind und per Signaleinstreuung die MCU aus dem Takt bringen.
Wenn das dilettantisch klingt, dann sorry.

Nachtrag:
ok, ich sehe es, #pragma DEBUG = Off. Ich nehme an, dass damit das In-Circuit-Debugging ausgeschaltet also DEBUG Bit = 1 gesetzt wird?
Das LVP wird nicht ausgeschaltet, also ist es an. Kann es sein dass Störsignale oder schwimmende Pegel an RB5 den Programmiermodus aktivieren?

Fast alles über /MCLR findet man unter 4.2 RESET auf 43. Seite von: http://ww1.microchip.com/downloads/e...Doc/39631E.pdf .

Zitat:

---

Zitat von witkatz

... zu dem C-Projekt gehören noch weitere Projektbestandteile, Header-Dateien, ... In-Circuit-Debugging oder etwas ähnliches unbeabsichtigt aktiviert ... Wenn das dilettantisch klingt, dann sorry. ... Das LVP wird nicht ausgeschaltet ...

---

Nein, nein, absolut nicht dilletantisch, ganz im Gegenteil; nur eben nicht auf meiner Checkliste, weil ich bisher ausschließlich "biologisch-dynamische Softwareentwicklung" betreibe, sprich: Assembler, eine Sourcedatei, dazu die Standard-<prozessor>.INC und fertig; d.h. ich weiß genau, was drin ist und was passiert.

Zitat:

---

Zitat von witkatz

ok, ich sehe es, #pragma DEBUG = Off. Ich nehme an, dass damit das In-Circuit-Debugging ausgeschaltet also DEBUG Bit = 1 gesetzt wird?
Das LVP wird nicht ausgeschaltet, also ist es an. Kann es sein dass Störsignale oder schwimmende Pegel an RB5 den Programmiermodus aktivieren?

---

Ich hab jetzt die zeile erweitert:

Code:

---

#pragma config STVREN = OFF, LVP = OFF, XINST = OFF, DEBUG = OFF        // CONFIG 4L

---

In den tests konnte ich den Chip nicht mehr stören -> das problem sollte gelöst sein. Ich hab beim programmieren der Config Bits wohl nicht genau geschaut, und der pic hat mithilfe von LVP aufgrund der störungen in den Programmiermodus geschalten.

Nochmals danke an alle die tipps und ideen geschrieben haben. Das war kein problem welches einem oft begegnet. Ein paar tipps werde ich sicher auch in die nächste platin-version übernehmen.

mfg, pointhi

Zitat:

---

Zitat von pointhi

In den tests konnte ich den Chip nicht mehr stören -> das problem sollte gelöst sein.

---

Da bin ich anderer Meinung, sorry. Das ungelöste Problem bleiben die Störungen. Was gelöst ist, ist nur ein Symptom.

ich vermute der step down benötigt noch einen filter, bzw. größere kondensatoren an ein und ausgängen.

Zitat:

---

Zitat von pointhi

größere kondensatoren an ein und ausgängen

---

Sind die bereits vorhandenen Kondensatoren im Schaltnetzteil LowESR-Typen? Mehr Kapazität bedeutet zwar -innerhalb der selben Raureihe- geringeren ESR, aber mehr Wirkung erzielt man angeblich mit mehreren (n) kleinen Kondensatoren parallel; die Summenkapazität kann gleich bleiben, der Gesamt-ESR reuziert sich auf r1/n * ESR des Einzelbauteils.

Zitat:

---

Zitat von pointhi

kein problem welches einem oft begegnet

---

Naja, der enabelte LVP-Mode kann im ungünstigsten Fall bereits den HV-Programmierablauf stören, bevor das LVP_OFF-Bit überhaupt das erste mal wirksam wird. Dagegen könnte man sich mit eiserner Disziplin bei der Konfiguration des LVP wappnen oder aber stets einen Pulldown-Widerstand am PGM-Pin einplanen. Damit wäre man auf der sicheren Seite.

Zitat:

---

Zitat von RoboHolIC

Naja, der enabelte LVP-Mode kann im ungünstigsten Fall bereits den HV-Programmierablauf stören, bevor das LVP_OFF-Bit überhaupt das erste mal wirksam wird. Dagegen könnte man sich mit eiserner Disziplin bei der Konfiguration des LVP wappnen oder aber stets einen Pulldown-Widerstand am PGM-Pin einplanen. Damit wäre man auf der sicheren Seite.

---

Man sollte sich nicht mehr Probleme machen, als nötig. Aus dem Datenblatt:

Zitat:

---

High-voltage programming is always available, regardless of the state of the LVP bit or the PGM pin, by applying VIHH to the MCLR pin.

---

Das ist ja gerade das Schöne an HV-Programming, es geht immer.