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?
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
Deshalb nutze ich Linux für die wichtigen sachenTheorie ist, wenn man alles weiß, aber nichts funktioniert.
Praxis ist, wenn alles funktioniert, aber niemand weiß warum.
Microsoft hat Theorie und Praxis vereint: Nichts funktioniert und keiner weiß warum!
Meine Website: www.oe5tpo.com
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?
Die 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
Deshalb nutze ich Linux für die wichtigen sachenTheorie ist, wenn man alles weiß, aber nichts funktioniert.
Praxis ist, wenn alles funktioniert, aber niemand weiß warum.
Microsoft hat Theorie und Praxis vereint: Nichts funktioniert und keiner weiß warum!
Meine Website: www.oe5tpo.com
Hallo pointhi.
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.
Geändert von RoboHolIC (01.12.2013 um 22:26 Uhr) Grund: Tipp-Abfall beseitigt.
rate mal was das problem war
Tja, und da glaubt man das die TRIS register nur für die Einstellung ob Ein oder Ausgang da sind.Code:TRISA = 0xFF; // 1... Input TRISB = 0x00; // 0... Output TRISC = 0xFF; TRISD = 0b11111100; TRISE = 0xFF;
Werd den Teil in das ändern:
Morgen teste ich's, sollte aber das problem gewesen sein.Code:TRISE = 0x0F;
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:
Ich hoffe mal es ist noch immer ein Softwareproblem, EMV probleme zu finden ist meiner meinung ungleich schwerer.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; } }
mfg, pointhi
Deshalb nutze ich Linux für die wichtigen sachenTheorie ist, wenn man alles weiß, aber nichts funktioniert.
Praxis ist, wenn alles funktioniert, aber niemand weiß warum.
Microsoft hat Theorie und Praxis vereint: Nichts funktioniert und keiner weiß warum!
Meine Website: www.oe5tpo.com
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.
Geändert von RoboHolIC (01.12.2013 um 23:17 Uhr) Grund: Nachtrag
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:
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
Deshalb nutze ich Linux für die wichtigen sachenTheorie ist, wenn man alles weiß, aber nichts funktioniert.
Praxis ist, wenn alles funktioniert, aber niemand weiß warum.
Microsoft hat Theorie und Praxis vereint: Nichts funktioniert und keiner weiß warum!
Meine Website: www.oe5tpo.com
MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!
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.
Deshalb nutze ich Linux für die wichtigen sachenTheorie ist, wenn man alles weiß, aber nichts funktioniert.
Praxis ist, wenn alles funktioniert, aber niemand weiß warum.
Microsoft hat Theorie und Praxis vereint: Nichts funktioniert und keiner weiß warum!
Meine Website: www.oe5tpo.com
Lesezeichen