Guten Morgen,
I2C-Portexpander und uC haben meistens einen eingebauten Power On Reset
und oft funktioniert der auch. Hier geht es um Chips, bei denen er
wirklich nur beim Einschalten funktioniert, also z.B. im Bereich VDD = 0
bis VDD = 2.9V. In der umgekehrten Richtung ist die Schaltschwelle
undefiniert, im Datenblatt steht dann etwas wie "VDD muss kleiner als
0.3V werden".
Das ist ok, wenn es auch einen Brown Out Reset und/oder einen Reset-Pin
gibt. Wenn beides fehlt, muss man für einen zuverlässigen Reset VDD
abschalten und warten, bis die Elkos entladen sind. Bei einem richtigen
Stromausfall ergibt sich das von alleine, bei einer sehr kurzen
Unterbrechung braucht man keinen Reset.
Aber was tut man gegen kurze Unterbrechungen, bei denen VDD nur bis 1.x
Volt abfällt und manche Bits umkippen und andere nicht? Hoffen, dass
jemand in der Nähe ist, der aus- und einschaltet? Hoffen, dass das
selten genug passiert ("jedes Gerät geht mal kaputt")?
Der traurige Anlass für diese Frage sind die PIC32MK, siehe Bild. Die
haben zwar einen MCLR-Pin, aber ob der als POR wirkt, ist per Fuse im
EEPROM einstellbar. Mit VDD unter 2.x Volt kann das nicht funktionieren.
Angehängte Dateien:
-
PIC32MK-Reset.png
67 KB
Du willst den i2c-Bus resetten, weil Master und Slave außer Synchronität sind? Dafür gibt's eine spezielle Sequenz.
http://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf Gruss Chregu
Abdul K. schrieb: > Du willst den i2c-Bus resetten, weil Master und Slave außer > Synchronität sind? Dafür gibt's eine spezielle Sequenz. Meine I2C Chips hatten bisher immer einen Reset-Pin, aber bei den PIC32M resettet der MCLR-Pin weniger als ein POR. Wenn ich das Datenblatt wörtlich nehme, werden die SFR nur vom POR resettet. Der Pin ist also nutzlos. Als Würgaround fällt mir nur ein, den 3.3V-LDO mit einem LM809 abzuschalten, und zu hoffen, dass die Elkos rechtzeitig leer sind. Bei den PIC32MX ist die Lage mit VDDmin <1.7V entspannter als bei den PIC32MK mit VDDmin <0.3V. Aber ohne Tricks geht es auch da nicht. Trotzdem danke für die I2C Appnote.
:
Bearbeitet durch User
Bauform B. schrieb: > Aber was tut man gegen kurze Unterbrechungen, bei denen VDD nur bis 1.x > Volt abfällt VDD wegschalten, z.B. durch Inhibit vom Spannungsregler.
Angehängte Dateien:
Nächster Versuch, nachdem es anscheinend keine fertige Lösung gibt. Rainer W. schrieb: > VDD wegschalten Ja, ein uC kann z.B. einen Port Expander abschalten. Aber wenn der uC selbst das Problemkind ist? In dem Fall müssen auch deutlich mehr als 100nF bis auf Null entladen werden, das dauert mir viel zu lange. Vor allem, weil es bei jedem Einschalten so lange dauert (oder extrem aufwendig wird). Also müssen die Elkos aktiv entladen werden. Das kostet 2 Transistoren, 3 Widerstände, einen 100nF und einen 5V-Regler: TLS810D1EJV50. Damit kommt man auf 12 bis 42ms unnötige Verzögerung beim Einschalten. Soviel Zeit muss wohl sein. Die Schaltung sieht unglaublich kompliziert aus, aber ein Drittel ist die Nachbildung vom TLS810 und ein Drittel die 3.3V mit Verbraucher. 5V kann man immer mal gebrauchen, also beschränkt sich der Aufwand auf die Bestellung des TLS810. Der 3.3V-Regler ist nichts spezielles, der muss nur einen hochohmigen Enable haben. R6 könnte man noch weglassen, der maximale Entladestrom wird sowieso durch R2 und die Q3-Stromverstärkung begrenzt. Die LED (oder ein Lastwiderstand) ist nötig, damit C4 entladen wird. C2 bestimmt die Pausendauer, hier 100n -20%.
Bauform B. schrieb: > Wenn ich das Datenblatt > wörtlich nehme, werden die SFR nur vom POR resettet. Der Pin ist also > nutzlos. Wie kommst Du darauf. Alle Resetquellen gehen auf SYSRST, bewirken also genau das gleiche. Nur die Flags, die die Resetquelle anzeigen, werden natürlich unterschiedlich gesetzt.
Bauform B. schrieb: > aber bei den PIC32M resettet der MCLR-Pin weniger als ein POR. > Wenn ich das Datenblatt wörtlich nehme, werden die SFR nur vom POR > resettet. Der Pin ist also nutzlos. Warum musst du die SFR auf die Defaultwerte zurücksetzen? Du bekommst doch den MCLR-Interrupt und kannst dann die Register in der Software allesamt auf die für deine SW nötigen nötigen Werte konfigurieren. Bauform B. schrieb: > Nächster Versuch, nachdem es anscheinend keine fertige Lösung gibt. Mir scheint eher, du baust da grade einen Holzhammer für die Holzhammermethode. Peter D. schrieb: > Alle Resetquellen gehen auf SYSRST, bewirken also genau das gleiche. Mit einem kleinen Dreizeiler könnte man das sogar schnell mal verifizieren, statt lange am Holzhammer herumzuschnitzen...
:
Bearbeitet durch Moderator
Peter D. schrieb: > Bauform B. schrieb: >> Wenn ich das Datenblatt >> wörtlich nehme, werden die SFR nur vom POR resettet. Der Pin ist also >> nutzlos. > > Wie kommst Du darauf. Alle Resetquellen gehen auf SYSRST Ja, in dem Bild im Reset-Kapitel. Da steht aber auch "vereinfachte Darstellung" dabei. Was mich zweifeln lässt: - Es gibt die SMCLR Fuse, die die MCLR-Funktion umschaltet. Damit man die lesen kann, braucht das Flash ordentliche Betriebsspannung und Takt. Beides hat man zur POR-Zeit noch nicht. Ein Henne und Ei Problem. - bei den Registerbeschreibungen steht ausdrücklich nur "POR" - es gibt aber Bemerkungen mit MCLR und POR, z.B. "The RTCALRM register is reset on a MCLR or Power-on Reset (POR)." - Microchip Dokumentation kommt mir allgemein etwas chaotisch vor.
Lothar M. schrieb: > Bauform B. schrieb: >> aber bei den PIC32M resettet der MCLR-Pin weniger als ein POR. >> Wenn ich das Datenblatt wörtlich nehme, werden die SFR nur vom POR >> resettet. Der Pin ist also nutzlos. > Warum musst du die SFR auf die Defaultwerte zurücksetzen? Du bekommst > doch den MCLR-Interrupt und kannst dann die Register in der Software > allesamt auf die für deine SW nötigen nötigen Werte konfigurieren. MCLR ist total ok für z.B. einen Reset-Taster. Im normalen Betrieb funktioniert das natürlich, egal, ob einzelne Register zurück gesetzt werden oder nicht, alles kein Problem. Mir geht es um den kurzen Netzausfall, bei dem VDD bis z.B. 1V absinkt. Das ist wenig genug, damit Bits umkippen, aber damit der POR funktioiert, müsste VDD kleiner als 0.3V werden. Beim PIC32MM...GPM steht sogar 100mV im Datenblatt. Normalerweise würde man einen LM809 an MCLR anschließen, aber der Sache traue ich eben nicht.
Ich verstehe das Problem nicht. Der MC hat doch ein BOR, also braucht man das doch nur zu enablen. Damit ist festgelegt, ab welcher Spannung der MC in Reset geht, d.h. angehalten wird. Das BOR hat auch eine Hysterese, d.h. die Spannung muß wieder um einen bestimmten Betrag steigen, damit er das Reset verläßt.
Peter D. schrieb: > Der MC hat doch ein BOR, also braucht man das doch nur zu enablen. Aber wie? Ich finde kein BOR Enable Bit. Wenn es eins gibt, gilt für BOR das gleiche wie für MCLR. Na gut, nehmen wir an, BOR wäre immer aktiv, das wäre ja noch besser. > Damit ist festgelegt, ab welcher Spannung der MC in Reset geht, > d.h. angehalten wird. Nicht wirklich, die Schaltschwelle wird auch per Fuse eingestellt. Vor allem: wenn VDD unter diese Schwelle sinkt, gibt es einen sauberen Reset. Sehr gut, aber anschließend sinkt VDD weiter und die ganze Logik kommt in einen undefinierten Zustand. > Das BOR hat auch eine Hysterese, d.h. die Spannung muß wieder um > einen bestimmten Betrag steigen, damit er das Reset verläßt. Wenn das funktionieren würde und die gleiche Wirkung hätte wie ein POR, wäre einer von beiden überflüssig. Wenn wenigstens einer von beiden ein einfacher Komparator mit echter Referenz wäre, gäbe es z.B. im Bereich von 1.5V < VDD < 2.5V einen echten Reset. Die Einschränkung "VDD muss praktisch Null werden" wäre dann unnötig. Im Kapitel Getting Started gibt es einen Hinweis, dass der uC über die Eingangsschutzdioden versorgt werden könnte. Soweit ganz normal, aber: "...it can also negatively affect the internal Power-on Reset (POR) and Brown-out Reset (BOR) circuits, which can lead to improper initialization of internal PIC32 logic circuits." Im Reference Manual, Kapitel 7, gibt es ein Argument, warum MCLR nur für Reset-Taster u.ä. taugt: "BOR, MCLR and WDTO resets are asynchronous events, and to avoid SFR and RAM corruptions, the system reset is synchronized with the system clock. All other reset events are synchronous." Auch nett: Im RCON Register gibt es zu den Bits BOR und POR eine Anmerkung (2), aber keine Erklärung, was damit gemeint ist.
Bauform B. schrieb: > Der traurige Anlass für diese Frage sind die PIC32MK Was war denn traurig, sind die hängen geblieben oder ist das nur eine Vermutung von Dir? Ich hab nicht sämtliche Doku zum PIC32 durchgelesen, warum es da Probleme geben sollte. Die PIC32 gibt es ja schon recht lange. Falls Probleme mit dem Reset aufgetreten sein sollten, dürften die inzwischen gefixt sein oder mindestens ein Errata veröffentlicht worden sein. Ich setze die AVRs ein und da funktioniert das Brown-Out bisher einwandfrei. Über Fusebits wird es aktiviert und die Spannung ausgewählt. Die ersten AVRs hatten definitiv Probleme mit dem Reset. Ich hatte damals Haakon Skar gleich gesagt, ein simples Zeitglied ohne Spannungskomparator reicht nicht, aber er hat nur abgewinkt. Erst mit den Atmega hat Atmel nachgebessert. Ich hatte sogar schon ein Gerät mit einem AT90Sxx gebaut. Beim abschließenden Test mit 10 mal Netzschalter ein/aus, blieb er beim 10. mal hängen. Ab in die Tonne. (nichtmal ein MAX690 am Reset-Pin hat geholfen).
Abdul K. schrieb: > Du willst den i2c-Bus resetten, weil Master und Slave außer Synchronität > sind? Dafür gibt's eine spezielle Sequenz. Die allerdings (je nach Idiotie der Slave-Implementierung) keinesfalls immer funktioniert. Ich kenne inzwischen einen ganzen Arsch voll I2C-Slaves (mindestens 30 verschiedene ICs (bzw. IC-Familien)), die man allein durch das Geschehen auf SDA/SCL in Zustände schicken kann, aus denen sie nur mittels Power-Cycle wieder befreit werden können. Anders ausgedrückt: 1) Traue absolut keinem I2C-Chip, der keinen Reset-Pin hat. 2) Wenn alle einen haben, siehe einen Bus-Reset darüber vor. 3) Wenn auch nur einer keinen hat, siehe einen Power-Cycle für den gesamten Bus als Reset vor. Leider führt das typisch oft zu erheblichen Folgekosten im Gesamtdesign.
Na dann liste mal auf. Wir wollen alle von dir lernen. Daraus hatte Intel gelernt und beim smBus einen time-out eingeführt. Philips hat leider nie ein Referenzdesign für einen Slave veröffentlicht.
Abdul K. schrieb: > Daraus hatte Intel gelernt und beim smBus einen time-out eingeführt. Nützt nur rein garnix, wenn der generische I2C-Slave davon nix weiss und die SCL-Leitung durch Dauer-Low blockiert. Das ist aber zum Glück ein eher seltener Fehler. Sehr viel häufiger ist das Problem, dass die interne Logik der Slaves auf höherer Ebene durcheinander kommt. D.h.: man kann zwar den Bus wieder "freimachen", aber zumindest der abgekackte Slave bleibt effektiv tot. Da man aber nur eher selten redundante Slaves einbaut (also welche, auf deren Dienste man in der konkreten Anwendung auch verzichten könnte) führt das letztlich auch nur dazu, dass die Anwendung nicht mehr wie vorgesehen funktionieren kann...
Eine perfekte Lösung wird es nicht geben. Man kann es nur oft deutlich besser implementieren. Aber wer hat dafür Zeit, wenn der BWLer schon unruhig wird, weil er dein Werk schon verkaufte ohne irgendwas in Händen zu haben. Kennste doch! --- Übrigens ein grundsätzliches Problem jedweder Kommunikation.
Peter D. schrieb: > Bauform B. schrieb: >> Der traurige Anlass für diese Frage sind die PIC32MK > > Was war denn traurig, sind die hängen geblieben oder ist das nur eine > Vermutung von Dir? Das hängen bleiben will ich von vornherein vermeiden. Ich baue doch keine Platine nach dem Motto "wird schon funktionieren". Das Datenblatt zum PIC32MK erwähnt diese negative Eigenschaft an mindestens 2 Stellen. Deswegen vermute ich, dass das stimmt. Sowas schreibt ja niemand freiwillig ins Datenblatt.
1 | DS60001519E, Abschnitt 2.9 |
2 | Without proper signal isolation, on non-5V tolerant pins, the remote |
3 | signal can power the PIC32 device through the high side ESD protection |
4 | diodes. Besides violating the absolute maximum rating specification |
5 | when VDD of the PIC32 device is restored and ramping up or ramping |
6 | down, it can also negatively affect the internal Power-on Reset (POR) |
7 | and Brown-out Reset (BOR) circuits, which can lead to improper |
8 | initialization of internal PIC32 logic circuits. |
1 | DS60001519E, Tabelle 37-4 |
2 | DC16 VPOR VDD Start Voltage — — Max. Vss + 0.3V |
3 | to Ensure Internal |
4 | Power-on Reset Signal(3) |
5 | Non-compliance can cause |
6 | indeterminate behavior |
7 | DC17 SVDD VDD Rise Rate 0.000011 — 0.33 V/μs |
8 | to Ensure Internal |
9 | Power-on Reset Signal |
10 | |
11 | Note 3: This is the limit to which VDD must be lowered |
12 | to ensure Power-on Reset. |
Beim PIC32MM ist VPOR max. sogar nur 100mV, der BOR ist per Fuse einstellbar, und es gibt Bemerkungen, dass MCLR nur manchmal ein echter Reset ist:
1 | Note: When MCLR is used to wake the device from Retention Sleep, |
2 | a POR Reset will occur. |
3 | Note: These bits are only reset by a Power-on Reset (POR) and are |
4 | not affected by other Reset sources. |
> Die PIC32 gibt es ja schon recht lange. Falls Probleme mit dem > Reset aufgetreten sein sollten, dürften die inzwischen gefixt > sein oder mindestens ein Errata veröffentlicht worden sein. So alt wie der PIC32MZ ist der MK nicht, allerdings gibt es schon eine 2. Generation davon. PIC32MM scheint wirklich neu zu sein. Aber egal, das ist ja per Definition kein Bug, wenn es im Datenblatt genau erklärt ist. > Ich hatte sogar schon ein Gerät mit einem AT90Sxx gebaut. Beim > abschließenden Test mit 10 mal Netzschalter ein/aus, blieb er beim 10. > mal hängen. Ab in die Tonne. (nichtmal ein MAX690 am Reset-Pin > hat geholfen). Genau das erwarte ich auch bei den PIC32, also spendiere ich ein paar Bauteile extra.
C-hater schrieb: > 1) Traue absolut keinem I2C-Chip, der keinen Reset-Pin hat. > 2) Wenn alle einen haben, siehe einen Bus-Reset darüber vor. > 3) Wenn auch nur einer keinen hat, siehe einen Power-Cycle > für den gesamten Bus als Reset vor. Genau so, bis auf 3) Wenn auch nur einer keinen hat, nimm einen anderen Chip Abdul K. schrieb: > Man kann es nur oft deutlich besser implementieren. Aber wer hat > dafür Zeit, wenn der BWLer schon unruhig wird, weil er dein Werk > schon verkaufte ohne irgendwas in Händen zu haben. Ja ABER? Erst dann weißt du doch, was du bauen musst ;)
Bauform B. schrieb: > Genau so, bis auf > 3) Wenn auch nur einer keinen hat, nimm einen anderen Chip Das wäre dann ein Splitting der Optionen. Also in der Systematik besser so darstellbar: 3)a) Wenn auch nur einer keinen hat, nimm einen anderen Chip 3)b) Wenn auch nur einer keinen hat, siehe einen Power-Cycle für den gesamten Bus als Reset vor. Was letzlich besser ist, findet man anhand von Beschaffbarkeit und Preis heraus. Das Problem ist hier: Das ist eigentlich nicht der Job des Enwtwicklers, sondern der Job der Einkäufer... Aber genau hier zeigt sich dann das Problem der arbeitsteiligen Gesellschaft in ganzer Härte... Einfach ist das nur, wenn man Enwickler und Beschaffer in Personalunion ist.
Sehr oft liegt es einfach nur an der richtigen Flankensteilheit von VCC. Insbesondere hartes Anklemmen an Labornetzteil vs. Seriennetzteil.
C-hater schrieb: > Nützt nur rein garnix, wenn der generische I2C-Slave davon nix weiss und > die SCL-Leitung durch Dauer-Low blockiert. Der generische Slave hat SCL nur als Eingang, kann also SCL nicht blockieren. Selbst wenn er beschäftigt ist, stellt er sich einfach tot (NACK), z.B. EEPROMs beim Schreiben. Der Master kann derweil andere Slaves bedienen. Ist ein Slave als Sender adressiert, kann er SDA auf low ziehen. Macht der Master dann einen CPU-Reset, weiß er das nicht mehr. Nach einem Reset sollte der Master den Bus prüfen und bei Bedarf bis zu 9* SCL takten und der Bus ist wieder frei. Blockieren können ausnahmslos nur Slaves, die in Software mit einem MC realisiert sind. Dann ist es pure Doofheit des Programmierers, wenn er kein Timeout vorgesehen hat, um den Bus freizugeben. Insbesondere die AVRs haben als Slave oder Multimaster einen Bug, der den Bus blockieren kann. Mit Philips/NXP-MCs (80C51) hatte ich dagegen nie Probleme. Schade, daß NXP die eingestampft hat. Es gibt zwar Nachbauten von Atmel/Tekmos, deren I2C ist aber auch buggy.
Abdul K. schrieb: > Philips hat leider nie ein Referenzdesign für einen Slave > veröffentlicht. Ausführlicher als im 80C552 Datenblatt (Data Handbook IC20) gehts nun wirklich nicht. Zusätzlich gibt es noch in den Application Notes Beispielcode in Assembler. Atmel hat das I2C von Philips in seinen 89C51 und AVR nachentwickelt (identische Statemaschine), aber wohl nicht alle Funktionen richtig verstanden und getestet.
Bauform B. schrieb: > Without proper signal isolation, on non-5V tolerant pins, the remote > signal can power the PIC32 device through the high side ESD protection > diodes. Das ist bei (fast) allen MCs der Fall. Ich hatte mich mal gewundert, warum ein AVR keinen Reset gemacht hat. Des Rätsels Lösung war, er wurde über die UART-Pins mit VCC versorgt. Eine Diode und Pullup rein und das Problem war gelöst. Es gibt aber auch Treiber-ICs, die ohne VCC in beide Richtungen sperren.
:
Bearbeitet durch User
Peter D. schrieb: > Der generische Slave hat SCL nur als Eingang, kann also SCL nicht > blockieren. Das glauben nur Vollidioten. Clockstretching ist von Anbeginn der Zeit Teil der I2C-Specs. Dementprechend natürlich auch aktiver Zugriff der Slaves auf SCL (wie sonst sollte das schließlich bewirkt werden?). Wenn du nichmal das in all den vielen Jahren begriffen hast, bist du schlicht keine Diskussionspartner für mich. Und jeder sollte dein Geschwalle geflissentlich als vollkommen nutzloses Gesabbel eines nachweislich vollkommen Inkompetenten ignorieren. So einfach ist das eigentlich...
C-hater schrieb: > Das glauben nur Vollidioten. Wenn Du unfähig bist, Datenblätter zu lesen, dann ist das kein Grund, andere zu beschimpfen. C-hater schrieb: > Clockstretching ist von Anbeginn der Zeit > Teil der I2C-Specs. Nur für MCs als Slave, weil die Zeit brauchen, um in den Interrupthandler zu springen. Generische Slaves haben aber das I2C komplett in Hardware. Schau einfach mal ins Datenblatt des 24C02, PCF8574, PCF8591, DS3231, AD5665 usw., da ist SCL eindeutig nur Eingang. Natürlich gibt es I2C-Slaves, die mit einem MC mit ROM-Code realisiert sind. Dann steht aber auch eindeutig im Datenblatt drin, daß SCL ein open-drain Ausgang ist oder als Ausgang konfiguriert werden kann.
:
Bearbeitet durch User
Peter D. schrieb: > Ausführlicher als im 80C552 Datenblatt (Data Handbook IC20) gehts nun > wirklich nicht In welchem Datenblatt soll dies genauer erklärt sein? Ich habe einige aufgerufen, waren alle nur 23 Seiten lang. Zumal der 552 auch eher ein Exot war. Bitbanging ging bei mir immer. Was anderes habe ich nie gemacht. Ich meinte ein Beispiel einer vollständigen Logikimplementation eines einfachen Slavechips. Also den i2c-Teil davon. Sowas sah ich nie.
Abdul K. schrieb: > Zumal der 552 auch eher ein Exot war. Ich hatte den 80C652 eingesetzt. Für die Beschreibung des I2C wird auf den 80C552 verwiesen. Der 80C552 steht im IC20 auf Seite 575 bis 673. Das I2C wird auf Seite 583 bis 616 beschrieben. Online: https://www.keil.com/dd/docs/datashts/philips/8xc5x2_ov.pdf Abdul K. schrieb: > Bitbanging ging bei mir immer. Ja, das ist das einfachste und stabilste als single-Master. Der große Vorteil ist, man muß bei Wechsel der MC-Familie nur die beiden Pinzugriffe und die Delayfunktion anpassen, alles andere bleibt. Und man hat keinen I2C-Controller dazwischen, der sich verklemmen kann. Außer von den Philips-Typen bin ich bezüglich Zuverlässigkeit des I2C von anderen MCs nur enttäuscht worden. Abdul K. schrieb: > Ich meinte ein Beispiel einer vollständigen Logikimplementation eines > einfachen Slavechips. Als Slave nehme ich die üblichen Chips (IO-Expander, ADC, DAC, EEPROM, RTC). Ich hab mal den ATmega8 als Slave programmiert, da mußte ich haufenweise Recovery-Code einbauen. Nie wieder!
C-hater schrieb: > Ich kenne inzwischen einen ganzen Arsch voll I2C-Slaves (mindestens 30 > verschiedene ICs (bzw. IC-Familien)), die man allein durch das Geschehen > auf SDA/SCL in Zustände schicken kann, aus denen sie nur mittels > Power-Cycle wieder befreit werden können. Abdul K. schrieb: > Na dann liste mal auf. Wir wollen alle von dir lernen. So wie wir ihn kennen, wirste darauf wohl ewig warten müssen. Bei mir funktionieren jedenfalls alle dummen Slaves 24/7/365.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.