wolfSSL - Embedded SSL Library — Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

null@example.com (embhorn) — Thu, 03 Dec 2020 23:39:46 +0000

Hi @agubisch

No, I think you are correct. It looks like MqttClient_Publish_WritePayload has overloaded the meaning of the return value MQTT_CODE_CONTINUE, so that the publish callback does not work correctly when non-blocking is enabled. I think a new return code is needed to specify the condition that the callback should be executed again.

I opened a ticket to track this defect
https://github.com/wolfSSL/wolfMQTT/issues/192

Thanks for your help investigating this issue!

-Eric @ wolfSSL Support

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

null@example.com (agubisch) — Mon, 30 Nov 2020 17:36:13 +0000

Hi Eric,
Yes, Microchip finally updated Harmony WolfMQTT to version 1.7 (from 1.2), but the problem remains.

Looking at the MqttClient_Publish_WritePayload function the pubCb function is called first and then the payload is written. If the MqttPacket_Write function returns MQTT_CODE_CONTINUE (-101) because (for example) the tcp tx buffer is full, the WritePayload function will call pubCb again before calling MqttPacket_Write to complete the write from the mqtt SendBuff.

Maybe I am not understanding how the callback is supposed to work. I have a work around where I delay in the net glue code until current payload buffer is written, but this defeats the idea of non-blocking code.

Thanks,

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

null@example.com (embhorn) — Mon, 23 Nov 2020 15:59:24 +0000

Hello @agubisch

It looks like there was a fix added to properly return the MQTT_CODE_CONTINUE error. Could you please confirm the release? Also can you please confirm that WOLFMQTT_NONBLOCK is defined in the settings?

Thanks,
Eric @ wolfSSL Support

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

null@example.com (agubisch) — Fri, 13 Nov 2020 18:23:05 +0000

Hi Eric,
The only example written for Harmony 3.00 does not use MqttClient_Publish_ex, just MqttClient_Publish and this is working correctly for me.
If I make the tcp tx buffer larger than the total payload size, the MqttClient_Publish_ex works. This problem seems to be related to the way wolfMQTT handles the MQTT_CODE_CONTINUE from the Harmony net glue layer.

Thank you.

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

null@example.com (embhorn) — Fri, 13 Nov 2020 17:53:24 +0000

Hello @agubisch

Have you tested the firmware push example as-is with the PIC32? Does it also demonstrate the issue you are seeing?

Thanks,
Eric @ wolfSSL Support

Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

null@example.com (agubisch) — Fri, 13 Nov 2020 17:06:32 +0000

WolfMQTT is running correctly with PIC32 Harmony 3.00 for messages smaller than my publish buffer.

I am trying to publish data that is larger than my publish buffer using MqttClient_Publish_ex. The code is modeled after the fwpush.c example, but I am still having problems.

PIC32 Harmony uses wolfMQTT in the non-blocking mode, and after the second (final) publish callback the Harmony net glue code (WMQTT_NETGlue_Write) returns a MQTT_CODE_CONTINUE response when called from the MqttPacket_Write function.

Calling MqttClient_Publish_ex after the MQTT_CODE_CONTINUE causes an additional publish callback, which does not return any data, since it has all been read.

This generates a MQTT_CODE_ERROR_BAD_ARG response because the client->write.len = 0

How do I get wolfMQTT to call the MqttSocket_Write (WMQTT_NETGlue_Write) until the entire tcp tx buffer is sent?

I appreciate any ideas on what to try next.