Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

receiving Serial data crashes the ESP #3869

Closed
s0170071 opened this issue Nov 23, 2017 · 4 comments
Closed

receiving Serial data crashes the ESP #3869

s0170071 opened this issue Nov 23, 2017 · 4 comments

Comments

@s0170071
Copy link

s0170071 commented Nov 23, 2017

Please fill the info fields, it helps to get you faster support ;)

Basic Infos

I have a MT681 power meter with an IR output connected to the UART. The meter sends bursts of 500 bytes every 1200ms @9600bps. So one burst lasts about 500ms.

Hardware

Hardware: WemosD1 mini
Core Version: 2.4.0rc2

Description

When the RX bursts are present upon boot, the ESP fails to connect to wifi. It does connect eventually but it takes it a unpredictable amount of time, mostly about 10min.
Obviously the watchdog kicked in. There is some output:

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

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v0c897c37
~ld

Workaround:
Set UART mode to tx only, RXbuffersize =0. Wait for connect , then adjust the buffer size and the uart mode according to your needs.

Settings in IDE

Module: Wemos D1mini
Flash Size: 4MB
CPU Frequency: 80Mhz
Flash Mode: ?qio?
Flash Frequency: ?40Mhz?
Upload Using: SERIAL (tried OTA too)
Reset Method: power cycle

Sketch

The sketch makes the ESP send itself some bytes over the serial. RX1 sends to swapped RX0.
You need a wire between D4 (TX1) and D7 (swapped RX0) for this.
If the wire is present the watchdog will kick in.
If you remove the wire, the ESP will start.
Observation 1: yield(); while receiving helps a lot. But how can you yield() if you do not know when bytes are coming ?
Observation 2: If the size of the RX buffer is left at the default value, things don't work either.

#include <ESP8266WiFi.h>
//#include <WiFiClient.h>
//#include <ESP8266WebServer.h>

const char* ssid = "...";
const char* password = "...";
unsigned long startuptime;
 

void setup(void){
  Serial.setRxBufferSize(400);
  Serial.begin(115200);
  Serial.println("\n\nstart...");
  pinMode(D4,OUTPUT); // check the wire bridge
  digitalWrite(D4,0); 
  if (digitalRead(D7)==0) 
      Serial.println("D4 D7 wire bridge detected."); 
  else 
      Serial.println("NO wire bridge detected. Put it between D4 and D7");

  Serial.flush(); // force ouput
  delay(100); // wait for output
  
  
  
  Serial.swap();          // route the RX pin to D7
  Serial1.begin(115200); 
  for (int i = 0; i<500; i++) 
  {
    Serial1.write(i);
    //yield();  // this fixes the issue (and breaks the example)
    // but this is not the point. Trouble occurs when recieving, not sending.
    // sending here is only done for the sake of simplicity.
    // besides: sending 500 bytes takes 39ms
    // now: pull the wire and watch the ESP run ;-)
  }
  
  
  startuptime=millis();

  WiFi.begin(ssid, password); //  now try to connect
  while (WiFi.status() != WL_CONNECTED) {
    delay(1);
    Serial1.write(0x55);
  }
  Serial.swap();
}

void loop(void){
   
  Serial.println("Wifi connected. Startup time: " + String(millis()-startuptime)  +"ms");
  Serial.println("Bytes in buffer: " + String(Serial.available()));
  for (;;) delay(1000);
}

Output:

start...
D4 D7 wire bridge detected.

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

wdt reset
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v0c897c37
~ld

edit 2017-12-22:

  • added wdt output
  • added example
@s0170071 s0170071 changed the title network connect fails while serial IF recieves burst receiving Serial data crashes the ESP Dec 22, 2017
@s0170071
Copy link
Author

s0170071 commented Dec 22, 2017

may be related to #2576 and #2239

@s0170071
Copy link
Author

s0170071 commented Mar 19, 2018

I don't mean to rush anyone but could anyone please have a look ? At least try the sketch and confirm this is a bug.
#4328 does not fix this.

@d-a-v
Copy link
Collaborator

d-a-v commented Mar 20, 2018

You may try #4536.

@earlephilhower
Copy link
Collaborator

Closing because #4328 is merged, and no feedback for many months.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants