新版本2.0.0-beta.1测出2个的问题 (IDFGH-13697)

[guo652917087]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

1、modbus tcp slave的问题。使用modbus poll工具，只要连接到4-5个，就出现连接好几种致命问题，包括socket导致tcp task卡死，系统看门狗报错没及时喂狗，换到旧版本就正常。
2.使用2个modbus rtu master，esp32s3模块，使用UART1和UART2，两个串口同时工作时，不能收到RS485的数据。

调试发现：在port_serial.c文件，153行，修改
LOG为INFO，ESP_LOGI(TAG, "%s, data event, len: %d.", port_obj->base.descr.parent_name, (int)event.size);
直接用模块，串口线接到RX、TX，往esp32s3模块发串口数据，经常不能触发收到消息的这段代码打印（偶尔反复重启后有打印）。但是如果主动调用uart_read_bytes去读取串口收取数据，一直能收到。
从这里判断在port_serial.c文件，240行:
err = uart_driver_install(pserial->ser_opts.port, MB_BUFFER_SIZE, MB_BUFFER_SIZE,
MB_QUEUE_LENGTH, &pserial->uart_queue, MB_PORT_SERIAL_ISR_FLAG);

这里注册使用串口中断收取数据，不能正确触发，也就是不能收到数据。
回到RS485板子上，在调用mbc_master_send_request后，一直超时。但是主动uart_read_bytes去读取数据解码，数据返回是正确的。

已经试过 CONFIG_FMB_TIMER_USE_ISR_DISPATCH_METHOD=y 打开或者关闭，依旧没有用，就是uart收取中断失效了。

总结，2.0新版本modbus RTU，串口收取中断无效！！！！我看旧版本队列使用全局变量 static QueueHandle_t xMbUartQueue;，新版本动态分配内存，这样spiram的内存，会不会中断失效呢？

[alisitsyn]

@guo652917087,

Thank you for your valuable report.

1、modbus tcp slave的问题。使用modbus poll工具，只要连接到4-5个，就出现连接好几种致命问题，包括socket导致tcp task卡死，系统看门狗报错没及时喂狗，换到旧版本就正常。

The Modbus TCP Master sends a lot of debug messages. The number of messages multiplied by number of instances created in your application. The issue with watchdog triggering happens because due to this logging functionality the IDLE task is not activated on time. Notes and solutions: Do not use the debug verbosity for normal communication or add the vTaskDelay(NN) somewhere into your communication tasks.

包括socket导致tcp task卡死，系统看门狗报错没及时喂狗，换到旧版本就正常。

Could you provide more information about this? Please provide the logs that confirm this. This may happen due to event queues overflow, this can be configured using Kconfig values. During the testing with correct configuration the issues are not observed.
Note: please be aware that handling of several Modbus objects takes resources and may apply to overall response time and increase number of events in the queues. I will check this issue when possible.

2.使用2个modbus rtu master，esp32s3模块，使用UART1和UART2，两个串口同时工作时，不能收到RS485的数据

This case was tested and worked fine. Please provide more information for your setup (task priorities, code, logs and etc).
Could be related to below issue.

调试发现：在port_serial.c文件，153行，修改
LOG为INFO，ESP_LOGI(TAG, "%s, data event, len: %d.", port_obj->base.descr.parent_name, (int)event.size);

This line is logged with debug verbosity as it should be. This information is related to internal Modbus processing and should not clutter the log. You can simply override this line verbosity in your project as needed.

直接用模块，串口线接到RX、TX，往esp32s3模块发串口数据，经常不能触发收到消息的这段代码打印（偶尔反复重启后有打印）。但是如果主动调用uart_read_bytes去读取串口收取数据，一直能收到。
从这里判断在port_serial.c文件，240行:
err = uart_driver_install(pserial->ser_opts.port, MB_BUFFER_SIZE, MB_BUFFER_SIZE,
MB_QUEUE_LENGTH, &pserial->uart_queue, MB_PORT_SERIAL_ISR_FLAG);

Yes, it looks like the v2.0.0 missed one backport MR from esp-modbus v1. The interrupt code is always placed into flash. This causes the deferred interrupt triggering in spite of CONFIG_FMB_TIMER_USE_ISR_DISPATCH_METHOD=y. I will update it as soon as possible.

回到RS485板子上，在调用mbc_master_send_request后，一直超时。但是主动uart_read_bytes去读取数据解码，数据返回是正确的。

Please configure the CONFIG_FMB_MASTER_TIMEOUT_MS_RESPOND properly to be bigger than your slaves maximum response time. I expect you configured it incorrectly and slave response come later when the transaction is completed with the timeout. It is obvious that the data of the slave is in the UART buffer after transaction and you can read it. However, it is expired and will be cleared after start of next transaction.

已经试过 CONFIG_FMB_TIMER_USE_ISR_DISPATCH_METHOD=y 打开或者关闭，依旧没有用，就是uart收取中断失效了。

总结，2.0新版本modbus RTU，串口收取中断无效！！！！

It seems you are right here. The interrupt placed into flash and can be triggered with the delay when the CPU cache is cleared. The CONFIG_FMB_TIMER_USE_ISR_DISPATCH_METHOD does not help to initialize it correctly.

This will be fixed as soon as possible. I can also provide the fix to check this. I will try to merge this and some other back port MRs for v2 that are pending.