search

mobizt / ESP32-Mail-Client

The complete and secured Mail Client for ESP32, sending and reading the E-mail through the SMTP and IMAP servers.
MIT License
90 stars 33 forks source link

Task watchdog got triggered #78

Closed Materie62 closed 3 years ago

Materie62 commented 3 years ago

Dear Mobizt,

I'm using your mail code on an ESP32 and for some reason the ESP32 watchdog is triggered. A got it working, so the basics are ok but the watchdog is triggered again. The network speed is fast enough (>200Mb/s) as well as the mail server. The watchdog trigger is reproducible. More info, using ESP32-Mail-Client version 2.15 and ESP32 is running at maximum clk speed.

With the debug switch on a get the following:

[DEBUG] - INFO: connecting to SMTP server... [DEBUG] - [DEBUG] - 587 [DEBUG] - INFO: starting socket [DEBUG] - INFO: connecting to Server... [DEBUG] - INFO: server connected [DEBUG] - INFO: begin STARTTLS handshake [DEBUG] - 220 ESMTP

[DEBUG] - INFO: send SMTP command extended HELO [DEBUG] - 250- 250-STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 31457280 250 AUTH LOGIN PLAIN

[DEBUG] - INFO: send STARTTLS protocol command [DEBUG] - 220 ready for tls

[DEBUG] - INFO: seeding the random number generator [DEBUG] - INFO: setting up the SSL/TLS structure... [DEBUG] - INFO: setting hostname for TLS session... [DEBUG] - INFO: performing the SSL/TLS handshake... E (26551) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (26551) task_wdt: - async_tcp (CPU 0/1) E (26551) task_wdt: Tasks currently running: E (26551) task_wdt: CPU 0: IDLE0 E (26551) task_wdt: CPU 1: IDLE1 E (26551) task_wdt: Aborting. abort() was called at PC 0x400ed267 on core 0

Backtrace: 0x4009243c:0x3ffbe190 0x4009266d:0x3ffbe1b0 0x400ed267:0x3ffbe1d0 0x400859f9:0x3ffbe1f0 0x4019547b:0x3ffbc360 0x400eed4a:0x3ffbc380 0x40090345:0x3ffbc3a0 0x4008eb51:0x3ffbc3c0

Rebooting...

Do you have suggestions?

Greetings,

Roland

mobizt commented 3 years ago

Nothing is related to the library because It does not use RTOS task in the library. I don't know you're trying to do, check your code.

Materie62 commented 3 years ago

First of all thanks for the fast responce. The code is the plain vanilla example code that one can find on the net (see below). I've the impression that something in your code (i.e. performing the SSL/TLS handshake...) is taken more than 5 seconds and holds up the processor. As a consequence the watchdog can't be resetted within this 5 seconds. If I search the net a suggestion is to include a small delay in the code that enables the watchdog to be resetted. However I can't include that in your code (I would not know were to begin). And I'm not using RTOS tasks in my program and the program is running on one core only.

smtpData.setLogin(String(SMTPServer), atoi(SMTPPort), String(SMTPUserName), String(SMTPPassword)); smtpData.setSender("ESP32", "...recipient mail address..."); smtpData.setPriority("High"); smtpData.setSubject("Test mail"); smtpData.addRecipient(String(Recipient)); smtpData.setMessage("<div style=\"color:#2f4468;\">

Hello World!

- Sent from ESP32 board

", true); smtpData.setDebug(true);

smtpData.setSendCallback(sendCallback); delay(1);

if (!MailClient.sendMail(smtpData)) Serial.println("Error sending Email, " + MailClient.smtpErrorReason()); delay(1); printf("Test mail send\n\r"); smtpData.empty(); //Clear all the data from the smtpData object

mobizt commented 3 years ago

You may send email with invalid port or not a SMTP server.

mobizt commented 3 years ago 
[DEBUG] - INFO: connecting to SMTP server...
[DEBUG] - <------- This line should show the SMTP server, but it's empty in your code or you delete it before post?
[DEBUG] - 587
mobizt commented 3 years ago

The SSL handshake is actually taken from WiFiClientSecure.h and ssl_client.h from core library, nothing wrong with that unless you're connecting to server that is not the real smtp or even web server.

Materie62 commented 3 years ago

The line missing is the SMTP server which I use. Copying text into the github interface seems to be translated into html code (?). I did mention an SMTP server on this line: [DEBUG] - INFO: connecting to SMTP server... [DEBUG] - SMTP server [DEBUG] - 587

I'll have a look in your last comment regarding not being the real SMTP or webserver. I'll try another SMTP server this evening and come back to this. I'll also try to change the default watchdog time out from 5 seconds to whatever time and see if this resolves the issue. Keep you posted.

mobizt commented 3 years ago

The library was intensive test for years for many SMTP servers then check your setup.

Materie62 commented 3 years ago

I'm sure I'm making a mistake somewhere. But I'm not seeing it thats why I reached out to you.

Materie62 commented 3 years ago

Dear Mobizt, I solved the issue. Some background information, I'm designing software for an environmental sensor based on the LiliyGo TTGO T-Higrow. The program has a webinterface to be able to communicate with the sensor and has more other features (sleep mode, Domoticz enabled, etc, etc). I’ve added a function in the environmental sensor program to test the mail settings. By pressing a “Test Mail” button on the webinterface I addressed the test mail function. This test mail function contains the plain vanilla code for sending mail. When pressing the “Test Mail” button an event handler (server.on) in the environmental sensor program responses. From this event handler I call the test mail function. Calling the test mail function from within the event handler caused the problem. What you can see is that the time-out in the send mail instruction doesn’t function anymore. Basically the send mail seems to wait indefinitely for something. In the end the watchdog steps in and resets the ESP32. Prolonging the watchdog time didn’t help, it simply gets stuck. Please note that this effect can only be provoked when calling the send mail instructions from the web server handler. To circumvent the issue a set a boolean flag in the event handler indicating a test mail is required. In the main program loop the Boolean flag is tested and when true a test mail is send. Problem solved.

mobizt commented 3 years ago

The facts is that if you can't send email, you also can't access to the server via https too even using the HTTPClient or WiFiClientSecure to perform any GET/POST request.

The problem may be insufficient memory used in SSL handshaking process which required by mbedTLS or the WiFi is not ready at that time.

Materie62 commented 3 years ago

I don't use https and simple http. But indeed, I do have the impressions that the problem is caused by a lack of resources (i.e. not enough memory). Anyways if somebody else faces the same problem I hope the above comment helps.

mobizt commented 3 years ago

This is the implementation conflicts, you need to solve by debugging instead by going into the source of WiFi library.

I hint you about trying to making your own https request to some server e.g. google.com and you'll will face the same result.

Materie62 commented 3 years ago

Hmm, I'm not sure what you mean. Can you elaborate?

mobizt commented 3 years ago

I mean your code causes the conflicts in the server connection not only with this library, you can create the HTTPS connection to some server within the event callback function (see the example in Arduino IDE) , you will get the same result i.e. can't connect to the server.

If you want to know the reason why you need to debug by looking into the source code of WiFi libraries.

The library use the enhanced WiFiClientSecure version to handle the STARTTLS command use in SMTP/IMAP servers secured connection.

That's why I said it's not related to the library unless your implementation may wrong.

mobizt commented 3 years ago

You solve your issue but don't know the actual root cause.

No one known your implementation (code) and how you implement the deep sleep in which mode.

Materie62 commented 3 years ago

You're correct. I don't know the actual cause. Only found a way to make it work and.... thanks to you! Simply by saying that the watchdog trigger is abnormal led me to suspect that the cause was in my program and forced me to dig in deeper. Which I did. This is how debugging goes. Some small remarks can lead to a solution. What I wanted to convey with the background information is that the program in the ESP32 is big and uses a lot of resources (flash memory, tickers, deep sleep modes, I2C, ADC, etc.). But in finding the solution I switched off all these features one by one to find the cause. In the end it seems to be a combination in the use of the ESP32 webserver event handler and mail client. I don't have enough resources (time) to find out the root cause. I hope that the above helps other people and perhaps give you pointers in the future development of your great software.