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,

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.

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.