Periodic start of always receiving MB_MRE_EXE_FUN in response to read request that had been previously valid (IDFGH-10891)

[dwarnow-xylem]

I am having an issue where the eMBMasterWaitRequestFinish() function in portevent_m.c will start returning a MB_MRE_EXE_FUN on every response to a read request to a Modbus slave. The response the slave device is sending is not appreciably different between functioning properly and returning that error. In absence of solutions, I would at least like clarity as to what that error actually signifies so that I may continue debugging myself.

Included below is a small bit of logging output.

Thank you.

E (518560316) MASTER_TEST: === Read active value failure 2 ===
E (518560346) portevent_m.c: Execute function error
E (518560346) MB_CONTROLLER_MASTER: mbc_master_send_request(93): Master send request failure error=(0x108) (ESP_ERR_INVALID_RESPONSE).
E (518560346) MASTER_TEST: === Read active value failure 3 ===
W (518560356) MASTER_TEST:  State change failed , flag :1 MBReg : 21845.
E (518560426) portevent_m.c: Execute function error
E (518560426) MB_CONTROLLER_MASTER: mbc_master_send_request(93): Master send request failure error=(0x108) (ESP_ERR_INVALID_RESPONSE).

[alisitsyn]

Hi @dwarnow-xylem,

The MB_MRE_EXE_FUN error is usually returned if master received unsupported response from slave or frame check failure is observed. Master can not execute command handler because the command is either not supported or is incorrect or the slave returns an exception in the response to master's request. It can be happened if your slave mapping is not configured correctly as well. See the slave mapping configuration in the manual. Please enable the debug verbosity in the kconfig menu or store the communication log between master and slave. This will allow to see the debug messages from stack to find the reason for this error.

The error MB_MRE_EXE_FUN corresponds to ESP_ERR_INVALID_RESPONSE returned from public API. See the troubleshooting table

[dwarnow-xylem]

Hi @alisitsyn ,

I unfortunately could not get the error to trigger with full verbose or even debug output, as that significantly slows down execution of our code. But I found the place in mb_m.c where the receive buffer prints when in debug logging and changed that to an info level output.

The below shows that the packets received are identical before and after the fault. The Modbus data is still being received correctly, and it is a response that had previously been accepted.

Let me know what you think of this, and if you know of any other logging I can manually move to a lower debug level so I can still cause the fault to occur, please let me know.

Thank you.

truncated log with rx buffer transition to error.txt

[alisitsyn]

Hi @dwarnow-xylem ,

First of all please send me the version of esp-modbus component you are using. Also, please send your sdkconfig file, then check the option CONFIG_FMB_TIMER_PORT_ENABLED(=n) which should be disabled in kconfig for your sw environment. Once disabled please clean your build and then rebuild the application.

We can go further then.

Thank you.

[dwarnow-xylem]

@alisitsyn

Attached is my sdkconfig file. The option you specify is not set. If I set it to "n" the IDE I'm using (Visual GDB) puts it back to being commented out when it does its configuration. Hopefully that is the same as setting it to no.

As for the version, based on the idf_component.yml file, I am on version 1.0.7 of the ESP-Modbus.

Thank you.

sdkconfig.txt

[alisitsyn]

@dwarnow-xylem,

puts it back to being commented out when it does its configuration.

Yes, it is the same as set it to n means disabled.

I am on version 1.0.7 of the ESP-Modbus.

Could you please migrate to the new esp-modbus component with your Visual GDB? In your project_folder/managed_components/espressif__esp-modbus is the esp-modbus component which is updated from component manager registry if CMakeLists.txt of the project root contains the line: set(ENV{IDF_COMPONENT_MANAGER} “1”). Please remove this folder and place the extracted latest esp-modbus component to the folder project_folder/components/espressif__esp-modbus then remove the project_folder/dependencies.lock file. Please also fix the component version in main folder manifest file to latest like project_folder/main//idf_component.yml.

Also, if you use the old version of VisualGdb it is required to add the line set(EXCLUDE_COMPONENTS freemodbus) to your project_folder/CMakeLists.txt file.

Let me know if you need more information.

Thank you.

[alisitsyn]

Hi @dwarnow-xylem,

Could you share some update for this issue?

[dwarnow-xylem]

Hi @alisitsyn,

Our team implemented the patch linked below to solve a different issue and it seems like it may have fixed this one as well. Since this is a periodic failure that is hard to trigger intentionally, it is difficult to say for sure, but in early testing, it seems to have helped.

https://github.com/alisitsyn/modbus_support/tree/modbus_support/fix_glitches_esp_modbus_master_rtu_ascii/modbus_master_rtu

[alisitsyn]

Hi @dwarnow-xylem ,

Thank you for update. Could you also try the latest esp-modbus version as well? The later versions of esp-modbus fix the issues you showed above.

[dwarnow-xylem]

Hi @alisitsyn, As this is a periodic failure that takes a lot of testing to try to prove out, I do not want to go chasing things while in the middle of trying to prove out a different solution.

Does the newest version of the Modbus library include the fix that I linked in my previous comment?

Thanks.

[alisitsyn]

Hi @dwarnow-xylem,

Does the newest version of the Modbus library include the fix that I linked in my previous comment?

The latest library does not have exactly the same commits as in previous link but fixes the issue you stated above.

Your issue is related to esp-modbus v1.0.7. The issue was fixed from v.1.0.9. It is up to you and your team what version of the library to use in your project. Unfortunately, in this case I can not reproduce the issue as well as confirm it and propose you to close the issue for now. Feel free to reopen it again once you have other results against the latest version of esp-modbus.

Thanks.