Soft WDT reset on interrupts #5885
Comments
|
I wonder if this is somewhat related to #5788 - even though I'm not using SPIFFS at all? |
|
Debugging this further, the MCVE code actually works.... (if you add the missing Serial.begin(115200).
Commenting out the OTA updates check has no effect and it still crashes.
It still crashes. and I don't have any idea why now :( The full code I'm using is here: |
|
Pinging @d-a-v - he seems the master of interrupts on ESP8266 from everything I've read. This may be something simple that I just haven't been able to get my head around... Interrupts seem like unstable voodoo at the moment :( |
|
I am far from being the interrupt master :)
Right after boot, or after some time ? I suggest to use git version master branch instead of v2.5.0. |
|
I started adding code to the MCVE - but couldn't make it crash again until I hit the entire program I have :( When I'm looking at the serial output, I can see a number of lines print, then there's a pause, sometimes there's a flood of loops run, then there's the reset again. It seems to do 2 x loops, then the pause, then sometimes a rush, then reset. I'm going to try putting in a whole lot more Serial.print debug into my code and see what I can figure out before the crash. This is my first experiment in interrupts - so I might be missing lots - but I've been finding what I can from your replies to other interrupt bug reports to hopefully get it right. Functional Interrupts - do you have any links to information about this? As mentioned, this is my first attempt here. |
|
Interesting news - when running with Debug port serial and Core+WiFi debug, see the following output: At this point, the crash happens. This code has millis() commented out in the interrupt - so I'm guessing we can rule that bit out... However I do note that I seem to get many more interrupts than I was expecting... I didn't see that when filtering for +50ms - however I wonder if the frequency of interrupts may be part of the problem? |
|
This looks like either an issue in the user's code or another instance of #5784 . |
|
I have the same problem. |
|
Are you able to reproduce the bug with core-release-2.4.2, or better with core-git-master ? |
|
The problem does not occur in 2.4.2, only in 2.5.0 |
|
I have a completely non-verified hunch on the problem... As the crash always happened at the 'scandone' print, I think that something to do with the wifi library is blocking or causing interrupts to stack up. I did actually find out that the signal I was monitoring was dirty as hell causing ~40-60k interrupts per second (using CHANGE). That may well be related. As I can't easily change the circuit, I ended up using a 'best out of 10' polling method instead. |
|
Unfortunately I can not put the master to run, it seems that incorporated SDFat in it, this is generating several conflicts in my project. |
|
It is supposed to be compatible and this version will be in core-release-2.5.1 soon, |
|
I have been battling this issue trying to get 9-bit soft serial to work reliably. I finally got some output from the SDK logging and discovered this: It looks like the sdk doesn't work well when ISRs take longer than 50us, so high speed software serial is pretty much out. |
Basic Infos
Platform
Problem Description
When using interrupts to count transitions (CHANGE), I get a stack trace and the program crashes. Have also tried with FALLING, but still same issue. I believe I've marked everything I need.
MCVE Sketch
Debug Messages
The text was updated successfully, but these errors were encountered: