After switching to ESP-IDF 5.1: The mbc_master_destroy() function no longer works (IDFGH-10779)

[ThomasDQS]

Goal:

The ESP32 is working as a master device. I want to open a TCP/IP socket to a slave device, read some registers and stop the modbus communication stack, destroy the interface & free all used objects by using the “mbc_master_destroy()” function.

This flow is perfectly working with the ESP-IDF v5.0.1 on a ESP32-C3-DevKitM-1.

Problem: I want to get the same code flow working on a ESP32-C6-DevKitC-1, which required an upgrade of the ESP-IDF to v5.1. Opening the connection to the slave and reading the desired registers is working perfectly, only the “mbc_master_destroy()” function is not working; some unexpected events got triggered resulting in running an endless loop until the IDLE task wachtdog got triggered.

Logs:

..[0;32mI (7893) MB_TCP_MASTER_PORT: Socket (#54)(192.168.2.242) created..[0m
.[0;32mI (7893) MB_TCP_MASTER_PORT: Connected 1 slaves, start polling....[0m
.[0;32mI (7943) MODBUS: temperature: 20.000000.[0m
.[0;32mI (7943) MODBUS: active MAX current: 0.000000.[0m
.[0;33mW (10943) MB_TCP_MASTER_PORT: Modbus port task couldn't exit gracefully within timeout -> abruptly deleting the task..[0m
.[0;31mE (10943) MB_PORT_COMMON: xMBMasterPortEventGet: Incorrect event triggered = 0..[0m
.[0;31mE (10943) MB_PORT_COMMON: eMBMasterPoll: Unexpected event triggered 0x00..[0m
.[0;31mE (15933) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:.[0m
.[0;31mE (15933) task_wdt:  - IDLE (CPU 0).[0m
.[0;31mE (15933) task_wdt: Tasks currently running:.[0m
.[0;31mE (15933) task_wdt: CPU 0: modbus_tcp_mast.[0m
.[0;31mE (15933) task_wdt: Print CPU 0 (current core) registers.[0m
Core  0 register dump:
MEPC    : 0x4080a8c0  RA      : 0x4080a8b6  SP      : 0x4082a270  GP      : 0x408129b0  
TP      : 0x40804af4  T0      : 0x40028192  T1      : 0x10000000  T2      : 0xffffffff  
S0/FP   : 0x00000080  S1      : 0x00000080  A0      : 0x00000080  A1      : 0x00000080  
A2      : 0x00000000  A3      : 0x00000004  A4      : 0x4081b000  A5      : 0x00000001  
A6      : 0x00000001  A7      : 0x0000000a  S2      : 0xffffffff  S3      : 0x40828f40  
S4      : 0x00000000  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x00000000  
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000  
T3      : 0x00000000  T4      : 0x00000000  T5      : 0x00000000  T6      : 0x00000000  
MSTATUS : 0x00000000  MTVEC   : 0x00000000  MCAUSE  : 0x00000000  MTVAL   : 0x00000000  
MHARTID : 0x00000000  

Any help on this would be great, thanks!

[alisitsyn]

Hello @ThomasDQS,

Thank you for this issue. Could you additionally set the log verbosity to DEBUG in kconfig, restart your project and attach log here? Please also attach your sdkconfig and map file in the build folder or your whole project. This will allow to find the exact reason for this issue and fix the destroy sequence for v5.1.

Thank you.

[ThomasDQS]

Hello @alisitsyn

Hereby the debug_log, the sdkconfig file & the map file.

Thank you. debug_log.txt sdkconfig.txt modbus_tcp_master_map.txt

[alisitsyn]

@ThomasDQS ,

Thank you for update. The destroy sequence of master should be revised. I will update it and test as soon as possible.

Update: In your case when the modbus_tcp_master_task waits for poll events the destroy sequence is started, and event handler is deleted that causes to send zero value (unexpected event) to unblock task waiting for the event. Unfortunately in my ESP32-C6 DevKit v1.1 environment with your sdkconfig I could not reproduce the issue.

Before go further could you please move the managed_components folder to your_project\components then make the modification of the component as below then check if it fixes the issue?

mbc_tcp_master.c

static esp_err_t mbc_tcp_master_destroy(void)
{
    MB_MASTER_ASSERT(mbm_interface_ptr != NULL);
    mb_master_options_t* mbm_opts = &mbm_interface_ptr->opts;
    MB_MASTER_CHECK((mbm_opts != NULL), ESP_ERR_INVALID_ARG, "mb incorrect options pointer.");
    eMBErrorCode mb_error = MB_ENOERR;

    // Stop polling by clearing correspondent bit in the event group
    xEventGroupClearBits(mbm_opts->mbm_event_group,
                         (EventBits_t)MB_EVENT_STACK_STARTED);

    // Disable and then destroy the Modbus port
    mb_error = eMBMasterDisable();
    MB_MASTER_CHECK((mb_error == MB_ENOERR), ESP_ERR_INVALID_STATE, "mb stack disable failure.");

    (void)vTaskDelete(mbm_opts->mbm_task_handle);
    mbm_opts->mbm_task_handle = NULL; 

    mb_error = eMBMasterClose();
    MB_MASTER_CHECK((mb_error == MB_ENOERR), ESP_ERR_INVALID_STATE,
                        "mb stack close failure returned (0x%x).", (int)mb_error);

    (void)vEventGroupDelete(mbm_opts->mbm_event_group);
    mbm_opts->mbm_event_group = NULL;
    mbc_tcp_master_free_slave_list();
    free(mbm_interface_ptr); // free the memory allocated for options
    vMBPortSetMode((UCHAR)MB_PORT_INACTIVE);
    mbm_interface_ptr = NULL;
    return ESP_OK;
}

Could you give me an example code of your initialization - read/write - destroy sequence? Do you read the parameters in one task and destroy it from other tasks?

Thank you.

[ThomasDQS]

@alisitsyn

I moved the managed_components folder and made the changes in the mbc_tcp_master.c file as you indicated. These changes have solved the problem! Thank you for the assistance!

[alisitsyn]

@ThomasDQS ,

Thank you for your issue and the feedback. The fix will go through the formal process and will be fixed ASAP. Feel free to reopen the issue if you observe something later.

[alisitsyn]

Hi @ThomasDQS ,

The fix has been merged and released in component version v1.0.12. The issue is closed. Please check the update and feel free to reopen the issue if you still have similar issue.