Function "tx_event_flags_get" does not react if it waits too long

[momi117]

Hello everyone,

on my evaluation board (STM32H750B-DK) I use Azure RTOS (Version 3.1.0) , NetX Duo (Version 6.2.0) and the MQTT stack. I run the RTOS with two threads. The first thread (low priority) is the heartbeat thread. In this thread, only one LED is blinking. In the second thread (high priority) a MQTT communication is running. Sending and receiving works also very well.

About the problem: The microcontroller waits for its event at the point where the function "tx_event_flags_get()" is called. The event that is waited for is an MQTT message. I have the problem that the function "tx_event_flags_get()" does not always react to the event. It almost never reacts to the event if the event occurs after a certain time (approx. longer than 20 seconds).

If the microcontroller reaches the above mentioned function and then the event occurs immediately after 1-2 seconds, then everything works very well.

How can it be that if the microcontroller spends a longer time in the "tx_event_flags_get" function, it stops responding to the event even when the event actually arrives? Is there perhaps a buffer or register I should be looking at?

I have added the full code to the attachment. If you need any additional information beyond that, please let me know: event_flag_issue.zip

Thanks in advance and I would appreciate answers or any assistance

[TiejunMS]

It is possible there will be multiple MQTT messages received during two tx_event_flags_get() call. If this is the case, it can be resolved by,

Option 1, for each nxd_mqtt_client_message_get() call, invoke it in a while loop until it fails. Option 2, use semaphore instead of event flags so the count of received messages can be restored.

[momi117]

Hello Tiejun,

thank you for your answer. I still haven't understood you. The µC is waiting for its MQTT message, which it subscribes. It should ignore all other messages that it does not subscribe to and these must not actually influence the waiting for the event either. Why is this a problem when other MQTT messages are sent over the line?

If by "multiple MQTT messages" you mean that the µC received the message it subscribed to multiple times, then I can assure you that this is not the case.

Is there any register or structure I should look at to better understand the problem?

[TiejunMS]

When tx_event_flags_get() is not resumed as expected, could you pause the debugger and look at the value of mqtt_app_flag.tx_event_flags_group_current?

[TiejunMS]

Closing