[BUG] Calling id(rgb8x32)->set_display_off() at boot crashes EspHoMaTriXv2
popy2k14 opened this issue · 10 comments
Bug report
Describe the bug
When adding the switch:
switch:
- platform: template
name: "Display"
id: displaycontrol
icon: "mdi:power"
restore_mode: ALWAYS_OFF
lambda: |-
return id(rgb8x32)->show_display;
turn_on_action:
lambda: |-
id(rgb8x32)->set_display_on();
turn_off_action:
lambda: |-
id(rgb8x32)->set_display_off();
The important part is: restore_mode: ALWAYS_OFF
which calls "id(rgb8x32)->set_display_off();" at boot and crashes EspHoMaTriXv2.
Additional information
- used Hardware:
- ESP32 (Ulanzi TC0001)
- EspHoMaTriXv2 version: [e.g. 2024.3.0] also tested with 2024.1.0, ...
To Reproduce
Steps to reproduce the behavior:
- Flash a v2 with an switch in the config (at least with the display switch part)
- Boot it -> it should crash
- To revive it, flash another binary without the switch
Expected behavior
It should not crash
Configuration
see switch above
Logs
Serial log of the crash:
...
[D][template.switch:046]: Restored state OFF
[D][switch:016]: 'Display' Turning OFF.
[D][EHMTXv2:142]: display off
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400d37a4 PS : 0x00060c30 A0 : 0x800dba33 A1 : 0x3ffb2380
A2 : 0x00000000 A3 : 0x401ba5f8 A4 : 0x00000000 A5 : 0x00000000
A6 : 0x00000008 A7 : 0x00000000 A8 : 0x800d379c A9 : 0x3ffb2360
A10 : 0x00000000 A11 : 0x3ffb2388 A12 : 0x3ffb238c A13 : 0x00007ffe
A14 : 0x0000000b A15 : 0x00000010 SAR : 0x00000004 EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000000 LBEG : 0x4008b191 LEND : 0x4008b1a1 LCOUNT : 0xffffffff
Backtrace:0x400d37a1:0x3ffb23800x400dba30:0x3ffb23b0 0x401b8af9:0x3ffb23e0 0x400db6d9:0x3ffb2400 0x400db709:0x3ffb2420 0x400db6be:0x3ffb2440 0x400dec92:0x3ffb2460 0x400fb018:0x3ffb2480 0x400faed5:0x3ffb24a0 0x401ba4d7:0x3ffb24c0 0x401b9a79:0x3ffb24e0 0x400f10f9:0x3ffb2500 0x400f0a73:0x3ffb2520 0x400f1080:0x3ffb2540 0x400f108e:0x3ffb2570 0x401b9f55:0x3ffb2590 0x401b9ff1:0x3ffb25b0 0x400f91e1:0x3ffb25d0 0x400fef22:0x3ffb2600 0x4010d12a:0x3ffb2820
ELF file SHA256: 0000000000000000
Rebooting...
@lubeda @andrewjswan let's continue here.
The problem is clearly here:
EspHoMaTriXv2/components/ehmtxv2/EHMTX.cpp
Line 143 in 6a0818f
But I don’t know why it occurs, maybe we need to add an explicit instruction:
this->display->clear();Or
if (this->display != NULL)
{
this->display->clear();
}You are right it happens in clear() but a null check does'nt help.
Code tested:
void EHMTX::set_display_off()
{
this->show_display = false;
ESP_LOGD(TAG, "display off");
if (this->display != NULL)
{
ESP_LOGD(TAG, "display off 2");
this->display->clear();
}
ESP_LOGD(TAG, "display off 3");
for (auto *t : on_show_display_triggers_)
{
t->process(this->show_display);
}
}
[D][template.switch:046]: Restored state OFF
[D][switch:016]: 'Display' Turning OFF.
[D][EHMTXv2:142]: display off
[D][EHMTXv2:145]: display off 2
Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandl ed.
Core 1 register dump:
PC : 0x400d37a8 PS : 0x00060030 A0 : 0x800dba37 A1 : 0x3f fb2390
A2 : 0x00000000 A3 : 0x401ba8d0 A4 : 0x00000000 A5 : 0x00 000000
A6 : 0x00000001 A7 : 0x3ffb08c0 A8 : 0x800d37a0 A9 : 0x3f fb2370
A10 : 0x00000000 A11 : 0x3ffb2398 A12 : 0x3ffb239c A13 : 0x00 007ffe
A14 : 0x00000005 A15 : 0x00000001 SAR : 0x00000004 EXCCAUSE: 0x00 00001d
EXCVADDR: 0x00000000 LBEG : 0x4008b191 LEND : 0x4008b1a1 LCOUNT : 0xff ffffff
Backtrace:0x400d37a5:0x3ffb23900x400dba34:0x3ffb23c0 0x401b8dc9:0x3ffb23f0 0x400 db6dd:0x3ffb2410 0x400db70d:0x3ffb2430 0x400db6c2:0x3ffb2450 0x400ded14:0x3ffb24 70 0x400fb2ad:0x3ffb2490 0x400faf41:0x3ffb24b0 0x401ba7a7:0x3ffb24d0 0x401b9d49: 0x3ffb24f0 0x400f1181:0x3ffb2510 0x400f0afb:0x3ffb2530 0x400f1108:0x3ffb2550 0x4 00f1116:0x3ffb2580 0x401ba225:0x3ffb25a0 0x401ba2c1:0x3ffb25c0 0x400f9269:0x3ffb 25e0 0x400ff192:0x3ffb2610 0x4010d39a:0x3ffb2820
ELF file SHA256: 0000000000000000
Rebooting...
Because it reaches the "display off 2" log, it seems display is NOT NULL, hence executing clear().
Any ideas?
Because it reaches the "display off 2" log, it seems display is NOT NULL, hence executing clear().
That’s what I thought, the object was created, but it’s not completely initialized, it’s a fall inside the ESPHome.
Here you need to look for a problem in ESPHome, or change tactics.
I also thought something like this.
Not so deep in esphome, but maybe there is an flag in the display component, which get's set when completly initialized?
Already done a workaround with a "booted" variable, display switch restore_mode: ALWAYS_ON & the triggers on_started_running but i thought it would be good to report it here.
If another user is playing with the restiore_mode, they would also stumble on this issue.
Not so deep in esphome, but maybe there is an flag in the display component, which get's set when completly initialized?
I looked, there is a simple function call, and it should work for me.
https://github.com/esphome/esphome/blob/dc0a7b1e205f5fa4e25fd1cadd507c27173636e1/esphome/components/display/display.cpp#L16
@popy2k14 Try change to:
if if (this->is_running)
{
this->display->clear();
}I make PR ...