Version 4.0.0 crashing regularly

[Olverine]

When trying to run the 4.0.0 version of the firmware (compiled from the master branch), the firmware boots up but crashes after about 25 seconds. It then reboots and crashes after 25 seconds again. I am running OpenEVSE firmware version D7.1.2. I have tested it on a Huzza32, the openevse wifi board found on the openevse store, and a esp32 gateway-e. All of them behave the same way.

The logs from the esp32 gateway-e looks like the following:

OpenEVSE WiFI 5424
Firmware: 4.0.0
Build date: Mar 12 2021 09:35:17
IDF version: 3.30300.190916
Free: 307940
Connecting to SSID: RUT240_B714
Server started
Connected, IP: 192.168.1.219
E (24467) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (24467) task_wdt:  - loopTask (CPU 1)
E (24467) task_wdt: Tasks currently running:
E (24467) task_wdt: CPU 0: IDLE0
E (24467) task_wdt: CPU 1: loopTask
E (24467) task_wdt: Aborting.
abort() was called at PC 0x4011a2ec on core 0

ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000

Backtrace: 0x4008748b:0x3ffbe880 0x400877a9:0x3ffbe8a0 0x4011a2ec:0x3ffbe8c0 0x40083c4d:0x3ffbe8e0 0x40183003:0x3ffbc930 0x4011a9c2:0x3ffbc950 0x4008fac1:0x3ffbc970 0x4008e035:0x3ffbc9a0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x1a (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:800
ho 0 tail 12 room 4
load:0x40078000,len:8160
load:0x40080400,len:5732
entry 0x4008069c

[jeremypoulter]

Interesting, it is locking up somewhere and the watchdog is kicking in... Can you sent the /config ? Have you tried a factory reset?

[glynhudson]

I've just tested the latest version downloaded from here: https://github.com/OpenEVSE/ESP32_WiFi_V3.x/actions/runs/629987476#artifacts

On a Huzzah32 and OpenEVSE WiFi V1 module, it seems to work fine for me. I'm unable to replicate this issue. @Olverine could you try using the pre-compiled binaries from the link above the rule out any local compiling issues.

[Olverine]

Interesting, it is locking up somewhere and the watchdog is kicking in... Can you sent the /config ? Have you tried a factory reset?

/config looks like the following:

{
	"firmware":"D7.1.2",
	"protocol":"-",
	"espflash":4194304,
	"version":"4.0.0",
	"diodet":0,
	"gfcit":0,
	"groundt":0,
	"relayt":0,
	"ventt":0,
	"tempt":0,
	"service":1,
	"scale":220,
	"offset":0,
	"mqtt_supported_protocols":["mqtt","mqtts"],
	"http_supported_protocols":["http","https"],
	"ssid":"RUT240_B714",
	"pass":"_DUMMY_PASSWORD",
	"www_username":"",
	"www_password":"",
	"hostname":"openevse-5424",
	"sntp_hostname":"pool.ntp.org",
	"time_zone":"",
	"emoncms_server":"https://data.openevse.com/emoncms",
	"emoncms_node":"",
	"emoncms_apikey":"",
	"emoncms_fingerprint":"",
	"mqtt_server":"192.168.1.1",
	"mqtt_port":1883,
	"mqtt_topic":"5424",
	"mqtt_user":"",
	"mqtt_pass":"",
	"mqtt_solar":"",
	"mqtt_grid_ie":"emon/emonpi/power1",
	"mqtt_vrms":"emon/emonpi/vrms",
	"mqtt_announce_topic":"openevse/announce/5424",
	"ohm":"",
	"divert_PV_ratio":1.1,
	"divert_attack_smoothing_factor":0.4,
	"divert_decay_smoothing_factor":0.05,
	"divert_min_charge_time":600,
	"tesla_username":"",
	"tesla_password":"",
	"tesla_vehidx":-1,
	"flags":16394,
	"emoncms_enabled":false,
	"mqtt_enabled":true,
	"mqtt_reject_unauthorized":true,
	"ohm_enabled":false,
	"sntp_enabled":true,
	"tesla_enabled":false,
	"divert_enabled":false,
	"pause_uses_disabled":false,
	"mqtt_protocol":"mqtt",
	"charge_mode":"fast"
}

Factory reset did not help.

On a Huzzah32 and OpenEVSE WiFi V1 module, it seems to work fine for me. I'm unable to replicate this issue. @Olverine could you try using the pre-compiled binaries from the link above the rule out any local compiling issues.

I tried the pre-compiled binaries. I still have the same issue.

It does not crash as long as it isn't connected to the openevse controller however. Any ideas?

[jeremypoulter]

@Olverine are you able to send the output of the RAPI monitor? http://openevse-xxxx.local/term.html?evse

[Olverine]

@Olverine are you able to send the output of the RAPI monitor? http://openevse-xxxx.local/term.html?evse

This is what I'm getting between starting and crashing:

$GV^35
$OK D7.1.2 5.1.3^67
$GF^25
$OK 0 0 0^30
$GE^26
$OK 12 8000^2B
$GC^20
$OK 6 16 12 12^11
$GU^36
$OK 0 0^20
$SY 5 6^2D
$NK^21
$GS^30
$OK fe 0 01 0200^10
$GP^33
$OK 250 236 -2560^2C
$F0 0^42
$OK^20
$FB 5^35
$OK^20
$FP 0 0 OpenEVSE WiFI^32
$OK^20
$FP 13 0       ^20
$OK^20
$FP 0 1 4.0.0^27
$OK^20
$FP 5 1       ^16
$OK^20
$FP 11 1       ^23
$OK^20
$GT^37
$OK 21 2 19 4 54 56^2F
$GA^22
$OK 220 0^20
$FP 0 0 Hostname:^0F
$OK^20
$FP 9 0       ^1B
$OK^20
$FP 15 0       ^26
$OK^20
$FP 0 1 openevse-5424^28
$OK^20
$FP 13 1       ^21
$OK^20
$FP 0 0 IP Address:^47
$OK^20
$FP 11 0       ^22
$OK^20
$FP 0 1 192.168.1.219^33
$OK^20
$FP 13 1       ^21
$OK^20
$FP 0 0 zzZ Sleeping Zzz^3D
$OK^20
$FP 0 1 Date 19/03/2021^0D
$OK^20
$FP 15 1       ^27
$OK^20

[jeremypoulter]

Not sure that gives me any more clues... Really I need to move to the latest Platform IO BSP which includes the exception decoding...

[glynhudson]

I'm unable to replicate the issue V4.0.0 has been working fine on all the units I've tested it on. Try flashing the pre-compiled V4.0 .hex from the releases to climate any compiling issues https://github.com/OpenEVSE/ESP32_WiFi_V4.x/releases/tag/V4.0.0.BETA

[Olverine]

I have tried the pre-compiled binaries without success. This is very strange since I get the same results on all units. V3.3.2 still runs without problems on the same devices. I must be doing something wrong. I will let you know if I find the problem.

[glynhudson]

Could you try V4.0.1 pre-compiled? https://github.com/OpenEVSE/ESP32_WiFi_V4.x/releases/tag/4.0.1

There must be some issue with your hardware, no other user has reported stability issues with V4.0.0. I've been unable to replicate

[jeremypoulter]

I think I have been able to replicate and potentially resolve this, I certainly got my device stuck in a very similar case. There is basically a race condition where the EVSE monitor task can get started twice causing MicroTasks to get stuck in a loop, as this was triggered by detecting a connection to the RAPI it would fit with the issue described here. Will submit a patch shortly.