MQTT Message Receiving Issue on STM32 (MQTTYield Error / Delayed or Missing Messages)

[Wertyus]

Hi all,

I'm working on an STM32-based system using FreeRTOS, LWIP (static IP), and the Eclipse Paho MQTTClient C library.

Problem Summary:

• MQTT connection is successfully established (MQTTConnect() OK).

• All SUBSCRIBE operations return SUBACK, everything looks fine.

• MQTTYield() initially runs correctly but after a while:

  • Messages stop arriving or arrive with a delay.

  • Sometimes multiple messages are batched and received at once.

• Inside MQTTYield(), the deliverMessage() call fails with error code 3 (FAILURE).

• In net_read(), the recv() function either returns nothing or behaves like a timeout.

• MQTT_LWIP_SOCKET is enabled.

• recv() is non-blocking.

• SO_RCVTIMEO is disabled, but issue persists.

• cycle() is tested both once and inside a while loop – the same issue occurs.

• It seems deliverMessage() is not properly triggered after readPacket().

This problem does not occur consistently in local/home network with Mosquitto. But in corporate/complex networks, messages stop being delivered.

MQTT CONNECT sent...
CONNACK received → rc=0, sessionPresent=0
MQTT connection established.
SUBSCRIBE OK → EPLINK/DEV/YGUM/control/voltage/set
SUBSCRIBE OK → EPLINK/DEV/YGUM/control/output_en
SUBSCRIBE OK → EPLINK/DEV/YGUM/control/fault/reset
All SUBSCRIBE operations completed.

Heap free after Flaman_Init: 10640 bytes
Min Ever Free Heap: 2272 bytes

PUBLISH received: topic="EPLINK/DEV/YGUM/control/process_id"
deliverMessage called → topic = EPLINK/DEV/YGUM/control/process_id
MQTTYield error: 3

...

PUBLISH received: topic="EPLINK/DEV/YGUM/control/voltage/set"
deliverMessage called → topic = EPLINK/DEV/YGUM/control/voltage/set
MQTTYield error: 3

Note: No messages are received after this point. The system connects again and shows the same behavior repeatedly.

---

My Questions:

1. Why does MQTTYield() return error code 3 (FAILURE)?

2. Could select() or recv() configuration cause this (e.g., timeout behavior)?

3. Should cycle() be called multiple times per loop to handle all packets?

4. Why are some messages delivered in batches or delayed significantly?

---

I can share relevant parts of net_read(), MQTTYield(), and cycle() logic if needed.
Thanks in advance to anyone who can help!

[Andrew Neil]

---

@Wertyus wrote:

Eclipse Paho MQTTClient C library.

---

Have you checked out their support options: https://eclipse.dev/paho/support/ ?

[Wertyus]

I've already checked various resources but couldn't find a proper solution. That's why I decided to ask for help here. I'm still investigating the issue, but so far no luck. If you have any ideas or experience related to this problem, I would really appreciate your input. Thank you in advance.

[Andrew Neil]

---

@Wertyus wrote:

1. Why does MQTTYield() return error code 3 (FAILURE)?

---

Have you tried stepping into that function to find out?

Does the Paho documentation give any further details on what "error code 3" means?

[Wertyus]

Yes, I did step into the function using debug. The error is returned from inside the `deliverMessage()` function within `MQTTYield()`. Specifically, it fails while processing the incoming PUBLISH packet — even though the packet itself is fully received and decoded correctly.

The function returns `FAILURE` (code 3) right after calling `messageHandler()` or due to a topic mismatch or internal delivery issue.

Unfortunately, the Paho documentation doesn’t provide much detail about error code 3. It just indicates a generic failure (`MQTTCLIENT_FAILURE`), which can be caused by various internal conditions.

I also tested the following possibilities:

- Increased the `MQTTYield()` timeout (even up to 1000ms)
- Tried calling `cycle()` once per loop and also within a continuous `while` loop
- Verified `recv()` behavior using `select()` and even removed `SO_RCVTIMEO`
- Checked for heap issues and task stack sizes under FreeRTOS
- Re-verified all my topic handlers and callbacks

But unfortunately, the result didn't change.

Even **after successfully receiving a few messages**, the system **still ends up returning error code 3**, or messages **arrive extremely delayed**, or in some cases **stop arriving altogether**.

If you’ve encountered similar behavior or have any suggestions, I’d be really grateful.

Thank you!