www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik sich aufhängende Sensoren LM70/75?


Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

ich habe in letzter Zeit einige Probleme mit den National Semiconductor 
Temperatursensoren LM70 (SPI) und LM75 (I²C), welche sich bei den 
EMV-Tests (Burst und Surge) "aufhängen". Beim LM75 ist besonders 
ärgerlich, dass dieser dann den I²C Bus blockiert indem er SDA und/oder 
SCL auf low zieht, der LM70 dagegen antwortet einfach nicht mehr. Man 
bekommt die Chips nur duch Ab- und Wiederanschalten der 
Versorgungsspannung aus diesem Zustand heraus. Den steuernden AVRs bzw. 
STR912-ern machen die (Rest-)Störungen dagegen nichts aus.

Hat jemand mit diesen Chips ähnliche Erfahrungen gemacht?
Tipps für Abhilfe (außer noch besserem Schutz vor Burst/Surge an den 
Eingangsleitungen des Gerätes - das geht leider erst im PCB-Redesign)?

Stefan

Autor: Haku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sicher dass der Chip sich aufhängt? Ich hatte ein ähnliches Phänoment 
einmal bei einem Bus mit einer handvoll Portexpandern. Nach einiger Zeit 
ging dann plötzlich garnix mehr.

Des Rätsels Lösung: Bei der Übertragung ist "irgendwann" mal ein Takt 
(SCK) flöten gegangen, danach hat dann eben nix mehr gestimmt, weil z.B. 
die Bestätigungen (ACK) ausblieben. Ausweg: vernünftig programmieren und 
beim geringsten Zweifel den Bus mal auf Idle legen, damit die Chips von 
vorne anfangen zu zählen.

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich bin mir ziemlich sicher: ohne die Störbeaufschlagung laufen die 
Boards wochenlang problemlos.
Treten die Abstürze auf, helfen auch die üblichen I²C-Recoveryversuche 
(SCKs generieren, bis der Arzt kommt bzw. der Bus wieder released wird) 
nichts. Die Störungen treten auch nicht auf, wenn man die SDA bzw. MISO) 
Pins der Sensoren hochbiegt und diese somit vom Bus nimmt.
Die am selben Bus befindlichen Portexpander (PCA9535) laufen dann auch 
während der Burst/Surge-Störbeeinflussung problemlos.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie lang ist denn der I2C-Bus?

Auch wenn es in Bastlerkreisen sehr gerne gemacht wird, der I2C ist 
nicht dafür vorgesehen, das Geräteinnere zu verlassen.

Bzw. dann sollte man wenigstens Bustreiber auf beiden Seiten verwenden 
(P82B715).


Peter

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hihi: es sind keine "Bastlerkreise" und der Bus bleibt daher schön 
onBoard (insgesamt mit allen Layout-Schnörkeln vielleicht 20cm 
(Europakarte))

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Wimmer wrote:
> Beim LM75 ist besonders
> ärgerlich, dass dieser dann den I²C Bus blockiert indem er SDA und/oder
> SCL auf low zieht

Das ist aber seltsam.

Ich kenne es eigentlich so, daß bei I2C-Slaves (24Cxx, PCF8574 usw.) der 
SCL nur Input ist, d.h. rein schaltungstechnisch kann er SCL gar nicht 
auf low ziehen.

Kommt das SCL = low wirklich vom Sensor?


Peter

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, damit (SCL = Eingang bei Slaves) hast Du natürlich recht. Da waren 
die Finger schneller als das Hirn... ;-)

Es ist SDA, welches auf Low bleibt und somit den Bus lahmlegt.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das stimmt so nicht. Ein I2C-Slave darf SCL auf Low halten, das zwingt 
den Master zum Warten, wenn der Slave wegen interner Beschäftigung die 
Daten nicht so schnell entgegen nehmen kann.

Gruß aus Berlin
Michael

Autor: Oliver N. (nixo2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ist es auch meiner Meinung nach korrekt, die Slaves können den Takt 
so verlangsamen, wenn Sie mit der Geschwindigkeit nicht mehr mitkommen, 
indem sie SCL einfach verlängern. Der Master muss darauf überprüfen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael U. (amiga)

>das stimmt so nicht. Ein I2C-Slave darf SCL auf Low halten, das zwingt
>den Master zum Warten, wenn der Slave wegen interner Beschäftigung die
>Daten nicht so schnell entgegen nehmen kann.

Richtig, er darf das machen, muss aber nicht. Viele ICs machen von 
der Option keinen Gebrauch.

Mfg
Falk

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Falk Brunner (falk):
bezog sich vorrangig auf das Posting von Peter Dannegger (peda) von 
05.02.2008 19:05.

Bei I2C sind beide Leitungen nie reine Eingänge, auch beim Slave nicht.

Diese Wait-Geschichte hat mich mal beim MAS3507D genervt, Atmels alte 
AppNote zu I2C hat genau das nicht berücksichtigt und irgendwann hing 
der Krempel dann immer fest.

Beim konkreten Problem des Posters wird es aber vermutlich nicht viel 
weiterhelfen, leider.

Gruß aus Berlin
Michael

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Wimmer wrote:

> Es ist SDA, welches auf Low bleibt und somit den Bus lahmlegt.

Und ein Reset des I2C-Busses hilft nicht?
D.h. bis zu 9-mal SCL mit 100kHz takten und STOP senden.
Dazu muß natürlich das HW-I2C erst disabled werden und dann die Pins 
selber takten.


Ich nehme ja immer SW-I2C, wenn der MC single-Master ist.

Dann muß man nicht drauf achten, ob sich das HW-I2C intern verhakt 
(Timeout) und es resetten (stoppen, disablen, Interuptflag löschen, 
enablen).

Irgendwie blöd, daß man bei nem HW-I2C die interne Statusmaschine nicht 
auslesen kann.
Man kriegt immer erst einen Status, wenn eine Aktion durchgelaufen ist.
Wenns hängt, weiß man also nicht, warum.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. wrote:
> Hallo,
>
> @Falk Brunner (falk):
> bezog sich vorrangig auf das Posting von Peter Dannegger (peda) von
> 05.02.2008 19:05.
>
> Bei I2C sind beide Leitungen nie reine Eingänge, auch beim Slave nicht.

Guck erstmal ins Datenblatt, ehe Du solchen Unsinn behauptest.
Da steht eindeutig: Input

Die meisten Slaves haben nur einen SCL-Input (24Cxx, PCF8574 usw.).
Wozu sollten sie auch den Master warten lassen?

Ich hab ja nirgends behauptet, daß alle Slaves so sind, es mag also 
Ausnahmen geben.



Peter

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

danke für die angeregte Diskussion - auf diese Weise bekommt man ja oft 
neue Denkanstöße.

Also wir haben beides probiert: sowohl Hardware- als auch Soft-I²C. Bei 
beiden bekommt man den aufgehängten Sensor nicht mehr aus dem Zustand 
heraus, wo er SDA auf low hält. Auch mit noch so vielen SCKs nicht. Und 
solange er SDA nicht loslässt kann man auch keine Stop-Bedingung 
erzeugen.

Ich habe auf einem Board versuchsweise mal einen TP0101T (P-Channel 
MOSFET) in die Versorgungsleitung des LM75 "eingefädelt" und wenn ich 
damit einen Power-Cycle mache, fängt der Sensor sich wieder. Aber das 
kann ja wohl nicht die Lösung sein!

Grüße aus Berlin-Tempelhof,
Stefan

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,

ich wärme den Thread mal nochmal auf, denn es scheint so, als ob ich 
nicht der einzige bin, der Probleme mit den LM75 hat, denn National hat 
den Chip verbessert und bietet ihn nun mit Filtern in SDA und SCL an.

Maxim geht noch einen Schritt weiter und kündigt gerade ein 
LM75-kompatibles Derivat mit I²C Watchdog an. Mal sehen, ob und wann das 
matrialisiert. Dann werde ich damit ein paar Burst-Tests machen.

Autor: Gerhard. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe zum Thema eine interessannte Application Note gefunden:

http://www.maxim-ic.com/appnotes.cfm/appnote_number/476

Die SMB Varianten scheinen robuster zu sein - Angeblich;-)

Gruss,
Gerhard

Autor: Gerhard. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist noch was Llesenswertes:

http://www.electronicsweekly.com/products/2004/08/...

In diesem Artikel steht dass beim MAX5700 eine Bus Reset Leitung 
vorhanden ist um den Bus im FAlle eises Lock-up wieder frei zu bekommen. 
Ist doch ulkig?-)

Gruss,
Gerhard

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, sowas in der Art soll es dann irgendwann mit LM75-kompatiblem 
Befehls-/Registersatz geben.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.