Tasmota32 9.1 on ESP32 DevKit v1 with Zigbee coord. CC2530/CC2591 goes into infinite boot loop (CORRUPT HEAP) after pairing first Zigbee end device #10121
Comments
|
My first impression the bug is in Arduino core |
ascillato2
added
awaiting feedback
|
Thanks for the tips. As before, everything goes well until I reboot the ESP32:
After the final reboot I get exactly the same behavior:
Here is the serial output: Should I change the GPIO pins? I tested so far with 16, 17 (RX2, TX2) and 18, 19. Thanks for looking into this - let me know if more details are needed. Cheers |
|
Zigbee has not really been tested with ESP32. It looks like the code to retrieve Flash. @arendst the current code is: Shouldn't it be: I have the impression it is overwriting the stack. |
|
@tlc76 Always use Tasmota(32) as base for customized builds. |
Fix ESP32 CC2530 heap corruption (#10121)
|
Give the fix a try and report back if it solved your issue. I cannot test as my CC2530 is in production on a ESP8266. |
|
Thanks a lot @arendst, this works perfectly! Reboot loop --> fixed
However the Tasmota settings remain read-only after I enable the serial GPIOs linking the ESP32 board to the CC2530/2591 Zigbee coordinator. Any change that I make in the Tasmota configuration gets reverted after a reboot.
@Jason2866 : thanks for the tip, I will keep that in mind. |
That could be a major issue. The zigbee devices are stored on (small)NVS as are the settings. They both need 4k contiguous space but I suspect once your first zigbee device is stored the area becomes fragmented and the 4k Tasmota settings cannot longer be saved. I have to rethink ESP32 zigbee device storage and move it to SPIFFS/TINYFS or what ever. This will take some time so for now treat this feature as "experimental" |
arendst
added
Requires more research (devs)
|
@arendst that's very clear, thanks. |
- Add ESP32 support for Tasmota FileSystem - Move ESP32 Zigbee persistence from NVS to SPIFFS (#10121)
arendst
added
awaiting feedback
|
Pls try the latest dev. It moved the zigbee persistence from NVS to SPIFFS. |
ascillato2
added
bug
|
Thanks a lot for fixing this issue! One small concern (I'm not sure it's an issue).
After the 2nd reboot, as soon as the first messages are sent out by the child devices to the coordinator (as they are already paired), the zigbee devices data are stored in the memory (see below lines in bold):
Is this behavior normal? Thank you once again! |
|
Saving zigbee device data was only implemented for Zbbridge eeprom. It should not even try to save it, until I adapt the code for esp32. Consider this feature as not implemented on esp32, yet. |
|
Ah I think I still have an issue. Did you ever see messages like: I'll do some more tests. |
Fix enabling SPIFFS filesystem (#10121)
|
Pls try latest dev. |
I didn't notice such messages in the serial logs. I will test the new sources right away - be right back with the results. |
|
Test scenario:
Here is a serial log extract (after last reboot):
And the full log (with all operations after the reflash step):
|
|
OK. That looks better. What happens after another reboot. You should not see the TFS: Formatting message anymore. |
|
Here is the log after another reboot (you are right, no more "formatting" message, it directly mounts the FS):
And after another reboot (after the 2 sensors had sent some zigbee messages to the coord.):
Could it be that the issue mentioned by @s-hadinger is gone and the zigbee device information is now persistent across reboots? That would be great :)
thanks! |
|
I think he was a bit confused about this as this was already present before his recent additions. Your latest response just confirms my expectation so I think we are done here. Thx for your cooperation. Pls close this issue. |
ascillato2
removed
the
awaiting feedback
First of all, I apologize for the very long post. I tried to give as many details as possible.
Practically I am unable to use the ESP32 with attached CC2530/CC2591 zigbee coordinatoor.
Just as an FYI, a similar behavior appears also in a EspEasy setup (infinite loop after I enable the Serial Server).
I tried with multiple ESP32 boards of the same model (see below) --> same problem.
PROBLEM DESCRIPTION
HW configuration:
ESP32 (DevKit v1 30 pins) with Tasmota 9.1.0 (recompiled w/ zigbee support enabled)
Zigbee CC2530/CC2591 flashed as coordinator and wired to the ESP32 (first attempt using standard UART2 ports GPIO16 + GPIO17 and also with GPIO18 + GPIO19)
Test end device: xiaomi aqara vibration sensor
Steps performed:
here is the serial log so far:
Right after this last reboot, the ESP32 goes into an infinite loop (this is the immediate continuation of the serial log from above):
and again:
If I unplug the ESP32 the boot loop stops, I can access the Tasmota web UI but somehow the chips goes read/only: the Pinout configuration in the Module configuration menu is reset (all pins set to None) and can no longer be changed:
If I attempt to change the setting to match the wiring of the 2 boards (GPIO18 --> Zigbee RX and GPIO19 --> Zigbee TX) and Save configuration, the setting is lost after the reboot and again all pins are set to None:
before Save configuration:
after Save config. and reboot:
The only way to get back access to the Zigbee coordinator is to reflash the firmware.
Then I run into the same problem after I pair the first end device.
REQUESTED INFORMATION
Backlog Template; Module; GPIO 255:..... before pairing the end device:
..... after the device gets into read/only mode;
Configuration output here:
Rules output here:
13:22:04 CMD: status0
13:22:04 MQT: tasmota/tasmota_851934/stat/STATUS = {"Status":{"Module":1,"DeviceName":"Tasmota","FriendlyName":["Tasmota"],"Topic":"tasmota_851934","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}
TO REPRODUCE
EXPECTED BEHAVIOUR
Practically I am unable to get the ESP32 board to work with the Zigbee coordinator.
I have a similar setup with ESP8266 (and EspEasy + Zigbee2mqtt) and it works perfectly!
Has anyone managed to make it working with ESP32 boards?
If yes, can you please provide more details about the "how"?
Thanks a lot,
Cristian
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
ADDITIONAL CONTEXT
Add any other context about the problem here.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: