BW-SHP2 (BLITZWOLF_BWSHPX) some measurements are zero

[ruimarinho]

Question
The device is crashing sometime after boot and sensor information is not available (always 0W).

Already tried factory reset with no change.

crash
[109684] [DEBUG] Latest crash was at 39608 ms after boot
[109685] [DEBUG] Reason of restart: 2
[109685] [DEBUG] Exception cause: 29
[109686] [DEBUG] epc1=0x4020e606 epc2=0x00000000 epc3=0x00000000
[109691] [DEBUG] excvaddr=0x00000000 depc=0x00000000
[109696] sp=0x3ffffd20 end=0x3fffffb0 saved=0x0080

[109700] [DEBUG] >>>stack>>>
[DEBUG] 3ffffd20: 3fff8684 3fffa694 3fff073c 4020d201
[DEBUG] 3ffffd30: 00000b95 00000b95 00000b95 00000000
[DEBUG] 3ffffd40: 00000002 3fff81ac 3fff073c 402164f5
[DEBUG] 3ffffd50: 00000000 00000000 00000000 3fff63f4
[DEBUG] 3ffffd60: 00000002 3fff63f4 3fff8048 40216583
[DEBUG] 3ffffd70: 3ffe94d0 00000000 3fffa764 00002000
[DEBUG] 3ffffd80: 3fff6a44 00000002 000000c0 000000a8
[DEBUG] 3ffffd90: 00000004 00000002 3ffffdd0 00000000
[DEBUG] <<<stack<<<

Device information

[101904] [MAIN] ESPURNA 1.13.6-dev
[101904] [MAIN] [email protected]
[101904] [MAIN] http://tinkerman.cat

[101904] [MAIN] CPU chip ID: 0x159532
[101907] [MAIN] CPU frequency: 80 MHz
[101910] [MAIN] SDK version: 1.5.3(aec24ac9)
[101914] [MAIN] Core version: 2.3.0
[101917] [MAIN] Core revision: 9826c6d
[101921] [MAIN] Build time: 1563050041
[101924]
[101925] [MAIN] Flash chip ID: 0x1440A1
[101929] [MAIN] Flash speed: 40000000 Hz
[101932] [MAIN] Flash mode: DOUT
[101935]
[101936] [MAIN] Flash size (CHIP)   :  1048576 bytes /  256 sectors (   0 to  255)
[101944] [MAIN] Flash size (SDK)    :  1048576 bytes /  256 sectors (   0 to  255)
[101950] [MAIN] Reserved            :     4096 bytes /    1 sectors (   0 to    0)
[101957] [MAIN] Firmware size       :   496416 bytes /  122 sectors (   1 to  122)
[101965] [MAIN] Max OTA size        :   524288 bytes /  128 sectors ( 123 to  250)
[101972] [MAIN] EEPROM size         :     4096 bytes /    1 sectors ( 251 to  251)
[101979] [MAIN] Reserved            :    16384 bytes /    4 sectors ( 252 to  255)
[101986]
[101987] [MAIN] EEPROM sectors: 251, 250
[101991] [MAIN] EEPROM current: 251
[101995]
[101996] [MAIN] EEPROM:  4096 bytes initially |  1587 bytes used (38%) |  2509 bytes free (61%)
[102004] [MAIN] Heap  : 34912 bytes initially | 22920 bytes used (65%) | 11992 bytes free (34%)
[102013] [MAIN] Stack :  4096 bytes initially |  1684 bytes used (41%) |  2412 bytes free (58%)
[102020]
[102021] [MAIN] Boot version: 4
[102024] [MAIN] Boot mode: 1
[102027] [MAIN] Last reset reason: Exception
[102031] [MAIN] Last reset info: Fatal exception:29 flag:2 (EXCEPTION) epc1:0x4020e606 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000
[102043]
[102044] [MAIN] Board: BLITZWOLF_BWSHPX
[102048] [MAIN] Support: ALEXA API BROKER BUTTON DEBUG_SERIAL DEBUG_TELNET DEBUG_WEB DOMOTICZ HOMEASSISTANT LED MDNS_SERVER MQTT NTP SCHEDULER SENSOR TELNET TERMINAL THINGSPEAK WEB
[102063] [MAIN] Sensors: HLW8012
[102066] [MAIN] WebUI image: SENSOR
[102069]
[102070] [MAIN] Firmware MD5: 205e5206e111e60d5939c8c7f9c0f2d0
[102076] [MAIN] Power: 3152 mV
[102078] [MAIN] Power saving delay value: 10 ms
[102082]

[mcspr]

Can you decode the stack trace? Or you can upload the .pio/build/env/firmware.elf
Crash 28/29 does look like OOM issue, judging from the heap amount too.
Is it strictly on boot, without any interaction at all? Or does it happen like in #1824 , opening WebUI / reloading it?

Can't comment on 0 energy values yet, don't see any obvious issues running SHPX_V23 firmware.

[ruimarinho]

Interesting @mcspr! I didn't know the root cause for it but it's exactly that - if I keep refreshing the page, eventually it crashes. Do you want to close this one as duplicate?

What's the right way to decode the stack trace?

[mcspr]

If you do actively use web, it does look like a duplicate. Do you use Chrome too, like #1824?

I will add this to the wiki eventually... One recent crash problem with thingspeak involved decoding:
#1752 (comment)

• You would need to know where are the toolchain files are. For platformio, common location across platforms is in the user's home directory - ~/.platformio/packages/toolchain-xtensa/
• addr2line is a manual option for decoding one address at a time
• https://github.com/me21/EspArduinoExceptionDecoder script can parse only the stack trace (between >>>stack<<< lines) using the -s option.

One problem discovered was that code lines may be incorrect for some of the addresses, not really sure about the reason. To mitigate that, one can use the current toolchain files from https://github.com/earlephilhower/esp-quick-toolchain/releases/tag/2.5.0-4

[ruimarinho]

@mcspr this is what I got:

stack:
0x4020d201: ArduinoJson::Internals::JsonPrintable<ArduinoJson::JsonObject>::measureLength() const at /espurna/code/espurna/ws.ino:528
0x402164f5: wsSend(unsigned int, ArduinoJson::JsonObject&) at /espurna/code/espurna/ws.ino:528
0x40216583: _wsStart(unsigned int) at /espurna/code/espurna/ws.ino:528
0x40220c4a: AsyncWebSocketResponse::_ack(AsyncWebServerRequest*, unsigned int, unsigned int) at /espurna/code/.piolibdeps/ESP Async WebServer/src/AsyncWebSocket.cpp:814

[ruimarinho]

The lack of sensor reading is not related to the crash then. I wonder if I have a faulty/dead sensor?

[mcspr]

No experience with that, really. (continuing #1038? and i thought that was related to the relay-on)

We do see half of the values though, filtering may still be a problem? If you can, this

espurna/code/espurna/sensor.ino

Line 1508 in 4469ec8

value_raw = magnitude.sensor->value(magnitude.local);

spot receives raw value as-is from the HLW library. Maybe some tracing can show if that's a problem with later calculations?

HLW8012 adaptation for SHP chip may be wrong, maybe? Logic flow sometimes resets values to 0 https://github.com/xoseperez/hlw8012

One interesting problem that #1802 mentioned regarding ESP in general / board design - could it be EM interference?

[mcspr]

@ruimarinho have you had any chance to check the raw output values? and have you tried this with ESPEasy or Tasmota? (i think espeasy uses Xose's library and tasmota uses it's own custom module)

What are you using to test the output values?

As I mentioned above, hwl library sometimes resets output values to 0. One of those conditions is pulse-timeout after switching to the current measurement mode (cf1 pin measures both current and voltage, depending on which digital signal we send to the sel pin; 0 / LOW for shp2 hardware)
https://github.com/xoseperez/hlw8012/blob/master/src/HLW8012.h#L45-L53

ref: https://tinkerman.cat/post/hlw8012-ic-new-sonoff-pow

[ruimarinho]

@mcspr can I use espurna's web interface to upload Tasmota's firmware?

I tried using a halogen bulb as well as a LED bulb.

[mcspr]

Yes, this was already tried before and seems to be working ok. Might briefly break setting, but reboot will fix things. Just make sure that you use the same SDK / Core versions

[ruimarinho]

Tasmota is already on 2.5.x but I was able to compile with 2.3.0. Thanks for the tip - the upgrade worked. The sensor still reads 0 power even with a custom HLW8012 implementation. At this point I am convinced I have a faulty power sensing chip.

[ruimarinho]

Not sure why but sometimes when I toggle on/off quickly I get what appear to be instantaneous (erroneous..?) readings.

The lamp is like 40W.

[mcspr]

Weird. And the same thing happens with something like laptop power adapter?
Essentially, it thinks there is no load (as I see the same result as #1823 (comment) when disconnecting any load but keeping relay on. but without the strange active power readings)

Referencing HLW source again, it counts CF pin pulses to calculate energy value (as it seemingly changes from time to time?)
https://github.com/xoseperez/hlw8012/blob/2dace562c339e77a2889446d461e8e56048fe634/src/HLW8012.cpp#L145
And more interrupts => more active power:
https://github.com/xoseperez/hlw8012/blob/2dace562c339e77a2889446d461e8e56048fe634/src/HLW8012.cpp#L106

[ruimarinho]

Yes, same behavior.

When toggling on/off rapidly, sometimes I get an instantaneous reading like before, but it seems abnormal as the charger is rated to 60W: