DS18B20: Wert 4095 nach einiger Zeit

[Jens (Gast)]

Hallo zusammen,

an einem STM320F103 Bluepill habe ich einen DS18B20 angeschlossen. 
Dieser funktioniert auch für einige Zeit. Irgendwann aber erscheint nur 
noch der Wert 4095 und ich muss den Controller resetten. Ich habe 
mehrere Sensoren ausprobiert, immer mit dem selben Fehler.

Angeschlossen habe ich diesen mit 5 V Versorgungsspannung und 3.3 V 
Portspannung. Ein 4k7-Pullup auf 3V3 ist ebenfalls eingebaut. Die 
eingestellten Zeiten in der tim.c passen ebenfalls.

Die Programmierumgebung ist STM32CubeIDE und als Programmer kommt ein 
ST/Link V2 zum Einsatz.

Als Ausgabe habe ich einen HD44780.

Mein Code ist im Anhang.

Was kann die Ursache für dieses Verhalten sein?

Die Berechnung findet hier statt:

float read_temperature(void)
{
    uint8_t check = 2;
    uint8_t temp_l;
    uint8_t temp_h;
    uint16_t temp;
    float temperature;

    check = sensor_init();

    sensor_write(SKIP_ROM);
    sensor_write(CONVERT);
    delay_ms(200);

    sensor_init();
    sensor_write(SKIP_ROM);
    sensor_write(READ_SCR);

    temp_l = sensor_read();
    temp_h = sensor_read();
    temp = (temp_h<<8)|temp_l;
    temperature = (float)temp/16;

    return temperature;
}

[Veit D. (devil-elec)]

Hallo,

deine zwei verschiedenen Spannungen verstehe ich zwar nicht ganz, aber 
default arbeitet das Teil mit 12Bit Auflösung was 750ms Conversion Time 
benötigt.

[Falk B. (falk)]

Jens schrieb:
> an einem STM320F103 Bluepill habe ich einen DS18B20 angeschlossen.
> Dieser funktioniert auch für einige Zeit. Irgendwann aber erscheint nur
> noch der Wert 4095 und ich muss den Controller resetten.

Klingt nach einem Fehler in deiner Software.

> Ich habe
> mehrere Sensoren ausprobiert, immer mit dem selben Fehler.

Was schon mal gut ist. Der Fehler ist reproduzierbar.

> Angeschlossen habe ich diesen mit 5 V Versorgungsspannung und 3.3 V
> Portspannung.

Kann man machen.

> Ein 4k7-Pullup auf 3V3 ist ebenfalls eingebaut. Die
> eingestellten Zeiten in der tim.c passen ebenfalls.

Hast du das Signal mit einem Oszi angeschaut?

Die Wartezeit von 200ms passt nur, wenn dein Sensor auf 8 oder 9 Bit 
Auflösung eingestellt ist. Ist er das?

Wenn du 4095 auf der Anzeige hast, dann reagiert dein Sensor nicht mehr 
und es wird immer 0xFF gelesen.

[Peter D. (peda)]

Wichtig ist, daß es zu keinen Datenkämpfen kommt. Der Portpin darf immer 
nur Output Low oder High Impedance sein. Aber zu keinem Zeitpunkt Output 
High, auch nicht kurzzeitig zwischen 2 Portbefehlen.

Wenn die CPU keinen echten Open-Drain kann, dann muß folgende 
Reihenfolge eingehalten werden:

Für auf high oder Input setzen:
1. Direction auf Input
2. Port auf High

Für auf low setzen:
1. Port auf Low
2. Direction auf Output

Man kann aber auch den Port einmalig auf low setzen und nie auf high.

[Jens (Gast)]

Falk B. schrieb:
> Hast du das Signal mit einem Oszi angeschaut?
>
> Die Wartezeit von 200ms passt nur, wenn dein Sensor auf 8 oder 9 Bit
> Auflösung eingestellt ist. Ist er das?
>
> Wenn du 4095 auf der Anzeige hast, dann reagiert dein Sensor nicht mehr
> und es wird immer 0xFF gelesen.

Auch bei 750 ms zeigt er das Verhalten. Mit dem Oszi habe ich mal 
geschaut, auch das sieht ganz gut aus. Im Fehlerfall sind es dann nur 
noch 3.3 V

[Veit D. (devil-elec)]

Hallo,

kannst du zeigen wie du den angeschlossen hast? Bezogen auf deine 5V und 
3,3V? Dein Board/Controller arbeitet doch bestimmt mit 3,3V. Dann würde 
ich den Sensor auch nur mit 3,3V versorgen ohne "parasitäre" 
Beschaltung.

[Jens (Gast)]

Gerne.

Die 5V werden über ein 7805 und die +3V3_MCU wird über einen LM317 
erzeugt. Dieser versorgt den Mikrocontroller (daher der Name +3V3 MCU). 
Die Sensorversorgungsspannung ist 5 V, also vom 7805.

[Jens (Gast)]

Ich glaube, der Controller hängt sich selber auf. In der main habe ich 
eine LED toggeln lassen. Diese blinkt ebenfalls nicht mehr sondern ist 
dauerhaft an.

[jo mei (Gast)]

Peter D. schrieb:
> Wenn die CPU keinen echten Open-Drain kann,

Kann sie aber. Der F103 kann das!

Ich mache das bei meinen Soft-I2C-Treibern so. Damit ist man
auf alle Fälle gefeit gegen Bus-Figths. Entscheidend ist aber
dass man bei Lesen eines Ports das Input-Data-Register aus-
wertet (im Gegensatz zum Output-Wert der davon abweichen kann).

Der Open-Drain-Betrieb ist die einzige Methode die sicher
dagegen hilft dass ein Slave und ein Controller gleichzeitig
den Pin-Pegel bestimmen wollen.

[Falk B. (falk)]

jo mei schrieb:
> Der Open-Drain-Betrieb ist die einzige Methode die sicher
> dagegen hilft dass ein Slave und ein Controller gleichzeitig
> den Pin-Pegel bestimmen wollen.

So ein Open Drain Bus ist voll depressiv, da zieht einer alle runter!

[jo mei (Gast)]

Falk B. schrieb:
> da zieht einer alle runter!

Für I2C und One-Wire jedenfalls die richtige Wahl.

[Peter D. (peda)]

jo mei schrieb:
> Kann sie aber. Der F103 kann das!

Jens schrieb:
> GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;

Ich würde diese Konstante aber als Push-Pull interpretieren und nicht 
als Open-Drain.

[jo mei (Gast)]

Peter D. schrieb:
> Ich würde diese Konstante aber als Push-Pull interpretieren

Das wird Jens auch nie gegenteilig behauptet haben.

Er hat es halt so implementiert "weil es funktioniert" (so auf
den ersten Blick zumindest), über gelegentliche Bus-Kämpfe wird
er sich dagegen keine Gedanken gemacht haben.

[Jens (Gast)]

Es war ein Fehler auf dem Bluepillboard. Die Stromaufnahme des Boards 
lag bei 175 mA und der Controller wurde warm.