Serielle Kommunikation STM32 -> ESP8266 klappt nicht

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?

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.

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.

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.

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.

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!

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

1

void loop()

2

{

3

  Serial.print("xxx");

4

5

  if (Serial.available())

6

    Serial1.println("!");

7

}

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?

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

So sicher nicht.

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.

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

1

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

2

3

load 0x4010f000, len 1384, room 16 

4

tail 8

5

chksum 0x2d

6

csum 0x2d

7

v8b899c12

8

~ld

9

   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.

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"?

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

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:

1

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

2

3

void loop()

4

{

5

  size_t len;

6

7

  if ((len = Serial.available())) {

8

    Serial.readBytes(bufptr, len);

9

    bufptr += len;

10

    Serial1.println("Received bytes ...");

11

    // ...

12

    }

13

  }

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 ...