Skip to content

Conversation

@legoabram
Copy link
Contributor

@legoabram legoabram commented Oct 2, 2024

A response returned after a request times out would increment the semaphore and stay until the next request is made which will immediately return when k_sem_take is called even before a response is returned. This will once again have the same problem when the actual response arrives. So the wait semaphore just needs to be reset before transmitting.

Ideally, I'd like to have the modbus test check for this edge case, but I don't have an frdm-k64f board, or the time to figure out how to configure a new board for the test to develop one. That said, I'm hoping this is simple and straightforward enough to get the point across. I've been running this modification on our boards for several days now and it's only improved behavior. But anecdotes only go so far.

Fixes #79518

A response returned after a request times out would increment the
semaphore and stay until the next request is made which will immediately
return when k_sem_take is called even before a response is returned. This
will once again have the same problem when the actual response arrives.
So the wait semaphore just needs to be reset before transmitting.

Signed-off-by: Abram Early <abram.early@gmail.com>
@legoabram legoabram force-pushed the abram/modbus-reset-sem branch from 1b2060a to add7c4c Compare October 2, 2024 22:03
Copy link
Contributor

@jfischer-no jfischer-no left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks


int modbus_tx_wait_rx_adu(struct modbus_context *ctx)
{
k_sem_reset(&ctx->client_wait_sem);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you like to add a test case to catch this in the tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I get some leeway at work, I'll get an nucleo board working and submit a test case. I think the easiest way to do it would be to artificially delay the server response past the timeout. But I'm not sure when I'll get to it.

@legoabram
Copy link
Contributor Author

Tagged this merge with a bug report for tracking purposes, and the backports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: modbus backport v3.7-branch Request backport to the v3.7-branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Temporary Modbus Client "Soft Lock"

4 participants