SoftwareSerial: wdt reset

[supersjimmie]

I use both SoftwareSerial and WiFiClient.
During normal operations, it sometimes works for many hours but other times it gives a wdt reset.
This looks like it has a relation between SoftwareSerial and WiFiClient.

If I use mySerial.enableRX(false) before starting the function with the WiFiClient, it seems to keep working, otherwise it looks like to crash on different places.

ets Jan 8 2013,rst cause:4, boot mode:(3,6) wdt reset
This was during client.print() operations, the first client.print with the data succeeded, then just after that, only when sending an empty line with client.print("\r\n") it gave the wdt reset.

But earlier, it was just during receiving data on the SoftwareSerial:
`ets Jan 8 2013,rst cause:4, boot mode:(1,6)``

And a couple of other times also during normal receiving on the serial:
ets Jan 8 2013,rst cause:4, boot mode:(3,7)

So many different boot modes, they all seem only to occur if I don't use the mySerial.enableRX(false).

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[supersjimmie]

Ah, too bad, also when I use enableRX(true)
ets Jan 8 2013,rst cause:4, boot mode:(1,6) wdt reset

I think I can better leave the github version for now, 2.0.0 is more stable on this.

[plerup]

Please supply some code and information about baud rate and traffic volume

[supersjimmie]

After more investigation, the title can be changed to "SoftwareSerial wdt reset".

#include <SoftwareSerial.h>
SoftwareSerial mySerial(D2, -1, true, 128);

char telegram[64];

int readTelegram();

void setup()
{
  Serial.begin(115200);  // 115200  256000
  mySerial.begin(115200);
}

void loop() {
  int t = readTelegram();
  yield();
}

int readTelegram() {
  if (mySerial.available() > 0) {
    int len = 0;
    char c;
    unsigned long timeout = 2;
    unsigned long start = millis();
    while ((len < 63) && (millis() - start < timeout)) {
      c = mySerial.read();
      if  ((c == '\n') || (c == '\r')) break;
      if ((c >= 32) && (c <= 126)) {
        telegram[len++] = c;
      }
      yield();
    }
    telegram[len] = 0;
    return len;
  }
  else return 0;
}

Pin D2 is connected to my "Smart Meter", which generates a 27 lines, all terminated with \r\n.
Each line is max 47 char long (shortest is 5 char, longest 47 char).
It is at 115200 baud, with inverted signal.
The lines are sent every 10 sec.

Sometimes there is some garbage, and sometimes no \r\n is received, so I have a timeout (2mSec) and a filter (c = 32-127).

Earlier I tried ReadBytsUntil, it also crashed.
So I now tried to write it with just read() and my own filter and timeout function.

Also tried with a shorter timeout, using micros() and a value of 500.

After running for a couple of minutes, mostly less then an hour, it crashes with a WDT reset.

[plerup]

This is a rather large burst of interrupts. Try using something like the code below which intends to read all the lines into a buffer and then treat the lines in the buffer afterwards

  #include <SoftwareSerial.h>

  #define MAX_SIZE 27*47
  SoftwareSerial mySerial(D2, -1, true, MAX_SIZE);

  char buffer[MAX_SIZE];

  void setup()
  {
    Serial.begin(115200);  // 115200  256000
    mySerial.begin(115200);
    Serial.println("Started");
  }

  void loop() {
     int pos = 0;
     while (mySerial.available() && pos < MAX_SIZE) {
        buffer[pos++] = mySerial.read();
     }
     if (pos) {
        // Data received, treat the buffer contents
        Serial.println(pos);
     }
  }

[plerup]

BTW, which version are you using?

[supersjimmie]

I think when I read all lines into one large buffer, it will still going to crash after some time.
It looks like series of lines has 3 different time gaps:
Very short gap between each line, a bit short gap just before the last line (which contains a checksum, but that does not matter) and then the long 10 sec gap.
I cannot exactly predict when data comes, so there will always be interrupts on unpredicted moments.

BTW:
The WDT resets occur with Arduino IDE 1.6.7 and esp8266 latest GIT.
Last reset with exactly the code above: rst cause: 4, boot mode:(1,7)

When I use DE 1.6.5 with esp8266 2.0.0 Stable, it runs fine for as long as I let it run.
So, why are the interrupts a problem with the latest, while it is not with the older?

(I think, not for sure, I started with softwareserial 2.1.1 or 2.2)

[supersjimmie]

I have changed the code, to get the whole telegram before continuing:

#include <SoftwareSerial.h>
SoftwareSerial mySerial(D2, -1, true, 128);

#define MAX_LINES 28
#define MAX_LENGTH 64
char buffer[MAX_LINES * MAX_LENGTH];

int readTelegram();

void setup()
{
  Serial.begin(115200);
  mySerial.begin(115200);
}

void loop() {
  int t = readTelegram();
}

int readTelegram() {
  if (mySerial.available() > 0) {
    memset(buffer, 0, sizeof(buffer));
    int len = 0;
    char c;
    unsigned long timeout = 700;
    unsigned long start = millis();
    while ((len < MAX_LINES * MAX_LENGTH) && (millis() - start < timeout)) {
      if (mySerial.available()) {
        c = mySerial.read();
        yield();
        buffer[len++] = c;
        Serial.write(c);
      }
      yield();
    }
    return len;
  }
  return 0;
}

No luck after a while:

 ets Jan  8 2013,rst cause:4, boot mode:(1,7)
wdt reset

Second attempt, boot mode:(1,6)

[supersjimmie]

Having the resets with:
Arduino IDE 1.6.5 and 1.6.7.
ESP-Arduino libraries 2.0.0 Stable and Latest GIT
SoftwareSerial 2.2.

Works with SoftwareSerial 2.1 and all IDE, and all ESP libs.
(but with 2.1 I have too much corrupted received data)

[supersjimmie]

@plerup I also tried your code example from 2 days ago. It was running for over an hour without a reset. (perhaps I should find time to let it run longer)
But... As soon as I made one simple change:

    buffer[pos++] = mySerial.read();

To:

    buffer[pos] = mySerial.read();
    Serial.print(buffer[pos]);
    pos++;

WDT reset within a couple of minutes.

EDIT: Noo, too bad.
The original code from you just crashed too with a wdt reset.

 #include <SoftwareSerial.h>

  #define MAX_SIZE 29*50
  SoftwareSerial mySerial(D2, -1, true, MAX_SIZE);

  char buffer[MAX_SIZE];

  void setup()
  {
    Serial.begin(115200);  // 115200  256000
    mySerial.begin(115200);
    Serial.println("Started");
  }

  void loop() {
     int pos = 0;
     while (mySerial.available() && pos < MAX_SIZE) {
        buffer[pos++] = mySerial.read();
     }
     if (pos) {
        // Data received, treat the buffer contents
        Serial.println(pos);
     }
  }

[supersjimmie]

So today I tried it with a hardware intverter and set the "inverted" flag to "false" in softwareserial.
But I still get the WDT resets.

[odilonafonso]

Hi,
What SoftwareSerial did you used ?
I do not found this constructor:

SoftwareSerial mySerial(D2, -1, true, MAX_SIZE);

Into the SoftwareSerial that I use. The SoftwareSerial I have has this constructor:

SoftwareSerial::SoftwareSerial(uint8_t receivePin, uint8_t transmitPin, bool inverse_logic /* = false */) : 
  _rx_delay_centering(0),
  _rx_delay_intrabit(0),
  _rx_delay_stopbit(0),
  _tx_delay(0),
  _buffer_overflow(false),
  _inverse_logic(inverse_logic)
{
  setTX(transmitPin);
  setRX(receivePin);
}

I have had problems using SoftwareSerial library.
Apparently the buffer it uses is not enough to communicate with the ESP8266 .

What is the fourth argument used in this builder - MAX_SIZE ?

[supersjimmie]

I use the latest mentioned here: https://github.com/esp8266/Arduino/blob/master/doc/libraries.md#softwareserial

SoftwareSerial(int receivePin, int transmitPin, bool inverse_logic = false, unsigned int buffSize = 64);

[odilonafonso]

Thanks.
One help more:
I found SoftwareSerial.h and SoftwareSerial.cpp on:
"/opt/arduino-1.6.7/hardware/arduino/avr/libraries/SoftwareSerial"
(I use Linux)
I have to delete it? and put the new there?
or I can put the new library on my local libraries directory - /home/odilon/Arduino/libraries.
What is a file search order include the Arduino IDE is?

[plerup]

@odilonafonso The SoftwareSerial you are referring to is the AVR version. If you are using the staging release of esp8266/arduino you will automatically get the correct version

[plerup]

@supersjimmie The only reason I can think of for your problem is if there are a lot of data coming in a burst or if there are some noise on the GPIO pin. In those cases there will be constant calls to the interrupt routine and yielding will not occur before the watchdog resets the chip. You could try disabling the watchdog but then your WiFi will probably be flaky.

[supersjimmie]

I don't think it is noise, but you may be right that it has something to do with the amount of data. If it was noise, the data would be corrupted but it is very clear data.

As far as I understand now, the crashes occur if I do just any small other thing while there is data coming in. Even just printing the received character makes it all instable.
For now it looks stable when I only capture data and store it in a buffer, without anything else like checking (is it a valid character) or printing it.

int readTelegram() {
  int len = 0;
  char c;
  unsigned long maxwait = 10000;
  unsigned long maxreceive = 650;
  memset(buffer, 0, sizeof(buffer));

  // Allow receiving data
  Serial.println("waiting...");
  mySerial.enableRx(true);

  // Wait max 10 sec for data
  unsigned long startwait = millis();
  while ((mySerial.available() == 0) && (millis() - startwait < maxwait)) {
    yield();
    ESP.wdtFeed();
  }

  // If data available, get entire telegram
  if (mySerial.available() > 0) {
    unsigned long startreceive = millis();
    while ((len < MAX_LINES * MAX_LENGTH) && (millis() - startreceive < maxreceive)) {
      if (mySerial.available() > 0) {
        buffer[len++] = mySerial.read();
      }
    }
  }

  // Stop receiving data
  mySerial.enableRx(false);

  // If any data has been received, show it
  return len;
}

I also noticed that I had to use enableRX(false) to avoid the interrupts when my code it doing something else (like sending data the the logging server) while new data is coming in on the line.

[pieman64]

@supersjimmie if you are using SoftwareSerial (and your reference to D2 rather than GPIO X) does that mean you are using an ESP with an Arduino rather than the ESP as an Arduino?
The reason I ask is that I use Arduino with ESP / USB. Obviously USB and ESP are completely different but almost identical sketches crash regularly with the ESP whereas they are fine with the USB. Maybe I have a similar problem to you.

[supersjimmie]

No I only use an ESP8266.
D2 is because on a ESP8266 NodeMCU dev board the pins are labeled ad D0..D8, which is then translated to normal GPIO numbers. (D2 is GPIO4)

Here to be precise: https://github.com/esp8266/Arduino/blob/master/variants/nodemcu/pins_arduino.h#L37-L59

[pieman64]

So neither Arduino with ESP or ESP Standalone, more a hybrid the NodeMCU?

[supersjimmie]

NodeMCU is just an ESP12 on a board with some extra features.
https://www.google.nl/search?q=nodemcu
So a standalone ESP.

[supersjimmie]

@plerup disabling the WDT before this function and re-enabling it afterwards does not solve it, it even seems worse.
The only work-around I could find is to do absolutely nothing during the time that any data comes into the SoftwareSerial buffer. Which is very hard to do, because I cannot predict when data can be expected to come. So for now all I can do is just create a waiting loop in my program and do nothing else than waiting for data. This makes the rest of all my code stop for a long time. During receiving I can still not do anything else than only putting it into a buffer.

[ps-nl]

Same problem occurs here, though that may be explained given that I run a modified version of supersjimmie's code. Reboots mostly with error "rst cause:4, boot mode:(3,6) wdt reset".

My environment is the latest github release of the esp8266 framework and espsoftwareserial 2.2, compiled with the platformio IDE environment. The board I use is an Wemos D1 Mini.

[rwkiii]

@supersjimmie - maybe you've already ensured power, but don't take the power requirements lightly. I was able to perform firmware updates and program my ESPs without problem. Running them is a different story! :-P

I cannot stress enough, make sure you have plenty of power to your ESP. I don't feel an Arduino can supply the needed power. I also order 5v - 3.3v converters so I could use the Arduino's power connectors. Very hit and miss. Sometimes it worked, other times it fails and that tends to lead to experimentation with the sketch or pin connections.

Of course, ESPs are rated at 2.7v to 3.3v or something like that, but they draw upwards of 250ma. The Arduino cannot supply that. Also, many FTDI adapters only pull 100ma from the USB conn. Some pull 500ma. I forget what the determination is there...

I ordered some power supply units for my breadboards. Several types that I wanted to try out. They would not all work - I received the same wdt resets you are getting. Replace the power supply with an a different one and it works fine. A sure fire way for me was with a regular 9-volt battery.

After I realized how power-hungry these ESPs are I've been making sure my power supply is always adequate. I can't tell you how much more reliable things have been in the regards to unwanted resets and non-responsive ESPs.

Despite this, I still have to make 3, 4, or even 5 attempts to get a sketch uploaded to them. They work fine - but they really are buggy. Keep that in mind. The wdt reset problem though may be due to power.

Just a thought!

[supersjimmie]

@rwkiii Yes I know about power.
I have no other problems whatsoever that might make power even a bit suspected.
I have all double checked and much more power and capacitors than ever recommended. I can exactly isolate the problem to what I am telling about the code, any other (much larger) function runs normally. Even wifi (power) hungry functions and reading/writing other devices are doing fine. It is already very clear the problem really only occurs at exactly the point that I am describing.
Also somebody else is having exactly the same problem with a completely different type of board and power etc.

The ESP can run fine for hours and even multipe days when I work-around the problem and it will fail within minutes when I use the problematic code. There is much more code running on it, it just files here and nowhere else.

[plerup]

Yes, let's to bring this thread on track. These are the facts:

SoftwareSerial is depending on interrupts on the Rx pin. If these are coming in constantly e.g. during a burst of many characters, all cpu time will be spent in the interrupt routine. Subsequently the hardware watchdog will not be feed and hence will reset the ESP once the its max time has elapsed. To my knowledge there is no way to disable the hardware watchdog, only the software one.

The only solution I can think of would be to let SoftwareSerial disable the interrupts after a certain time, or when the buffer gets full. Either way characters will be lost.

If anyone has any better solution feel free to send pull requests.

I guess we all have to look forward to the ESP32 where all WiFi and BT communication will be handled in a separate cpu.

[supersjimmie]

Is this really such a big burst then?
It is a maximum of 700 chars and about halfway there is a slight delay (maybe a few mSec) and another longer delay just before the last 6-8 chars (a checksum).
So it is:

1. About 350 chars,
2. a short delay,
3. again about 350 chars,
4. a longer delay,
5. 6-8 chars.

350 chars at 115k2 would be just about 3mSec, that's not really long?
Including all delays, the total is always done within 650mSec (maybe even a bit less).
Is there a way I can do some testing with disabling the interrupts when the buffer gets full?
I think that would be easy to test.

But what's strange, or may bring a solution, it seemed to be working with the Stable 2.0.0 core esp8266/arduino. But I'm not absolutely sure about that (must think about a thorough easy way to test that again).

[igrr]

Note that the HW watchdog is set to trigger in 6 seconds by default, so these watchdog resets you are seeing are not directly caused by a long chain of interrupts. Looks more like some lock-up, i.e. an endless loop within an interrupt.

[supersjimmie]

As you can see in the crashing examples above, I don't think there is a problematic loop?
Perhaps one is somewhere in the softwareserial itself?

[jeroenst]

I also can confirm softwareserial is causing my esp to have watchdog timeouts every several hours.

It occurs with read and write of software serial.

logging:
read_MHZ19()
executing co2Serial.write(cmd,9)
dev 1153

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

wdt reset

[alexgrauer]

@jeroenst, do you still have issues when using SoftwareSerial?

I did what @LuisVSa recommended and it works like a charm. Until now, it has been working for more than 2 days in a row without any crash.
Im using software serial library for Tx purposes thou, so its confusing what you are saying about your system also crashing when sending info.
I config the serial software like this:
SoftwareSerial SIM5320_Serial(-1, SIM5320_SERIAL_TX_PIN);
which disables all rx functions from the library, and until now no problem.

Can you confirm that your system crashes also when sending?
Thanks
Alex

[allene222]

@alexgrauer
I use what @LuisVSa does for Rx and Serial2 for Tx. No software serial and no problems. My application is battery powered so it would never see 2 days in a row but I have built many units and have not seen a problem.

Allen

[alexgrauer]

Thanks @allene222.
Do you think I should have any problem with using SoftwareSerial in Only TX mode?

My system is actually using Hardware Serial for debugging, and two different Software Serials two connect to different peripherals. So far, so good!

[allene222]

@alexgrauer I don't know as I quit using SWSerial both Tx and Rx at the same time.

[jeroenst]

I switched to hardware serial which solved all my problems, I now have an uptime of 20 days.

[alexgrauer]

That's great @jeroenst.
I don't have that option because I need 3 different serials. But until 2 days ago the system was rebooting every few hours, and now is still working so I will assume the problem has been solved.

[jeroenst]

That is great news!!

[allene222]

@alexgrauer Perhaps I misread your post. You said it has been working for 2 weeks but the "until now" made me think it is no longer working. Working until now...

Perhaps you are saying it is working fine and has for 2 weeks.

Just to be clear, you are using the @LuisVSa for Rx and SW Serial for Tx and everything works fine.

I think I am out of IO pins so I will continue to share Serial 1 for debug and my Tx needs. But the next project might be different so I try and keep up on what works and what doesn't.

[alexgrauer]

@allene222, sorry about the confusion. Im a Spanish speaker trying to make sense in English, haha.

1. it's 2 days, not 2 weeks (I'll let you know if I get there without issues)
2. Yes its still working
3. Im using @LuisVSa Rx solution, and SW_Serial for Tx only.
   The library says:
   // If only one tx or rx wanted then use this as parameter for the unused pin
   #define SW_SERIAL_UNUSED_PIN -1

I read the entire file, and setting Rx to -1 makes every piece of code related to Rx not to run.
So far, so good... and hopefully it continues this way.

[tzanampeths]

Hi everybody,
I'm experiencing the wdt reset also. @alexgrauer is it possible to guide me to @LuisVSa solution please?
I'm unable to find the code in this conversation.
Thanks in advance!

[alexgrauer]

Hi @tzanampeths,

This is the way I've done it. Not sure if its the most efficient one, but it works. (BaudRate: 9600)

1. SoftwareSerial SIM5320_Serial(-1, SIM5320_SERIAL_TX_PIN);
   Define SoftwareSerial to only use TX functions

2. In the setup function:
   SIM5320_Serial.begin(9600);

pinMode(SIM5320_SERIAL_RX_PIN, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(SOFTWARE_Serial_Active_Pin), NODEMCU_External_Interrupt_Handle, FALLING);

timer1_attachInterrupt(onTimerISR);
timer1_enable(TIM_DIV16, TIM_EDGE, TIM_SINGLE);

3. Define variables to control de received info

#define SOFTWARE_SERIAL_BUFFER_SIZE 500

char. SOFTWARE_Serial_Rx_Buffer[SOFTWARE_SERIAL_BUFFER_SIZE];
uint16_t SOFTWARE_Serial_Chars_Received_Counter = 0;

uint8_t SOFTWARE_Serial_Bits_Received = 0;
byte SOFTWARE_Serial_Char_Received;
boolean SOFTWARE_Serial_New_Data_Received = false;

4. Create functions to manage external and timer_1 interruptions

void ICACHE_RAM_ATTR onTimerISR(){
bitWrite(SOFTWARE_Serial_Char_Received, SOFTWARE_Serial_Bits_Received, digitalRead(SOFTWARE_Serial_Active_Pin));
SOFTWARE_Serial_Bits_Received++;
if(SOFTWARE_Serial_Bits_Received == 8){
timer1_detachInterrupt();
SOFTWARE_Serial_Bits_Received = 0;
SOFTWARE_Serial_Rx_Buffer[SOFTWARE_Serial_Chars_Received_Counter] = SOFTWARE_Serial_Char_Received;
SOFTWARE_Serial_Chars_Received_Counter++;
SOFTWARE_Serial_New_Data_Received = true;
if(SOFTWARE_Serial_Chars_Received_Counter >= SOFTWARE_SERIAL_BUFFER_SIZE){
SOFTWARE_Serial_Chars_Received_Counter = 0;
}
attachInterrupt(digitalPinToInterrupt(SOFTWARE_Serial_Active_Pin), NODEMCU_External_Interrupt_Handle, FALLING);
}
else{
timer1_write(520); //104ms
}
}

void NODEMCU_External_Interrupt_Handle() {
timer1_attachInterrupt(onTimerISR);
timer1_write(780); //156ms
detachInterrupt(SIM5320_SERIAL_RX_PIN);
}

Let me know if you have any doubt.
Hope it helps

[tzanampeths]

Thank you very much @alexgrauer !
I've built my code using the h/w serial. But it's a pain... so I'll definitely give this a try.
All the best!

[mike89klein]

Hi @tzanampeths,

This is the way I've done it. Not sure if its the most efficient one, but it works. (BaudRate: 9600)

1. SoftwareSerial SIM5320_Serial(-1, SIM5320_SERIAL_TX_PIN);
   Define SoftwareSerial to only use TX functions
2. In the setup function:
   SIM5320_Serial.begin(9600);

pinMode(SIM5320_SERIAL_RX_PIN, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(SOFTWARE_Serial_Active_Pin), NODEMCU_External_Interrupt_Handle, FALLING);

timer1_attachInterrupt(onTimerISR);
timer1_enable(TIM_DIV16, TIM_EDGE, TIM_SINGLE);

1. Define variables to control de received info

#define SOFTWARE_SERIAL_BUFFER_SIZE 500

char. SOFTWARE_Serial_Rx_Buffer[SOFTWARE_SERIAL_BUFFER_SIZE];
uint16_t SOFTWARE_Serial_Chars_Received_Counter = 0;

uint8_t SOFTWARE_Serial_Bits_Received = 0;
byte SOFTWARE_Serial_Char_Received;
boolean SOFTWARE_Serial_New_Data_Received = false;

1. Create functions to manage external and timer_1 interruptions

void ICACHE_RAM_ATTR onTimerISR(){
bitWrite(SOFTWARE_Serial_Char_Received, SOFTWARE_Serial_Bits_Received, digitalRead(SOFTWARE_Serial_Active_Pin));
SOFTWARE_Serial_Bits_Received++;
if(SOFTWARE_Serial_Bits_Received == 8){
timer1_detachInterrupt();
SOFTWARE_Serial_Bits_Received = 0;
SOFTWARE_Serial_Rx_Buffer[SOFTWARE_Serial_Chars_Received_Counter] = SOFTWARE_Serial_Char_Received;
SOFTWARE_Serial_Chars_Received_Counter++;
SOFTWARE_Serial_New_Data_Received = true;
if(SOFTWARE_Serial_Chars_Received_Counter >= SOFTWARE_SERIAL_BUFFER_SIZE){
SOFTWARE_Serial_Chars_Received_Counter = 0;
}
attachInterrupt(digitalPinToInterrupt(SOFTWARE_Serial_Active_Pin), NODEMCU_External_Interrupt_Handle, FALLING);
}
else{
timer1_write(520); //104ms
}
}

void NODEMCU_External_Interrupt_Handle() {
timer1_attachInterrupt(onTimerISR);
timer1_write(780); //156ms
detachInterrupt(SIM5320_SERIAL_RX_PIN);
}

Let me know if you have any doubt.
Hope it helps

Sorry for my miscommunication, but what mean "SOFTWARE_Serial_Active_Pin"? I use GPIO 13 as SIM5320_SERIAL_RX_PIN and GPIO15 as SIM5320_SERIAL_TX_PINK, but where active pin? Sorry for dummy question. I am a beginner.

[alexgrauer]

@mike89klein,

Sorry about that. The SOFTWARE_Serial_Active_Pin is there because I was trying to use this method for two different SoftwareSerial communications at the same time.

Change all occurences of SOFTWARE_Serial_Active_Pin for SIM5320_SERIAL_RX_PIN.

Good luck, and let me know if it worked.

[mike89klein]

@alexgrauer when I change Sowtware_active_pin on RxPin, but data transfer from the GPS module does not occur. Me only need to receive the data. Can you explain why?

[alexgrauer]

Hi @mike89klein.

1. Its impossible to tell you the reason without seeing your code. I'll have a look if you send it to me.

2. Which module are you using?

3. This modules usually come with a baud rate of 115200, so for my code to work you should first look into changing the bajd rate to 9600 (check AT+IPREX command)

4. You have to activate GPS funtionality and then ask the module to send the GPS information every x seconds. (Check AT+CGPS and AT+CGPSINFO commands)

[mike89klein]

Hi @alexgrauer
1.Unfortunately I can not show the code,it does not belong to me. The WiFi module is also working together with GPS.
Work with WiFi and GPS data happens with help of ICACHE_RAM_ATTR.
2.NEO-6M
3.Baudrate 9600
4.Can you explaine how activate GPS funtionality?

[alexgrauer]

@mike89klein,

Have you tried using the NEO-6M module using the software serial library, without using my code? You should go for that first and get it working. Once that works go for my code.
I have never used that module before, but google is full of info about it.

https://www.youtube.com/watch?v=iWd0gCOYsdo

https://www.instructables.com/id/How-to-Interface-GPS-Module-NEO-6m-With-Arduino/

[mike89klein]

@alexgrsuder Yes, I use this module early with library TinyGPS, but for my programm need parsing without special library. And when I create project and run the programm, after some time get error: rst cause 4, boot mode (1,6). I use your fix, but in line "SoftwareSerial SIM5320_Serial(-1, SIM5320_SERIAL_TX_PIN)" instead of "-1", I wet SIM5320_SERIAL_RX_PIN. I use one Softserial.

[alexgrauer]

You can not use:
SoftwareSerial SIM5320_Serial(SIM5320_SERIAL_RX_PIN, SIM5320_SERIAL_TX_PIN)
at the same time as my code.

If you want to use the code I've made, then you have to use
SIM5320_Serial(-1, SIM5320_SERIAL_TX_PIN)

The code is actually doing the job of receiving the serial information instead of the library.

[mike89klein]

@alexgraurer you use code with SoftwareSerial library by plerup or Arduino integrated? And if eds dont receive information from gps with this code, then me need change some parametres NEO-6M?

[alexgrauer]

Honeslty, its hard to help without seeing any code.
I understand you cant share it, but if you want, create a new code just testing the gps module, i will help you with that, and you can then include it in your real code.
If not, it will be impossible.

[mike89klein]

@alexgraurer can I ask your mail?

[alexgrauer]

//edit by devyte
alexgrauer a t gee ma il dot com

[earlephilhower]

@dok-net, @devyte - Do you think we can close this? The long trail seems to have wandered over a bunch of area, and now I know @dok-net and @plerup have updated SWSerial quite a few times since it was opened.

[devyte]

Agreed. Closing due to age.
New SoftwareSerial issues should be tracked in the SoftwareSerial repo.