Forum: Mikrocontroller und Digitale Elektronik PIC32MZ Ports mit Pull up spinnt


von Uwe B. (uwe_beis)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

mir scheint, dass ich am Ende meiner Weisheit mit dem folgenden Problem
bin. Eigentlich passiert mir so was selten, aber hier habe ich keine
Idee mehr.

Ein PI32MZ (64 Pins) soll an 3 seiner Ports einlesen, ob der jeweilige
Pin auf Masse liegt oder nicht. Dazu sind diese Ports als Inputs
konfiguriert und die Pull-ups sind enabled. Ganz einfach, geradezu
trivial. Geht aber nur teilweise, folgender Effekt:

Ein Pin (Pin 22, PB9) funktioniert normal.
Ein weiterer Pin (Pin 41, PF4) funktioniert, aber etwas anderes stimmt
nicht.
Der letzte Pin (Pin 47, PC13) spinnt ganz merkwürdig.

Letzteres ist das Hauptproblem: Wenn ich Pin 47 auf Masse lege, wird
korrekt 0 eingelesen. Wenn ich die Masse entferne, wird immer noch 0
eingelesen. Wenn ich ein Messgerät (Oszi, Multimeter) an Pin 47
anschließe, zeigt es +2V an und es wird 1 eingelesen(!). Auch wenn ich
danach das Messgerät wieder abnehme. Wenn ich ein Messgerät dauerhaft an
Pin 47 angeschlossen lasse, funktioniert der Port ebenfalls normal(!!),
aber nicht mehr, wenn ich das Messgerät wieder entferne.

Nochmal, mit anderen Worten: Ein Messgerät (Spannung zwischen Port und
Masse) sorgt dafür, dass der Port high wird, wenn er vorher low gezogen
wurde.

Zur Kontrolle, dass alle Register richtig initialisiert wurden, habe ich
einen Screenshot der Einstellungen gemacht (eine Kopie als Text geht
nicht). Im Moment der Aufnahme waren alle Ports offen, trotzdem wird bei
PORTC, Bit 13, 0 eingelesen.

Die Schleife, mit der ich das Verhalten teste, ist der Vollständigkeit
halber am Ende des Beitrags. Das Programm zur Initialisierung der Ports
habe ich mir hier gespart, denn im Screenshot sollte erkennbar sein,
dass alles so ist, wie es sein sollte.

Dieses Verhalten habe ich auf zwei unter verschiedenen Umständen
produzierten Modulen identisch beobachtet. Einen Hardwarefehler schließe
ich daher aus. Der Pin 47 ist auch völlig frei, es ist keine Leiterbahn
angeschlossen oder in der Nähe.

Noch zwei Ungereimtheiten, die mir aufgefallen waren:

1. Die Pull-ups auf Pin 41 und 47 ziehen nur bis ca. 2.0V hoch, der auf
Pin 22 auf knapp 3.3V.
2. Der Strom, wenn ich einen Pin auf Masse ziehe, sollte lt. Datenblatt
maximal 40µA sein, ist aber auf allen drei Pins ca. 280µA.
Ich mache zwar hin und wieder Fehler, auch saublöde, aber eigentlich
kann ich messen - das tue ich sei ca. 50 Jahren. Hier habe ich mehrfach
gemessen und kontrolliert.

Das Modul hat kein Display oder ähnlich, ich kann die Eingangszustände
nur auf Ports ausgeben und mit einem Oszi anzeigen. Meine
Programmschleife dazu:
1
void getDevIndex()
2
{
3
    while (true)
4
    {
5
/*    devIndex =
6
    PLIB_PORTS_PinGet (DEVMODE_PIN_0) |       // M0, 22
7
    PLIB_PORTS_PinGet (DEVMODE_PIN_1) << 1 |  // M1, 41
8
    PLIB_PORTS_PinGet (DEVMODE_PIN_2) << 2;   // M2, 47
9
*/
10
    // Test der Input-Ports:
11
    devIndex = PLIB_PORTS_PinGet (DEVMODE_PIN_2);                  // 
12
M0, Pin 22
13
    devIndex = devIndex | PLIB_PORTS_PinGet (DEVMODE_PIN_1) << 1;  // 
14
M1, Pin 41
15
    devIndex = devIndex | PLIB_PORTS_PinGet (DEVMODE_PIN_0) << 2;  // 
16
M2, Pin 47
17
    // Bitserielle Ausgabe auf Pin 1 (Sync auf Pin 64):)
18
    PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_E, PORTS_BIT_POS_4, 
19
1); // 64
20
    PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_E, PORTS_BIT_POS_5, 
21
(devIndex >> 2) & 1);  // 1
22
    PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_E, PORTS_BIT_POS_5, 
23
(devIndex >> 1) & 1);
24
    PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_E, PORTS_BIT_POS_5, 
25
(devIndex >> 0) & 1);
26
    PLIB_PORTS_PinWrite (PORTS_ID_0, PORT_CHANNEL_E, PORTS_BIT_POS_4, 
27
0);
28
    }
29
}

von micha (Gast)


Lesenswert?

Wenn der Port offen ist, dann kann alles
mögliche an dem Port anliegen. Deshalb sollte
man den Port auf ein definiertes Signal legen.

von WehOhWeh (Gast)


Lesenswert?

micha schrieb:
> Wenn der Port offen ist, dann kann alles
> mögliche an dem Port anliegen. Deshalb sollte
> man den Port auf ein definiertes Signal legen.

Tut er doch. Dazu hat er ja die Pullups eingeschaltet. Das macht per 
Definition einen definierten Zustand, dazu sind die ja da.

@TP
Daher würde ich folgendes prüfen:
Mit dem Debugger schauen, ob:
- Der Pin tatsächlich digital ist
- tatsächlich als IN geschaltet ist (TRIS)
- Wirklichecht die Pullups für den Pin eingeschaltet sind

Wenn die Pullups ein sind, dann muss der PIN auch dann High zeigen, wenn 
ein 470k gegen Masse geschaltet ist.
Ist das so?
Ist das so bei den anderen Pins die funktionieren?

von Uwe B. (uwe_beis)


Lesenswert?

> Mit dem Debugger schauen, ob:
> - Der Pin tatsächlich digital ist
> - tatsächlich als IN geschaltet ist (TRIS)
> - Wirklichecht die Pullups für den Pin eingeschaltet sind
Dafür ist der Screenshot des Debuggers im Anhang, denn 4 (und mehr) 
Augen sehen mehr als 2. Die wesentlichen Registerbits (auch ein paar 
mehr) sind grün eingerahmt.

> Wenn die Pullups ein sind, dann muss der PIN auch dann High zeigen, wenn
> ein 470k gegen Masse geschaltet ist.
Wie ich schrieb: Wenn Pin 47 (PC13) vorher auf 0 war, bleibt er auf 0, 
bis das Messgerät (10 MOhm) anliegt, dann geht auf high bzw. ca. 2V. Ich 
kann also gar nicht am Pin messen, weil das anschließen eines 
Messgerätes die Situation in völlig widersinniger Weise verändert. Ich 
kann nur den ausgelesenen Wert auf einem anderen Port beobachten, und 
der sagt, dass - ich wiederhole - wenn der Pin vorher auf 0 war, bleibt 
er auf 0, bis das Messgerät (10 MOhm) anliegt, dann geht auf high.

> Ist das so?
> Ist das so bei den anderen Pins die funktionieren?
Die anderen beiden Pins verhalten sich bis auf die oben beschriebenen 
Abweichungen (Spannung bei einem nur 2V im High-Zustand und Strom 280 
statt 40µA, wenn auf Masse) normal.

Uwe

von Peter D. (peda)


Lesenswert?

Uwe B. schrieb:
> Das Modul hat kein Display oder ähnlich, ich kann die Eingangszustände
> nur auf Ports ausgeben und mit einem Oszi anzeigen.

Du magst ja vielleicht durchsehen, ein anderer aber kaum.
Warum nimmst Du nicht die UART bzw. SW-UART oder den Debugger zur 
Ausgabe?

Teile das Problem doch erstmal auf, d.h, setze nur die Pullups mit 
nachfolgender Endlosschleife. Und dann miß, ob an jedem Pin ~VCC 
anliegt.
Wenn nicht, dann setze die Register direkt, auch Libs können fehlerhaft 
sein.
Auch könnte das falsche Target für Compiler bzw. Linker eingestellt 
sein.


Und Code postet man besser als Anhang und nicht nur einzelne aus dem 
Zusammenhang gerissene Pfitzelchen, sondern einen vollständigen 
Testcode.
Dann muß niemand mehr im Kaffesatz lesen können, was wie initialisiert 
wird, welche Includes und Typen und wie überhaupt die Reihenfolge im 
Main ist.

von Uwe B. (uwe_beis)


Lesenswert?

Hallo Peter,

danke, aber...

Warum sollte ich einen UART einsetzen, wenn ich eine bequemere und 
schnellere Lösung habe?

Ich habe in meiner Abfrage-und-Anzeigeschleife jetzt zusätzlich im 
Schleifendurchlauf den Befehl zum Setzen des Pull-ups (CNPUCbits.CNPUC13 
= 1;) eingebaut, was nichts geändert hat. Ich nehme an, dass du das mit 
Pull-ups  mit nachfolgender Endlosschleife setzen gemeint hast.

Ich weiß ja, dass die Pull-ups gesetzt sind (insbesondere bei Register 
CNPUC, Bit 13). Das sehe ich in der Debugger-Ausgabe (Window -> PIC 
Memory Views -> Peripherals, ab Adresse BF86_0100 stehen die I/O-Ports). 
Das wirst du sicherlich kennen und den Screenshot schon angesehen haben. 
Das kann also nicht an einer fehlerhaften Library liegen. Die Adressen, 
die der Debugger für die Peripherals anzeigt, stimmen mit denen des 
Datenblattes überein, als kann es keine falsche Compiler- oder 
Linker-Einstellung sein. Und nicht zuletzt: Das Phänomen ist ist ja 
nicht, das es gar nicht funktioniert, sondern dass es mit einer 
unerklärlichen Verhaltensweise funktioniert.

Entschuldige, dass ich den Code im Text gepostet habe. Immerhin ist 
dafür ja ein Tag vorgesehen. Ich hätte es gar nicht tun sollen, denn der 
Code ist eigentlich irrelevant. Was ich beschrieben und mit dem 
Screenshot gezeigt habe, ist vollständig. Ich könnte aber gerne alle 
relevanten Code-Abschnitte aus den verschiedenen Files zusammen stellen. 
Das wäre dann wirklich nichts mehr für den Text.

Nochmal zusammengefasst:
1. Pin 47 (PC13) auf Masse: 0 wird gelesen. Ok. Dann:
2. Pin 47 (PC13) offen: 0 wird gelesen. Falsch. Dann:
3. Pin 47 (PC13) Oszi anschließen: 1 wird gelesen. Korrekt. Dann:
4. Pin 47 (PC13) offen: 1 wird gelesen. Korrekt. Dann weiter bei 1.

In allen Fällen: Wenn Pin 47 (PC13) an Masse: Es fließen ca. 280µA vom 
Pin nach Masse.

Neuer Versuch mit 390k nach Masse: In keiner Situation wird dabei ein 
geänderter Zustand eingelesen. 390k verhält sich also anders als Oszi 
oder Multimeter.

Kaffesatz: Jeder Code, mit dem initialisiert wird, ist irrelevant, wenn 
in der Debugger-Ausgabe bewiesen wird, das es korrekt geschah bzw. dass 
die Register im Moment, in dem der Port gelesen wird, korrekt 
eingestellt sind. Es gibt wahrscheinlich Programmierer, denen 
Registereinstellungen nichts sagen, aber du bist ja zweifellos in der 
Lage, sie zu verstehen und kontrollieren.

Grüße, Uwe

: Bearbeitet durch User
von Uwe B. (uwe_beis)


Lesenswert?

Nachtrag:

Mit einem externen 10k-Pull-up an Pin 47 (RC13) verhält sich der 
Prozessor bzw. das Programm normal. Der Pulldown-Strom ist jetzt ca. 
600µA, also die Summe aus den 280µA aus dem Port-eigenen Pull-up und den 
ca. 330µA des externen 10k. Ein interessanter Versuch, aber er bringt 
mich nicht weiter. Ich suche natürlich eine Ursache, und keine 
halbseidene provisorische Lösung. Der interne Pull-up hat gefälligst zu 
funktionieren, wie an den anderen Ports auch.

Noch eine Beobachtung: Selbst ein 30 cm langes, offenes Kabel an Pin 47 
führt zu normaler Funktion. Ich gehe davon aus, dass irgendwelche 
schwachen Felder zu geringfügigen Spannungen am Port führen, die den 
Pull-up irgendwie "aufwecken". Nach dieser Theorie würde selbst über 
einen 10:1 Oszi-Tastkopf so eine "Aufweckspannung" erzeugt.

von Peter D. (peda)


Lesenswert?

Uwe B. schrieb:
> Ich nehme an, dass du das mit
> Pull-ups  mit nachfolgender Endlosschleife setzen gemeint hast.

Nein ich meine wirklich nur die Pullups setzen und nix weiter. Also 
besonders nicht Deine Osziausgabe.
Ich tu mich da immer sehr schwer, irgendwelche Lib-Funktionen zu 
verstehen, da die so elend lange Argumentenlisten haben. Ich 
schreibe/lese lieber die Register direkt.

Da Du keinen Testcode zeigst, vermute ich mal, daß die Lib-Funktionen 
Seiteneffekte haben, die die Pullups zeitweilig wieder rücksetzen.
Ein Debugfenster zeigt ja immer nur einen Moment, d.h. eine spätere 
Änderung sieht man nicht.
Wichtig wäre daher die Debugausgabe nach dem Pullup-Init in der 
tue-absolut-nix Schleife:
1
for(;;){}
Vielleicht muß da noch ein NOP rein zum Debuggen.
Dann sieht man auch, wenn der Pin extern auf 0 gezogen wird.

Daß Deine Inputs nicht irgendwelche aktiven Sonderfunktionen (ADC, JTAG) 
haben, hast Du aber geprüft.

von Uwe B. (uwe_beis)


Angehängte Dateien:

Lesenswert?

Ok, ich finde solche Versuche gut und richtig, auch wenn ich meine, dass
sie eigentlich keinen Erfolg bringen können, denn je mehr man
experimentiert, desto größer die Wahrscheinlichkeit, doch mal über ein
Indiz zu stolpern.

Ich habe mein bisschen Code auf ganze 3 bzw. mit Oszi 5 Zeilen gekürzt.
Im Bild sieht man:

Oben: Die reine Schleife nach den Setzen des Pull-ups, Debugger
angehalten (grün markiert) und in der Debug-Ausgabe der Peripherals die
Register-Einstellungen kontrolliert: TRISC.13 ist 1 und CNPUC.13 ist
ebenfalls 1. (ANSELC gibt's in diesem Prozessor nicht.)

Darunter: Meine verkürzte Schleife mit Oszi-Ausgabe. Die Verhaltensweise
ist identisch mit der vorher geschilderten: Wenn man dem Pin nur ein
bisschen hilft, "in die Hufe zu kommen", dann wird auch der Pull-up
aktiv.

Nicht gezeigt: Eine ebenso verkürzte Schleife mit Oszi-Ausgabe für Pin
22 (Port B9). Dort funktioniert alles völlig normal.

Im früheren Code hatte ich die Harmony-Library verwendet, jedenfalls
soweit es ging, denn die kennt die CNPU-Register nicht(!?!).
Library-Funktionen mag ich auch nicht, auch ich setzte die Register
lieber direkt, am liebsten in Assembler. Aber beim ARM mag ich mir
keinen Assembler 'reinziehen. Das Programm ist nicht von mir, ich
versuche nur, es zu modifizieren.

Sonderfunktionen (guter Tipp, hatte ich nicht geprüft):
Pin 47: SOSCI/RPC13/RC13
SOSCI: 32.768 kHz low-power oscillator crystal input; CMOS otherwise
RPC13: Output: RPC13R steht auf 0, also kein Output
       Input: U3RXR steht auf 0, also kein Input von RPC13

Beim SOSCI bin ich noch unsicher, denn ich weiß (noch) nicht, wie man
den disabled bzw. wann der die Funktion SOSCI statt IO bekommt. Aber
jetzt ist es spät. Morgen geht es weiter.

Und ein Dankeschön für deine Hilfe.

Uwe

von Dr. MIPS (Gast)


Lesenswert?

Uwe B. schrieb:
> Im früheren Code hatte ich die Harmony-Library verwendet, jedenfalls
> soweit es ging, denn die kennt die CNPU-Register nicht(!?!).
> Library-Funktionen mag ich auch nicht, auch ich setzte die Register
> lieber direkt, am liebsten in Assembler. Aber beim ARM mag ich mir
> keinen Assembler 'reinziehen. Das Programm ist nicht von mir, ich
> versuche nur, es zu modifizieren.


Was hat denn jetzt der ARM damit zu tun? Du verwirrst mich...

von Uwe B. (uwe_beis)


Lesenswert?

Ups, ja - der PIC32 kat keinen ARM, sondern einen MIPS Core. Sorry Dr. 
DOS, mein Fehler. Aber auch mit dessen Assembler mag ich mich nicht ohne 
Not beschäftigen.

von Uwe B. (uwe_beis)


Lesenswert?

Ich bin jetzt ein Schrittchen weiter. Ich suche jetzt nur noch die 
Ursache dafür, dass an den Pins 41 und 47 die Pull-ups die Spannung nur 
bis ca. 2.0V hoch ziehen, während der Pin 22 ganz normal auf auf knapp 
3.3V gezogen wird.

Aller anderen Beobachtungen lassen sich mit diesen 2.0V erklären, denn 
dass ist genau die Schwelle, bei der der interne Schmitt-Trigger high 
erkennt. Bei Pin 41 war es gerade ein bisschen darüber, deswegen hatte 
es sich dort "normal" verhalten, bei Pin 47 haben ein paar mV gefehlt, 
da hat nur ein ganz leichtes überlagertes Signal mit wenigen mV gefehlt, 
um die Schwelle zu überschreiten.

Ich habe für diesen Versuch den Pin 47 mit Spannung von 0 bis 3.3V 
versorgt. Bei 2.0V fließt kein Strom - logisch. Über 2.0V fließen ca. 
+15µA weitgehend konstant in den Pin, unter 2.0V steigt der Strom zuerst 
schnell, dann langsamer, auf ca. -280µA.

Es sieht so aus, als ob die Stromquelle, durch die der Pull-Up 
realisiert wird, an den Pins 41 und 47 nicht auf 3.3V, sondern auf ca. 
2V zieht. Bei Pin 22 sind es ja 3.3V. Das wäre sicherlich weder 
einstellbar noch gewollt. Designfehler? So einen fetten Designfehler 
halte ich für sehr unwahrscheinlich.

Auch, dass der Pull-up Strom auf allen 3 Pins nicht < 40µA, sondern 280 
µA ist, ist sehr suspekt.

Ich könnte jetzt mal die anderen Pins untersuchen.

von pull (Gast)


Lesenswert?

>Ich bin jetzt ein Schrittchen weiter. Ich suche jetzt nur noch die
>Ursache dafür, dass an den Pins 41 und 47 die Pull-ups die Spannung nur
>bis ca. 2.0V hoch ziehen, während der Pin 22 ganz normal auf auf knapp
>3.3V gezogen wird.

Gratuliere, schön für dich.
Aber was hast du verändert?

von Uwe B. (uwe_beis)


Lesenswert?

Verändert habe ich meinen Wissensstand. Das nenne ich ein Schrittchen 
weiter".

Neuster Verdacht: Spannungsversorgung, nicht alle VCC-Pins auf +3.3V. Da 
muss ich noch mal das Datenblatt mit der Schaltung abgleichen.

von pull (Gast)


Lesenswert?

DER Verdacht ist der beste bisher.

von Uwe B. (uwe_beis)


Lesenswert?

Hat sich aber leider nicht bestätigt. Alle 5 VDD-Pins und der der AVDD 
lt. Schaltung, Layout und nachgemessen gemäß dem Datenblatt auf +3.3V.

Das ist einer der Momente, wo man enttäuscht ist, keinen eigenen Fehler 
gefunden zu haben.

von WehOhWeh (Gast)


Lesenswert?

Das alles klingt sehr komisch.
Poste doch bitte mal deine Config, und welches Device das genau ist. In 
den Config kannst du auch den SOSC abschalten.

Hast du die RTCC an, oder einen Timer auf SOSC geschaltet?

Ansonsten:
Dein Problem ist so speziell (Verhalten weicht vom Datenblatt ab!), dass 
ich dir das Microchip-Forum empfehlen würde:
http://www.microchip.com/forums/
Mir wurde da schon öfter sehr kompetent geholfen.

Auch die "Erratas" wären einen Blick wert, schließlich ist das ein PIC32 
MZ ;-)

von Uwe B. (uwe_beis)


Lesenswert?

Ich weiß zwar immer noch nicht was los ist, bin wieder etwas weiter und 
habe jetzt eine Lösung, mit der ich leben kann. Aber zunächst:

WehOhWeh schrieb:
> Das alles klingt sehr komisch.
Weiß Gott, ja.

> Poste doch bitte mal deine Config, und welches Device das genau ist.
system_config.c oder die Configuration Bits? Es ist ein PIC32MZ mit 64 
Pins. Welche Variante davon ist lt. Datenblatt unerheblich, aber der 
Vollständigkeit halber: PIC32MZ2048ECH064.

> den Config kannst du auch den SOSC abschalten.
Das habe ich jetzt auch in den Configuration Bits gefunden. In der Doku 
der IO-Ports hätte ich auch einen fetten Hinweis darauf erwartet, aber 
nichts gesehen. Vielleicht übersehen.

Mein Pin 47 ist es offensichtlich tatsächlich als Oscillator Input 
konfiguriert. Die Configuration-Bits sind aber offensichtlich nicht 
einfach durch einen Clr/Set-Befehl zu verändern, dazu kommt ein zweiter 
Grund, aus dem ich Pin 47 nicht mehr verwenden werde.

> Hast du die RTCC an, oder einen Timer auf SOSC geschaltet?
Nein, SOSC wird nicht gebraucht. Mehr dazu gleich.

> Ansonsten:
> Dein Problem ist so speziell (Verhalten weicht vom Datenblatt ab!), dass
> ich dir das Microchip-Forum empfehlen würde:
> http://www.microchip.com/forums/
> Mir wurde da schon öfter sehr kompetent geholfen.
Du hast recht, das ist etwas für das Forum. Aber erst mal wollte ich 
meine "dummen" Fehler vermeiden.

Ich habe weiter experimentiert:
Ich habe jetzt alle freien IO-Pins - das ist die Mehrzahl der 
vorhandenen - als Input mit Pull-up konfiguriert, und zwar sofort nach 
Programmbeginn, also gleich am Anfang von main.c. Was vor main.c läuft 
weiß ich nicht, danach sind jedenfalls alle Bits in den IO-Registern wie 
"befohlen". Nach dieser IO-Konfiguration läuft der µC in einer Schleife 
auf der Stelle. Es gibt bei diesem Experiment keine system_config.c 
mehr.

Dann untersuche ich mit dem Oszi die elektrischen Eigenschaften aller so 
konfigurierten Ports. Fazit: Es gibt im Wesentlichen 2 Verhaltensweisen:

1. Normal: Der Pull-up zieht bis knapp 3.3V. Spannungen über 3.3V, die 
von außen angelegt werden, erzeugen Ströme, die in den Pin fließen. 
Dieses normale Verhalten zeigen alle Pins des Ports B.

2. Nicht normal: Der Pull-up zieht bis etwas über 2.0V. Spannungen über 
2.0V bis hin zu mindestens 5V, die von außen angelegt werden, erzeugen 
keinen Ströme, die in den Pin fließen. Dieses anormale Verhalten zeigen 
alle Pins der anderen Ports.

Kleine Ausnahme, aber kein Wunder: Weil die 4 Oszillator-Pins nach wie 
vor als solche konfiguriert sind, verhalten sie sich auch entsprechend.

Nach wie vor ist auf allen Pins der Strom aus den Pull-ups nicht max. 
40µA, sondern ca. 280µA.

Mit diesen Erkenntnissen habe ich mich jetzt entschlossen, nur noch Pins 
des Ports B für meine Zwecke zu verwenden und Schaltung und Layout 
geändert. Ich bin sicher, dass das zuverlässig funktionieren wird, aber 
es wurmt mich, nicht zu wissen, was mit den anderen Ports los ist.

> Auch die "Erratas" wären einen Blick wert, schließlich ist das ein PIC32
> MZ ;-)
Auch richtig. Wäre nicht das erste Mal...

Ich danke auch dir.

Uwe

von Stampede (Gast)


Lesenswert?

Hallo,

das Verhalten ist im Datenblatt mehr oder minder so beschrieben, Tabelle 
37-9, Parameter DI30, DI31 und DI50. Der Pullup/Down Current ist max. 
40µA, die normalen Pins haben einen Leakage current von max. +-1µA. 
Alles gut also. Dann gibts da noch ein paar Spezialisten (SOSCI, SOSCO, 
USBID) die bis zu +-500µA an Leckstrom haben können. Das reicht dann für 
den IO nicht mehr. Und der Pin 47 an den 64Pin PIC32MZ ist das nun mal 
einer dieser o.g.

Grüße
Stampede

von Uwe B. (uwe_beis)


Lesenswert?

Hallo Stampede,

> das Verhalten ist im Datenblatt mehr oder minder so beschrieben, Tabelle
> 37-9, Parameter DI30, DI31 und DI50. Der Pullup/Down Current ist max.
> 40µA, die normalen Pins haben einen Leakage current von max. +-1µA.
Da habe ich meine Information auch her.

> Alles gut also.
Das verstehe ich nicht. Auf allen IO-Pins ist der Strom aus dem 
Pull-up bei mir ca. 280µA, das ist "mehr" als 40µA!?!

> Dann gibts da noch ein paar Spezialisten (SOSCI, SOSCO,
Der SOSCI verhält sich genau so, wie alle anderen IOs außer denen von 
Port B. Es ist ja auch ein Eingang. Am SOSCO habe ich alledings 
festgestellt, das der Oszillator an den Pins aktiviert ist und vermeide 
ihn zum Einen deshalb, und zum Anderen weil die Pullups nur bis 2V 
gehen, jetzt.

Nebenbei: Ich habe erkannt, dass alle 4 Pins des Port C an die beiden 
Oszillatoren gebunden und nicht ganz so einfach als IO verwendbar sind. 
Am CLKO (Pin 32) ist das am schnellsten zu erkennen, denn der gibt das 
Signal des externen Oszillators aus.

> USBID) die bis zu +-500µA an Leckstrom haben können.
Die 500µA habe ich nicht gefunden. USBID habe ich vermutlich auch 
getestet und als "wie die anderen" befunden.

> Das reicht dann für
> den IO nicht mehr. Und der Pin 47 an den 64Pin PIC32MZ ist das nun mal
> einer dieser o.g.
Das hatte ich ja dann auch erkannt. Wie gesagt, als SOSCI hat er sich 
ja, im Gegensatz zum SOSCO, auch wie ein "normaler anormaler" Eingang 
verhalten.

Grüße, Uwe

von Stampede (Gast)


Lesenswert?

Uwe B. schrieb:
>> Alles gut also.
> Das verstehe ich nicht. Auf allen IO-Pins ist der Strom aus dem
> Pull-up bei mir ca. 280µA, das ist "mehr" als 40µA!?!

Ja, und das steht doch auch so im Datenblatt!

Zur Erklärung: Im Datenblatt (Tabelle 37-9) steht (Note 3) "Negative 
current is defined as current sourced by the pin."

Dann:
DI30 ICNPU Change Notification  Pull-up Current -40µA, VDD = 3.3V, VPIN 
= VSS (Note 3,6)

Das heißt also, dass wenn du den Pin auf Masse legen würdest ein Strom 
von max. -40µA (!!!) herausfließen, oder auch ein kleinerer Wert. Das 
heißt, es könnten auch -100µA sein oder wie bei dir sogar -280µA. Und 
das entspricht genau dem, was du misst.
Die "normalen" IOs mit nur +-1µA leakage current bekommt man damit immer 
definiert auf Potential gezogen, bei den drei Spezialpins (SOSCx und 
USBID) eben nicht, da die mit max. +-500µA spezifiziert sind.
Und genau das sehen wir bei dir in der Schaltung.

Weiter heisst es (Note 6):
The VIH specifications are only in relation to externally applied 
inputs, and not with respect to the userselectable
internal pull-ups. External open drain input signals utilizing the 
internal pull-ups of the PIC32
device are guaranteed to be recognized only as a logic “high” internally 
to the PIC32 device, provided that
the external load does not exceed the minimum value of ICNPU. For 
External “input” logic inputs that require
a pull-up source, to guarantee the minimum VIH of those components, it 
is recommended to use an
external pull-up resistor rather than the internal pull-ups of the PIC32 
device.

Ob das bei dir nun zutrifft oder nicht, muss du selbst herausfinden.

Grüße
Stefan

von Uwe B. (uwe_beis)


Lesenswert?

Ich wollte gerade deiner Meinung widersprechen, als es mir wie Schuppen 
aus den Haaren fiel: Ich wäre nicht sicher, ob der Autor unter maximal 
bei einer negativen Zahl tatsächlich die korrekte mathematische 
Definition versteht*, außerdem war ich von anderen ICs kleinere Ströme 
gewöhnt, aber in der nächsten Zeile wird es sonnenklar: Pull-down 
current minimal 40µA. Keine Fragen, kein Zweifel mehr.

Bezüglich Note 6: Außer Port B werden alle anderen Port-Pins nur auf ca. 
2V gezogen, nicht nur SOSCI. Dort liegt auch die gemessene Schwelle zur 
Erkennung von high. Lt. Datenblatt ist nicht spezifiziert, wie hoch die 
Pull-ups ziehen, und wenn sie es bei Port C, D, E und F nur bis 2V tun, 
dann brauche ich einen externen Pull-up. Das ist absurd, aber meine 
Erkenntnis. Auch noch einmal der Hinweis, dass bei Port B alle Pins bei 
Spannungen über 3.3V Strom aufnehmen, bei allen anderen Ports bei 
Spannungen über 2V hochohmig sind(!). Es sieht etwas wie 
Open-Collector aus, aber die Einstellung hat keinen Einfluss. Auch 
betrifft es nicht die 5V-toleranten Eingänge. Ich sehe kein System, 
warum nur der Port B sich so verhält, wie ich erwarte.

Nebenbei, auch wenn es nicht wichtig ist: Ich habe gesucht und nicht 
gefunden: Wo hast du die Angabe von 500µA her?

* Anmerkung: Auch an anderen Stellen wird es nicht so genau mit der 
korrekten mathematischen Definition genommen. Wo der Leckstrom mit max. 
+-1µA angeben wird, hätte es min. -1µA und max. +1µA heißen müssen. 
Ähnlich bei Figure 38: Bei IOH hätte es dann "Absolute Minimum" heißen 
müssen. Ich glaube nicht, dass sich jeder immer an solche Vereinbarungen 
hält, verzeih' mir daher meine ursprünglich Skepsis bzgl. der 40µA.

: Bearbeitet durch User
von Stampede (Gast)


Lesenswert?

Hi,

Uwe B. schrieb:
> Ich wollte gerade deiner Meinung widersprechen, als es mir wie Schuppen
> aus den Haaren fiel: Ich wäre nicht sicher, ob der Autor unter maximal
> bei einer negativen Zahl tatsächlich die korrekte mathematische
> Definition versteht*, außerdem war ich von anderen ICs kleinere Ströme
> gewöhnt, aber in der nächsten Zeile wird es sonnenklar: Pull-down
> current minimal 40µA. Keine Fragen, kein Zweifel mehr.

Uwe B. schrieb:
> Nebenbei, auch wenn es nicht wichtig ist: Ich habe gesucht und nicht
> gefunden: Wo hast du die Angabe von 500µA her?

DI50, folgende Seite im Datenblatt ( 
http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en566815 
)

Uwe B. schrieb:
> Bezüglich Note 6: Außer Port B werden alle anderen Port-Pins nur auf ca.
> 2V gezogen, nicht nur SOSCI. Dort liegt auch die gemessene Schwelle zur
> Erkennung von high. Lt. Datenblatt ist nicht spezifiziert, wie hoch die
> Pull-ups ziehen, und wenn sie es bei Port C, D, E und F nur bis 2V tun,
> dann brauche ich einen externen Pull-up

Ich verstehe das so: Wenn du die als OC Eingänge mit Pullups einstellst, 
wird garantiert dass dies als Highpegel erkannt wird, insofern diese 
externe Quelle den Pullup-Strom nicht irgendwie "wegfrisst". Danach 
sollte es egal sein, ob da nun 2,0V oder mehr anliegen. Ich gebe zu, das 
ist ein wenig verwirrend.

Uwe B. schrieb:
> uch noch einmal der Hinweis, dass bei Port B alle Pins bei
> Spannungen über 3.3V Strom aufnehmen, bei allen anderen Ports bei
> Spannungen über 2V hochohmig sind(!).

Verstehe ich nicht. Hochohmig sollten doch alle sein. Und warum mehr als 
3,3V? Dann greifen doch ohnehin die Clampingdioden.

Grüße
Stefan

von Uwe B. (uwe_beis)


Angehängte Dateien:

Lesenswert?

Stampede schrieb:
>> Nebenbei, auch wenn es nicht wichtig ist: Ich habe gesucht und nicht
>> gefunden: Wo hast du die Angabe von 500µA her?
>
> DI50, folgende Seite im Datenblatt (
> http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en566815
> )
Auch auf die Gefahr hin, mich zu blamieren: Ich finde auf der Seite 
keine solche Angabe. Damit wir nicht aneinander vorbei reden, habe ich 
einen Screenshot gemacht. Es gibt die Angaben des Injection Currents 
(5mA), muss aber zugeben, dass ich nicht weiß, was das sein soll. 
Welcher Strom wird da von wem injiziert? Ist das ein maximal zulässiger 
Strom, der in die Pins eingespeist werden darf, und der der m. E. 
eigentlich zu den Absolute Maximum Ratings gehört? Dort finde ich 
wiederum tatsächlich keine passende Angabe, hätte sie aber erwartet.

Stampede schrieb:
> Ich verstehe das so: Wenn du die als OC Eingänge mit Pullups einstellst,
Die Port-Pins sind als Eingänge (TRISx = 1) mit Pull-up (CNPUx = 1) 
eingestellt. Es ist egal, wie dabei ODC einstellt ist (ODCx = X). Alle 
Eingänge haben Schmitt-Trigger und die gemessenen Schaltschwellen liegen 
bei ca. 2V und 1V.

Wenn ich mit dem Oszi/Multimeter die Spannung an den unbeschalteten 
Eingänge messe, messe ich ca. 3.3V an Port-Pins B und ca. 2V an allen 
anderen Port-Pins (Ausnahme: Einige der Spezial-Pins). Wenn ich über 
einen hochohmigen Widerstand z. B. 5V auf den Eingang gebe, messe ich 
wieder ca. 3.3V an Port-Pins B aber ca. 5V an allen anderen Port-Pins. 
Kein Clamping! Es ist so, als wenn der Pull-up-FET an Port B direkt, und 
an den anderen Ports über zwei in Reihe geschalteten Dioden 
angeschlossen ist.

Ich hoffe, dass ich diese Kennlinien verständlich beschrieben habe, 
könnte sie aber noch einmal skizzieren.

Ja, das ist sehr, sehr merkwürdig. Und ich kann mir nicht vorstellen, 
irgendetwas falsch gemacht zu haben. Und wenn doch: Wie könnte man diese 
Verhaltensweise provozieren? Aber dass ein so dicker Bug im Prozessor 
ist, kann ich mir noch weniger vorstellen.

Grüße, Uwe

von Stampede (Gast)


Lesenswert?

Uwe B. schrieb:
> Auch auf die Gefahr hin, mich zu blamieren: Ich finde auf der Seite
> keine solche Angabe. Damit wir nicht aneinander vorbei reden, habe ich
> einen Screenshot gemacht. Es gibt die Angaben des Injection Currents
> (5mA), muss aber zugeben, dass ich nicht weiß, was das sein soll.
> Welcher Strom wird da von wem injiziert?

Seite 572, Tabelle 37-9, DI50.
Der Injection current ist was ganz anderes, der gibt an wieviel Strom du 
durch die internen Clamping Dioden jeagen kannst bevor da was kaputt 
geht.

von Uwe B. (uwe_beis)


Lesenswert?

Stampede schrieb:

> Seite 572, Tabelle 37-9, DI50.
Tatsächlich. Da muss ich zu meiner Entlastung erklären, dass ich zuerst 
mit einer älteren Ausgabe des Datenblatts (DS60001191C) gearbeitet 
hatte, wo DI50 noch mit +-1µA spezifiziert war. Ich hatte aber extra 
wegen deiner Aussage das neue Datenblatt (DS60001191E) ebenfalls geladen 
und auch dort gesucht. U. a. habe ich den gesamten Text nach "500" 
durchsucht, ohne Ergebnis. Hatte ich, in der Meinung die neue Version zu 
durchsuchen, doch die ältere verwendet??? Scheint so. Egal.

> Der Injection current ist was ganz anderes, der gibt an wieviel Strom du
> durch die internen Clamping Dioden jeagen kannst bevor da was kaputt
> geht.
Wie ich vermutete: Das gehört also in die Absolute Maximum Ratings. Da 
hätte ich es sofort verstanden. Bei den Characteristics ist es 
irreführend.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.