Exception reporting?

[Hal Sampson]

Getting occasional exception 0 reboots on simple YM-WS-3 plugs:

With 8.3.1.6:

01:25:26 RSL: tele/tasmota/INFO3 = {"RestartReason":{"Exception":0,"Reason":"Exception","EPC":["4025f43a","00000000","00000000"],"EXCVADDR":"3fff50bc","DEPC":"00000000","CallChain":["402693ac","40268cf7","402685b7","40246ec4","40000f49","40000f49","40000e19","401059c9","401059cf","4010000d","402674a0","40267451","401046c9","40105811","4024ce12","401053f6","40104d45","4010101c","401052f9","401047bb","401047b8","4010371b","4010101c","4000050c","4024d1fc","4024ce12","4024ce12","40287d27","4024d749","4024ce12","4024cd48"]}}

With 8.3.1:

00:00:09 RSL: tele/tasmota/INFO3 = {"RestartReason":{"Exception":0,"Reason":"Exception","EPC":["4025dc7c","00000000","00000000"],"EXCVADDR":"0000000e","DEPC":"00000000","CallChain":["40267c20","401010b1","401060a1","4026756b","40266e2b","4024570c","40000f49","40000f49","40000e19","40105a41","40105a47","4010000d","40265d14","40265cc5","40101090","40102688","4010593b","4010321f","40103400","40101090","40102688","4010593b","4010321f","40103400","401038c2","402845b6","4000050c","401035e4","4024b03e","4024b6a2","4024bfd9"]}}

Are symbol tables posted online anywhere to quickly find where the exceptions are occurring or should I set up the tool chain myself?  Any better place/way to report exceptions?

[Hal Sampson]

These occasional reboots, sometimes logging various exceptions, appeared to happen much more frequently with an access point, another samrt plug, power cord, or finger nearby. I checked ESP8266 GPIO pins configured as "None" and found them floating, so I suspected they were picking up transients from local electric fields. Floating CMOS inputs can cause power supply current spikes which might be causing reboots, so the "None" GPIO pins should likely be configured with EP8266 internal pull-downs (or maybe pullups in some cases).

Try configuring any GPIOs set to "None" instead set as an otherwise unused LED (e.g. LED4) to see if the reboots go away. GPIO 9 and 10 in particular were causing trouble for me, with slow command response as well. I've done a Reset 99 and have been watching Boot Count -- none on 6 devices for 6+ hours now (much better than before when near other devices -- e.g. two devices on a duplex outlet). If this workaround also helps you we should let Theo know, e.g. by filing a bug/suggestion.

[Michael Ingraham]

Hal,

As I mentioned in the other post, I have a HW-655 relay device with an ESP-01S daughterboard that I use as an appliance monitor using a PZEM-004T to detect when the dryer is running or not. I don't actually use the onboard relay. The device was just a convenient way of using 5V since that's what the PZEM requires. The HW-655 has on board voltage circuitry to run the ESP-01S at 3.3V. For my use case, the WDT reboots are more of a nuisance since it's not to critical if I detect the dryer going off immediately. Waiting for a one minute reboot to detect that the dryer is off is acceptable. But I would love to eliminate the reboots and the additional flash writes that it consumes.

My setup only has the two serial GPIO configured for comms with the PZEM. I had the rest of the GPIO configured as `None`, nine in all (GPIO9 & GPIO10 are allocated for the flash memory interface). Unfortunately, there aren't enough LED components available to cover all of these. Nevertheless, I used LED1-LED4, LED1i-LED4i (not really recommended since these are still the "same" LED in the code), and LEDLink hoping that having something assigned to those free GPIO would alleviate the WDT reboots this device experiences. No joy :(

Do you think using Button<x> or Button<x>n would be appropriate to test your suggestion?

Theo recently added an exception fix (sometimes WDT) that some rules processing was causing when processing triggers based on JSON results. For completeness of this specific WDT issue (which I don't think is related), I went ahead and upgraded this device to the latest version (8.3.1.6).

Regards.

Mike

[Hal Sampson]

I selected "LED4" instead of "None" for all unused GPIOs. This made the frequent reboots on two brands of smart plugs go away completely. Button<x.> should also work since it would configure an internal pullup. Button<x> would be a better choice in case something is actually connected to the pin, but it would add confusing buttons to the Main http UI, if you use that.

(While some units were open, I added  a resistor and thermistor to measure temperature:

X3 ESP8266EX module with 11 edge connections, in YM-WS-3:

U1 ESP pins

1   24   GPIO5

2   16   GPIO4  

3   12   GPIO13  Blue button LED

4    6    ADC in  -----------------------\

5    8    GPIO16  Grn link LED      |

                                                     |

6    1,3,4  Vdd ------ 33.2K ---------+

7    Gnd  ----  Themistor   ----------/              

8    25  GPIO3 U0RxD flash programming

9    26  GPIO1 U0TxD flash programming, Button

10  10  GPIO12

11    9  GPIO14     relay

GPIO0 pin 15 -> anode of small blue LED on module

AdcParam 2, 33200, 10000, 3950

The attic fan control used to go offline as the motor was switched on or off -- that appears to be fixed. Now I can also see how hot the attic gets and control based on temperature.)

The typically unused ADC pin picks up enough 50/60 Hz that it could likely be used to synchronize relay actions for close to zero-crossing switching (would need relay close/open response time settings).That would help with transients and extend relay contact lifespan.

Hal

[Michael Ingraham]

Only Relay<x> add web UI buttons.

I switched from LEDs to Buttons & Switches to continue testing.

[Hal Sampson]

OK, then Buttons and Switches are a better choice than LEDs for unused "None" GPIOs (to avoid possible high pin current if pins are actually connected to something).

Here's a Windoze script I use to check Boot Counts (none so far):

@echo off

setLocal EnableDelayedExpansion

set errs=0

call :chk 1111

call :chk 2222

...

call :chk 9999

rem if !errs! GTR 0 echo !errs! errors & pause

goto :EOF

:chk

<NUL set /P a="%1 "

curl -s http://tasmota-%1/in? | findstr /C:"Boot Count}20" >NUL

if not ERRORLEVEL 1 goto :EOF

echo booted!

set /A errs=errs+1

echo Check exception log?

pause

echo Resetting

curl -s http://tasmota-%1/cm?cmnd=reset+99 > NUL

goto :EOF

[Michael Ingraham]

Hal - Depending on which commit and variant you are using, the map files for each is posted in the ~15-day rolling archive - http://thehackbox.org/tasmota/archive/

[Michael Ingraham]

Unfortunately, even assigning them as Buttons & Switches, the ESP still reboots due to WDT.