Serielle Kommunikation STM32 -> ESP8266 klappt nicht

[Peter M. (pbm)]

Ich möchte Daten von einem STM32 über serielle Schnittstelle zu einem 
ESP8266 senden. Dort kommen die Daten auch an, aber der ESP mag sie 
nicht.

Zunächst mal sieht man auf dem angehängten Bild die vom STM32 gesendeten 
Daten, gemessen am UART0-RX-Pin des ESP. Die Daten sollten nun mit 
diesem ESP-Arduino-Sketch verarbeitet werden:

void setup() 
{
  Serial.begin(BAUD);
  Serial1.begin(9600);
}

void loop()
{
  int len;

  if ((len = Serial.available())) {
    Serial1.println("Received bytes ...");
    // ...
  }
}

Eine erweiterte Trace-Ausgabe zeigt aber, dass Serial.available() 
konstant 0 zurückgibt.

Muß ich für den ESP das UART-Interface vom STM32 irgendwie besonders 
konfigurieren? Oder hat mein Sketch einen Denkfehler? Baud und Parität 
passen zusammen, und TX/RX sind gekreuzt.

[Rainer B. (katastrophenheinz)]

Hi,
- GND ist verbunden?
- Loopbacktest ( TX/RX kurzschließen) auf ESP-Seite klappt auch?
- Was sagen die UART-Fehlerbits auf ESP-Seite ?
- ist die Baudrate auf beiden Seiten von einer ausreichend genauen 
Quelle (zB Quarz/kalibrierter RC-Oszillator) abgeleitet, so dass der 
Baudratenfehler ausreichend klein bleibt?

[Jim M. (turboj)]

Bei der gezeigten Kurve und angenommenen 100µs/Kästchen wären 9600 Baud 
um ca. Faktor 10 falsch.

Bei 9600 Baud wäre ein Bit ungefähr ein Kästchen breit. Oben im Bild 
sind run 10 Bits/Kästchen - also eher 115200 Baud.

[Guest (Gast)]

Jim M. schrieb:
> Bei 9600 Baud wäre ein Bit ungefähr ein Kästchen breit. Oben im Bild
> sind run 10 Bits/Kästchen - also eher 115200 Baud.

Da schließe ich mich an. Ich zähle 11 statt 10 Bit aber das ist 
Haarspalterei. 9600 Baud ist das nicht.

Wie hast du die Baudrate am STM denn eingestellt?

[Peter M. (pbm)]

Also erstmal: GND ist da. Am Loopback arbeite ich, ist aber auf der 
Platine nicht so einfach hinzufummeln.

Die Kommunikation ist mit 115200 Baud. Die 9600 Baud gelten nur für 
Serial1, also den Trace.

Zu den Fehlerbits kann ich nichts sagen, dazu kenne ich auf ESP-Seite 
(zumal mit Arduino) nicht gut genug aus.

Der ESP ist ein aufgelötetes ESP-07S-Modul, und der STM32 läuft mit HSI. 
Ich kann mal testweise die Baudrate reduzieren, vielleicht hilft das.

[Rainer B. (katastrophenheinz)]

Peter M. schrieb:
> Der ESP ist ein aufgelötetes ESP-07S-Modul .
Kann das Ding überhaupt mehr als einmal U(SART) und hast du die GPIOs so 
konfiguriert, dass die entsprechenden GPIOs Tx und Rx des zweiten 
U(S)ART sind? Der Loopbacktest wird das zeigen.


> Ich kann mal testweise die Baudrate reduzieren, vielleicht hilft das.
Wenn der Baudratenteiler bei hoher Baudrate nicht von sich aus schon 
einen Fehler beinhaltet, dann hilft das nix.

[GEKU (Gast)]

Bei mir waren die ESP8266 werkseitig auf 115kBaud eingestellt. 
Funktionieren die AT Kommandos mit dieser Übertragungsgeschwindigkeit?

[Stefan F. (Gast)]

Überprüfe das Timing vom seriellen Signal. Die horizontale Auflösung 
deines Oszilloskop-Bildes reicht dazu nicht aus. Ein Logic Analyzer kann 
das besser.

[Rainer B. (katastrophenheinz)]

Und poste bitte mal eine Malung vom Schaltungsaufbau und eine genaue 
Beschreibung des verwendeten ESP-Moduls und des STM32-Boards, sonst 
bleibt das hier Stochern im Nebel.

Weiterhin würde es helfen, wenn du z.B. mit einen USB-to-Serial-Adapter 
mal auf dem Übertragungssignal mithören/mitloggen lassen könntest.

[Harry L. (mysth)]

Peter M. schrieb:
> Die Kommunikation ist mit 115200 Baud. Die 9600 Baud gelten nur für
> Serial1, also den Trace.

Ja...nee...is klar!

Finde den Fehler!

[Peter M. (pbm)]

Loopback funktioniert offenbar auch nicht. Wenn ich diesen Sketch 
ausführe

void loop()
{
  Serial.print("xxx");
  
  if (Serial.available())
    Serial1.println("!");
}

und dann direkt RX mit TX verbinde, passiert gar nix.

Um auf das Timing (und zur Schaltung) zurückzukommen, ich habe vor TX- 
und RX-Pin je 1K Widerstand, wie von Stefan Frings empfohlen. 
Wahrscheinlich sollte ich die entfernen, aber kann das (bei geringer 
Geschwindigkeit) die Ursache sein?

[Peter M. (pbm)]

Harry L. schrieb:
> Ja...nee...is klar!
>
> Finde den Fehler!

So sicher nicht.

[Rainer B. (katastrophenheinz)]

Peter M. schrieb:
> ich habe vor TX-und RX-Pin je 1K Widerstand,

Schaltplan?

Was zeigt das Oszi am verbundenen Rx-Tx-Pin? Kommen die drei 'x' da 
raus?
Und nimm mal 'U' statt 'x', dann kannst du die Bits/Bitzeiten besser 
auszählen.

[drm (Gast)]

TX an TX und Rx an Rx angeschlossen ? Passiert selbst den Besten mal.

[Peter M. (pbm)]

Ich habe zwischenzeitlich noch einmal alles überprüft und frisch 
angeschlossen, und siehe da:

 ets Jan  8 2013,rst cause:2, boot mode:(3,2)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
   Init done.

Dieser Fehler wiederholt sich ca. alle Sekunde.

rst cause 2 steht für "External reset or wake-up from Deep-sleep". Der 
RST-Pin ist mit einem GPIO-Pin des STM32 verbunden, welcher als Input 
ohne Pullup/-down konfiguriert ist. Testweise habe ich auch Output mit 
HIGH ausprobiert, aber der Fehler blieb.

Diese Verbindung habe ich für den Fall, dass der STM32 den ESP resetten 
muss. Wahrscheinlich wäre ein Pullup geschickt gewesen, aber wieso tritt 
der Fehler immer wieder auf?

Anbei die Schaltung. Man beachte, dass die Verdrahtung sowohl UART als 
auch SPI unterstützen sollte. Leider ist der Anschluß am STM32 
fehlerhaft: anstelle von RTS/CTS wurde MOSI/NSS doppelt verbunden. Die 
Kommunikation ist jedoch ohne RTS/CTS.

Dabei fällt mir gerade auf: Verwendet der ESP denn RTS/CTS per default? 
In der Arduino-Doku steht dazu nichts.

[Arno (Gast)]

Peter M. schrieb:
> Um auf das Timing (und zur Schaltung) zurückzukommen, ich habe vor TX-
> und RX-Pin je 1K Widerstand, wie von Stefan Frings empfohlen.
> Wahrscheinlich sollte ich die entfernen, aber kann das (bei geringer
> Geschwindigkeit) die Ursache sein?

Ja, kann sein. Überbrück die mal testweise, ich bin in der RX-Leitung 
von einem 5V-Chip (mit separater Clamping-Diode) auf wimre 220 Ohm 
runtergegangen, damit das zuverlässig funktioniert.

Hast du für den Loopback-Test die STM32-Pins auf "Eingang" geschaltet?

Peter M. schrieb:
> Anbei die Schaltung. Man beachte, dass die Verdrahtung sowohl UART als
> auch SPI unterstützen sollte. Leider ist der Anschluß am STM32
> fehlerhaft: anstelle von RTS/CTS wurde MOSI/NSS doppelt verbunden. Die
> Kommunikation ist jedoch ohne RTS/CTS.

Man sieht auch - wenn das die reale Platine ist - dass du sehr dünne 
Leiterbähnchen verwendest. Das kann eine Fehlerquelle sein, vor allem, 
weil auch die VCC/GND-Leiterbahnen nicht breiter sind und der ESP ja 
bekanntlich sehr steile Peaks in der Stromaufnahme hat (die Versorgung 
selbst ist hoffentlich ausreichend?)

Mein anderer Verdacht wäre ein Bug bei der Verwendung von zwei 
verschiedenen seriellen Schnittstellen - hast du mal verschiedene 
Versionen des esp8266-arduino-Core getestet?

> Dabei fällt mir gerade auf: Verwendet der ESP denn RTS/CTS per default?

Nein, tut er nicht.

MfG, Arno

[Peter M. (pbm)]

Gut, aber erst muss der rst cause Fehler weg.

Wifi wird noch gar nicht genutzt, daher denke ich, die Stromversorgung 
reicht aus - wäre sonst nicht auch die Fehlermeldung "rst cause:1"?

[Rainer B. (katastrophenheinz)]

Peter M. schrieb:
> Diese Verbindung habe ich für den Fall, dass der STM32 den ESP resetten
> muss. Wahrscheinlich wäre ein Pullup geschickt gewesen, aber wieso tritt
> der Fehler immer wieder auf?

Hi,

was ist mit den roten Leiterbahnen, die einfach so im rough enden?

Ist WRST sicher active low? Dann zieh den WRST-Pin mal mit einem 
externen Widerstand 4k7 auf High. ggf auch noch einen 100nF Kerko zw. 
WRST und GND. Und guck, ob das hilft.

Als nächstes dann das Oszilloskop an den VDD-Pin vom ESP-Modul und guck, 
ob dort Spannungseinbrüche auftreten

[Arno (Gast)]

Peter M. schrieb:
> Gut, aber erst muss der rst cause Fehler weg.
>
> Wifi wird noch gar nicht genutzt, daher denke ich, die Stromversorgung
> reicht aus - wäre sonst nicht auch die Fehlermeldung "rst cause:1"?

Würde ich mich nicht drauf verlassen - bei fehlerhafter 
Spannungsversorgung kann ungefähr alles passieren.

Hat die Arduino-Umgebung einen Software-Watchdog zusätzlich zum 
HW-Watchdog? Dann kann es auch daran liegen, denn der würde den Reset 
Cause nicht ändern: 
https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf

MfG, Arno

[Stefan F. (Gast)]

Peter M. schrieb:
> verwendet der ESP denn RTS/CTS per default?

Nein

[Peter M. (pbm)]

So, das Problem ist gelöst!

Erstmal habe ich zwei dicke Drähte an Vdd und GND gelötet - immer noch 
der gleiche Fehler.

Dann habe ich die Schaltung mit einem Nucleo-Board auf einem Steckbrett 
nachgebaut - wieder der gleiche Fehler.

So langsam habe ich nicht mehr an einen Hardware-Fehler geglaubt und 
habe mir nochmal den (ganzen) Code angesehen:

uint8_t *bufptr;  // <-------------------

void loop()
{
  size_t len;
  
  if ((len = Serial.available())) {
    Serial.readBytes(bufptr, len);
    bufptr += len;
    Serial1.println("Received bytes ...");
    // ...
    }
  }

Ein ganz profaner Dereferenzierungsfehler also! Und ich hatte den 
relevanten Code nicht mitzitiert.

Trotzdem hat mich der Fehler überrascht, denn ich hätte eher was mit 
Stacktrace erwartet. Oh mann ...