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!

Update:

I’ve just discovered something interesting.

The exact same STM32 firmware works **perfectly fine** when connected to a Mosquitto broker running on **Windows (localhost)**.

However, when I run the same Mosquitto broker on a **Raspberry Pi** (same local network, same configuration), the issue comes back — messages are delayed, or `MQTTYield()` eventually fails with error code 3 again.

This makes me think it might be related to differences in:
- Network stack behavior between Windows and Linux (on Pi)
- TCP buffering, latency, or Nagle’s algorithm
- Timing precision in how packets are delivered to the STM32 side

So the problem might not be in the STM32 code directly, but in how the broker (or the OS underneath) interacts with it.

Still investigating — I’ll post updates if I find more.

If anyone has experience with Mosquitto on Raspberry Pi or similar low-power Linux devices, I’d love to hear your insights.