Notifications
Clear all
Topic starter
2021-03-24 3:54 pm
Hi gang,
Got an oddball problem. I've been playing with a few projects using the ESP-WROOM-32 SBC. I often send debugging info to the serial port, and they run for days. For example, I set the time every Sunday at 4 AM on a DS3231 IIC clock using NTP (to deal with the DST time change.) And I also send emails with them, etc.
It seems they ALL lock up in about 3 days if I disconnect them from the computer serial port (using a Mac if it matters.) They run for weeks if I leave them connected to the computer. I run them with a 5-volt supply only. This smells like a memory issue, but that's just a guess. I have done this with an Arduino Nano, and those fellows run for months, sending stuff to a not connected serial port. The issue seems specific to an ESP-WROOM-32 (KeeYees Development boards) I get from Amazon.
Clearly, I can comment out all the Serial.print statements before running them stand alone, but I am looking for the root cause. Has anyone else encountered this? Are any suggestions other than commenting out the print statements? Nanos don't seem to care, but ESP32s do.
- Paul VE1DX
2021-03-24 4:23 pm
Ive not come across your problem but it sprang to mind that as your program was running you could periodically check free memory (some sort of malloc() call) and if memory is getting low light up an LED attached to your board or something like that. Also commenting out all your print statements, or better changing them all to debug.print and turning debug off at the start of the program, will at least enable you to see if your board then runs for more than 3 days so as to confirm if the print statements that cause your issue or you need to look elsewhere for the culprit.
Topic starter
2021-03-24 4:30 pm
@byron thanks, both suggestions make a heck of a lot of sense. I like the malloc() call and flashing LED idea in particular. The Serial.print(s) might be a red herring, so I guess checking memory will confirm or deny if something is not releasing things. If that doesn't shed light on the issue, I'll try the debug.print idea.
- Paul VE1DX
2021-03-24 4:39 pm
@VE1DX,
Just gonna toss this into the stream, as I've seen similar way back-in-the-day... any chance that the serial buffer is over flowing? Not sure what level of flow control you are using, but if the UART thinks all is normal, except that no one is allowing data to be sent, this could cause a problem.
Possible fixes:
1. Reset the transmit buffer every so often. Could be tricky if you are not sure when transmission is working well (mac serial port connected).
2. If you are able to detect that the xmit buffer is getting packed, you could disable the "Prints", using an if statement.
Nothing pretty, I'm afraid.
Dale
--
Dale
Topic starter
2021-04-01 3:01 pm
@dale and @byron Thank you both for the thoughtful responses. Because of bad weather and a dozen other things, I'm just getting back to this now. I had about a week to think about it. I have email capability from the ESP32, so it occurred to me, "Why not use that?"
What I am going to do is sample the heap and stack sizes at several places in the program (and a couple of times a day) and send myself the "memory count" values. That ought to give me a clue, and more info than a winking LED, looking at the UART, commenting out prints, etc. The purpose of the project is to use email once a week to set the time - and this all came from the DS3231 not understanding DST.
I'll give this a shot for a few days and see if it tells me anything. I can also send any other debugging info I dream up. SMTP is my friend. I just needed time to ponder this and to determine the best way. The answer was looking me in the face. Oh well . . . we're all getting older and this lockdown is making me a bit stunned! 😱 🤣
- Paul VE1DX