Closed fink-at-trmc-dk closed 1 year ago
Hi @fink-at-trmc-dk ,
Thank you for the report. The formal process is started for the issue. I will let you know the result as soon as possible. Your sdkconfig, map, elf, bin, srcs (if possible)
files can be useful. Thanks.
Hi again and thanks for the fast response. I have attached a zip with the project which is a WIP, but the failure remains.
I have a diagslave.exe running as diagslave.exe -c 100 -a71 -o1 -p1502
which means that I have modified xMBMasterTCPPortSendResponse line 990
by adding pucMBTCPFrame[MB_TCP_UID] = (UCHAR)(pxInfo->ucSlaveAddr);
to have the slave ID correctly set.
As seen in the log it may take some time to crash. Last log entry on my machine was nearly 900 seconds.
Please let me know if you need more from me :-)
Latest log added:
I (840097) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840107) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840107) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840107) ModbusTCP: CID_SET_CHARGE (-5.000000) read successful.
I (840107) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840127) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840127) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840137) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840137) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840147) ModbusTCP: CID_ACT_SOC (0) read successful.
I (840147) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (840157) ModbusTCP: state_t::RELEASE:
I (840157) ModbusTCP: ModbusTCP 5972
I (850167) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850167) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850197) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850197) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850197) ModbusTCP: CID_SET_CHARGE (-5.000000) read successful.
I (850197) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850217) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850217) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850227) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850227) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850237) ModbusTCP: CID_ACT_SOC (0) read successful.
I (850237) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (850247) ModbusTCP: state_t::RELEASE:
I (850247) ModbusTCP: ModbusTCP 5972
I (860257) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (860257) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (860647) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (860647) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (860647) ModbusTCP: CID_SET_CHARGE (-5.000000) read successful.
I (860647) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (860667) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (860667) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
E (861667) MB_CONTROLLER_MASTER: mbc_master_get_parameter(73): Master get parameter failure, error=(0x108) (ESP_ERR_INVALID_RESPONSE).
I (861667) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (861677) ModbusTCP: state_t::RELEASE:
I (861677) ModbusTCP: ModbusTCP 5972
I (867677) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
E (871677) MB_CONTROLLER_MASTER: mbc_master_get_parameter(73): Master get parameter failure, error=(0x108) (ESP_ERR_INVALID_RESPONSE).
I (871677) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (871677) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
E (872677) MB_PORT_COMMON: xMBMasterRunResTake(183): Take resource failure.
I (872677) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
E (872677) MB_CONTROLLER_MASTER: mbc_master_get_parameter(73): Master get parameter failure, error=(0x108) (ESP_ERR_INVALID_RESPONSE).
I (872687) ModbusTCP: state_t::RELEASE:
I (872697) ModbusTCP: ModbusTCP 5972
E (882697) MB_CONTROLLER_MASTER: mbc_master_get_parameter(73): Master get parameter failure, error=(0x108) (ESP_ERR_INVALID_RESPONSE).
I (882697) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882697) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882707) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882707) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882717) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882727) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
E (882717) MB_CONTROLLER_MASTER: mbc_master_get_parameter(73): Master get parameter failure, error=(0x108) (ESP_ERR_INVALID_RESPONSE).
I (882727) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882747) ModbusTCP: state_t::RELEASE:
I (882747) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882757) ModbusTCP: ModbusTCP 5972
I (882757) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
I (882767) MB_CONTROLLER_MASTER: modbus_tcp_mast 2112
assert failed: remove_free_block tlsf.c:331 (next && "next_free field can not be null")
Backtrace: 0x400818a6:0x3ffc2130 0x40088edd:0x3ffc2150 0x4008ff66:0x3ffc2170 0x4008e0df:0x3ffc2290 0x4008daa2:0x3ffc22b0 0x40082091:0x3ffc22d0 0x400820f1:0x3ffc22f0 0x40082126:0x3ffc2310 0x4008ff79:0x3ffc2330 0x400eac19:0x3ffc2350 0x400eaca3:0x3ffc2370 0x400ead06:0x3ffc2390 0x400e9213:0x3ffc23b0 0x400e925d:0x3ffc23d0 0x40144bca:0x3ffc23f0 0x401931fd:0x3ffc2410 0x40100729:0x3ffc2430 0x4008fb7e:0x3ffc2450 0x4008fc39:0x3ffc24a0 0x4009397d:0x3ffc24c0 0x40091824:0x3ffc24e0 0x4008b9c9:0x3ffc2510
0x400818a6: panic_abort at C:/espressif/esp-idf/components/esp_system/panic.c:427
0x40088edd: esp_system_abort at C:/espressif/esp-idf/components/esp_system/port/esp_system_chip.c:68
0x4008ff66: __assert_func at C:/espressif/esp-idf/components/newlib/assert.c:78
0x4008e0df: remove_free_block at C:/espressif/esp-idf/components/heap/tlsf/tlsf.c:331
(inlined by) block_locate_free at C:/espressif/esp-idf/components/heap/tlsf/tlsf.c:567
(inlined by) tlsf_malloc at C:/espressif/esp-idf/components/heap/tlsf/tlsf.c:1004
0x4008daa2: multi_heap_malloc_impl at C:/espressif/esp-idf/components/heap/multi_heap.c:207
0x40082091: heap_caps_malloc_base at C:/espressif/esp-idf/components/heap/heap_caps.c:145
0x400820f1: heap_caps_malloc at C:/espressif/esp-idf/components/heap/heap_caps.c:165
0x40082126: heap_caps_malloc_default at C:/espressif/esp-idf/components/heap/heap_caps.c:190
0x4008ff79: malloc at C:/espressif/esp-idf/components/newlib/heap.c:24
0x400eac19: mem_malloc at C:/espressif/esp-idf/components/lwip/lwip/src/core/mem.c:209
0x400eaca3: do_memp_malloc_pool at C:/espressif/esp-idf/components/lwip/lwip/src/core/memp.c:254
0x400ead06: memp_malloc at C:/espressif/esp-idf/components/lwip/lwip/src/core/memp.c:350 (discriminator 2)
0x400e9213: tcpip_inpkt at C:/espressif/esp-idf/components/lwip/lwip/src/api/tcpip.c:254 (discriminator 2)
0x400e925d: tcpip_input at C:/espressif/esp-idf/components/lwip/lwip/src/api/tcpip.c:287
0x40144bca: wlanif_input at C:/espressif/esp-idf/components/esp_netif/lwip/netif/wlanif.c:160
0x401931fd: esp_netif_receive at C:/espressif/esp-idf/components/esp_netif/lwip/esp_netif_lwip.c:1085
0x40100729: wifi_sta_receive at C:/espressif/esp-idf/components/esp_wifi/src/wifi_netif.c:39
0x4008fb7e: sta_input at ??:?
0x4008fc39: sta_rx_cb at ??:?
0x4009397d: ppRxPkt at ??:?
0x40091824: ppTask at ??:?
0x4008b9c9: vPortTaskWrapper at C:/espressif/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:150
ELF file SHA256: 267a8393e0598a65
CPU halted.
To exit from IDF monitor please use "Ctrl+]". Alternatively, you can use Ctrl-T Ctrl-X to exit.
//Fink sntp.zip
I tried to reproduce the issue using your whole project. My modifications are:
xMBMasterTCPPortSendResponse line 990
that are required for diagslave.The project has been checked with the modbus component from your components folder then with esp-modbus v1.0.7, then with v1.0.8. The modbus slave: /home/esp-man/diagslave/x86_64-linux-gnu/diagslave -c 100 -a71 -o2 -p1502
The extended logs are attached:
sntp.log log_diagslave.txt sntp1.log
The testing was performed for couple of hours without any crash. Please let me know which version of esp-idf you are using and try the same with master of esp-idf.
Thanks.
Hi again,
Thanks for taking your time on this issue.
I updated ESP-IDF to lates version from Main instead of V5.0. Regarding
Modbus I could not find a tag v1.0.8 and do not know what commit is the
best v1.0.8, so I also took the latest from master here and added changes
in xMBMasterTCPPortSendResponse
to enable specific slave ID.
It has been running for several hours (> 10) without any hickups so the
problem seems to have solved itself with the bleeding edge of both IDF and
Modbus.
Is it possible for you in the future to use the tags so it is easy to checkout and use a specific version like in the rest of the ESP-IDF environment?
In any case: Thanks for the help :-) Case can be closed from my perspective. //Fink
On Tue, Jan 17, 2023 at 2:55 PM Alex Lisitsyn @.***> wrote:
I tried to reproduce the issue using your whole project. My modifications are:
- SSID, Password of wifi
- IP Address of the Modbus master slave.
- changes in xMBMasterTCPPortSendResponse line 990 that are required for diagslave.
- compile project on linux machine and use diagslave on linux.
The project has been checked with the modbus component from your components folder then with esp-modbus v1.0.7, then with v1.0.8. The modbus slave: /home/esp-man/diagslave/x86_64-linux-gnu/diagslave -c 100 -a71 -o2 -p1502
The extended logs are attached:
sntp.log https://github.com/espressif/esp-modbus/files/10435642/sntp.log log_diagslave.txt https://github.com/espressif/esp-modbus/files/10435643/log_diagslave.txt
The testing was performed for couple of hours without any crash. Please let me know which version of esp-idf you are using and try the same with master of esp-idf.
Thanks.
— Reply to this email directly, view it on GitHub https://github.com/espressif/esp-modbus/issues/17#issuecomment-1385460505, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQ6NZQHRJXV4S7YZ5JLTAMTWS2QE5ANCNFSM6AAAAAAT3EE3PY . You are receiving this because you were mentioned.Message ID: @.***>
Hi,
Thank you for the update. It is always good when solution is found. The latest version of esp-modbus is v1.0.8 and there are no any changes that fixes any issue related to what you described. You can select this version in your manifest file or just download the archive, extract it to the components folder and try to test. The changes related to UID will be merged with some other pending MRs. I will try to do this as soon as possible.
Is it possible for you in the future to use the tags so it is easy to checkout and use a specific version like in the rest of the ESP-IDF environment?
In the internal system the version tag is applied before each merge. Once the version is merged the version is being synchronized with the giithub repo and uploaded to component manager. I will check the project rules to apply the version tag on the github project accordingly.
https://github.com/espressif/esp-modbus/releases/tags
I agree the issue can be closed then. Feel free to reopen the issue if you have some additional results. Thanks.
Hi again,
I get the following in the terminal after running the below code for som time. I poll a slave with UID 71 (Kostal Inverter) periodically every 10 seconds.
The code used is here:
Does anyone have an idea as to how to fix it or go about debugging it? I'm unsure as to where to start...
Please net me know if more information is needed :-)
BR Fink