Watchdog got triggered

[ScApi]

Probably I'm doing something wrong but everything compiled ok, with Your config, hardware wise everything is probably also ok. After start almost instantly I'm getting this:

Connected to the MQTT server I (4905) uart: queue free spaces: 20 Serial1 OK I (4905) uart: queue free spaces: 20 Serial2 OK E (9895) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (9895) task_wdt: - IDLE (CPU 1) E (9895) task_wdt: Tasks currently running: E (9895) task_wdt: CPU 0: Modbus01RTU E (9895) task_wdt: CPU 1: MBsrv01RTU E (9895) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x400E8F37:0x3FFB0B900x40082C11:0x3FFB0BB0 0x40084DB9:0x3FFC8FE0 0x400DB84C:0x3FFC9000 0x400D9A87:0x3FFC9020 0x4008C45D:0x3FFC90B0

E (9895) task_wdt: Print CPU 1 backtrace

Backtrace:0x40084D59:0x3FFB11900x40082C11:0x3FFB11B0 0x4008B8AD:0x3FFCA560 0x400DB84C:0x3FFCA580 0x400DAE98:0x3FFCA5A0 0x400DA77C:0x3FFCA5F0 0x4008C45D:0x3FFCA6A0

Same on older Code:

E (25429) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (25429) task_wdt: - IDLE (CPU 1) E (25429) task_wdt: Tasks currently running: E (25429) task_wdt: CPU 0: Modbus01RTU E (25429) task_wdt: CPU 1: loopTask E (25429) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x400E1593:0x3FFB0B900x400828A1:0x3FFB0BB0 0x400D74CD:0x3FFBB000 0x400892B9:0x3FFBB090 0x400e1593: task_wdt_isr at C:/Espressif/frameworks/esp-idf-v4.4-2/components/esp_system/task_wdt.c:183 (discriminator 3)

0x400828a1: _xt_lowint1 at C:/Espressif/frameworks/esp-idf-v4.4-2/components/freertos/port/xtensa/xtensa_vectors.S:1111

0x400d74cd: bool std::operator==<ModbusClientRTU::RequestEntry, ModbusClientRTU::RequestEntry&, ModbusClientRTU::RequestEntry>(std::_Deque_iterator<ModbusClientRTU::RequestEntry, ModbusClientRTU::RequestEntry&, ModbusClientRTU::RequestEntry> const&, std::_Deque_iterator<ModbusClientRTU::RequestEntry, ModbusClientRTU::RequestEntry&, ModbusClientRTU::RequestEntry> const&) at c:\espressif\tools\xtensa-esp32-elf\esp-2021r2-patch2-8.4.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.4.0\bits/stl_deque.h:270 (inlined by) std::deque<ModbusClientRTU::RequestEntry, std::allocator >::empty() const at c:\espressif\tools\xtensa-esp32-elf\esp-2021r2-patch2-8.4.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.4.0\bits/stl_deque.h:1368 (inlined by) std::queue<ModbusClientRTU::RequestEntry, std::deque<ModbusClientRTU::RequestEntry, std::allocator > >::empty() const at c:\espressif\tools\xtensa-esp32-elf\esp-2021r2-patch2-8.4.0\xtensa-esp32-elf\xtensa-esp32-elf\include\c++\8.4.0\bits/stl_queue.h:190 (inlined by) ModbusClientRTU::handleConnection(ModbusClientRTU) at c:\espressif\project\dtsu666_2\build/../main/ModbusClientRTU.cpp:170

0x400892b9: vPortTaskWrapper at C:/Espressif/frameworks/esp-idf-v4.4-2/components/freertos/port/xtensa/port.c:131

E (25429) task_wdt: Print CPU 1 backtrace

[ScApi]

One more thing as I'm looking thru the code.

On both serial init You use SERIAL_8N2 but Huawei is 8N1, Chint can be configured to any option that's available but recommended 8N1. Is it on purpose like that ?

Tested on another board gives same error:

(0) cpu_start: App cpu up. I (248) cpu_start: Pro cpu start user code I (248) cpu_start: cpu freq: 160000000 I (248) cpu_start: Application information: I (252) cpu_start: Project name: DTSU666H_translator I (258) cpu_start: App version: 1 I (263) cpu_start: Compile time: Apr 9 2022 15:47:16 I (269) cpu_start: ELF file SHA256: 8480c26b2b8f95b5... I (275) cpu_start: ESP-IDF: -128-NOTFOUND I (281) heap_init: Initializing. RAM available for dynamic allocation: I (288) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (294) heap_init: At 3FFB3368 len 0002CC98 (179 KiB): DRAM I (300) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (306) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (313) heap_init: At 4008CB14 len 000134EC (77 KiB): IRAM I (320) spi_flash: detected chip: generic I (324) spi_flash: flash io: dio W (328) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header. I (342) gpio: GPIO[15]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 I (350) gpio: GPIO[23]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 I (360) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (1Serial0 OK I (20) uart: queue free spaces: 20 Serial1 OK I (20) uart: queue free spaces: 20 Serial2 OK __ E (10393) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (10393) task_wdt: - IDLE (CPU 1) E (10393) task_wdt: Tasks currently running: E (10393) task_wdt: CPU 0: Modbus01RTU E (10393) task_wdt: CPU 1: MBsrv01RTU E (10393) task_wdt: Print CPU 0 (current core) backtrace

Backtrace:0x400E14AB:0x3FFB0B900x40082901:0x3FFB0BB0 0x400849A3:0x3FFBA9B0 0x400849B1:0x3FFBA9D0 0x40088A3D:0x3FFBA9F0 0x400D8E4C:0x3FFBAA10 0x400D771F:0x3FFBAA30 0x400892D9:0x3FFBAAC0 0x400e14ab: task_wdt_isr at C:/Espressif/frameworks/esp-idf-v4.4-4/components/esp_system/task_wdt.c:183 (discriminator 3)

0x40082901: _xt_lowint1 at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/port/xtensa/xtensa_vectors.S:1111

0x400849a3: esp_crosscore_int_send at C:/Espressif/frameworks/esp-idf-v4.4-4/components/esp_system/crosscore_int.c:127

0x400849b1: esp_crosscore_int_send_yield at C:/Espressif/frameworks/esp-idf-v4.4-4/components/esp_system/crosscore_int.c:144

0x40088a3d: vTaskDelay at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/tasks.c:1595

0x400d8e4c: delay at c:\project\dtsu666_2\build/../components/arduino/cores/esp32/esp32-hal-misc.c:178

0x400d771f: ModbusClientRTU::handleConnection(ModbusClientRTU*) at c:\project\dtsu666_2\build/../main/ModbusClientRTU.cpp:254

0x400892d9: vPortTaskWrapper at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/port/xtensa/port.c:131

E (10393) task_wdt: Print CPU 1 backtrace

Backtrace:0x40084945:0x3FFB11900x40082901:0x3FFB11B0 0x4000BFF3:0x3FFBBE90 0x400888F9:0x3FFBBEA0 0x40087579:0x3FFBBEC0 0x400D9101:0x3FFBBF00 0x400D9825:0x3FFBBF30 0x400D8AFD:0x3FFBBF50 0x400D8414:0x3FFBBFA0 0x400892D9:0x3FFBC050 0x40084945: esp_crosscore_isr at C:/Espressif/frameworks/esp-idf-v4.4-4/components/esp_system/crosscore_int.c:92

0x40082901: _xt_lowint1 at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/port/xtensa/xtensa_vectors.S:1111

0x400888f9: vPortClearInterruptMaskFromISR at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/port/xtensa/include/freertos/portmacro.h:571 (inlined by) xTaskGetSchedulerState at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/tasks.c:4685

0x40087579: xQueueSemaphoreTake at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/queue.c:1554

0x400d9101: uartAvailable at c:\project\dtsu666_2\build/../components/arduino/cores/esp32/esp32-hal-uart.c:225 (discriminator 1)

0x400d9825: HardwareSerial::available() at c:\project\dtsu666_2\build/../components/arduino/cores/esp32/HardwareSerial.cpp:402

0x400d8afd: RTUutils::receive(HardwareSerial&, unsigned int, unsigned int&, unsigned int) at c:\project\dtsu666_2\build/../main/RTUutils.cpp:220

0x400d8414: ModbusServerRTU::serve(ModbusServerRTU*) at c:\project\dtsu666_2\build/../main/ModbusServerRTU.cpp:118

0x400892d9: vPortTaskWrapper at C:/Espressif/frameworks/esp-idf-v4.4-4/components/freertos/port/xtensa/port.c:131

[ScApi]

Weird things are going on, moved everything to Arduino, changed couple of things and it all works, I really don't know why it isn't working on ESP compiler

[s-marian]

I managed to get it to work using ESP-IDF + Arduino core. I also fixed compatibility issues, I am not entirely sure how it worked, maybe the author ran it on an old SUN2000 inverter. See my fork.

[xyphro]

Question guys: Does it still work for you with latest sun2000 firmware? See my issue: https://github.com/salakrzy/DTSU666_CHINT_to_HUAWEI_translator/issues/5

[salakrzy]

After splitting the query to Chint into several smaller issues, the problem should no longer occur. The problem has been fixed in the new version.