• Registered: 2020-11-13
  • Posts: 3

Topic: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

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.

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 357

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

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

embhorn's Website

Share

  • Registered: 2020-11-13
  • Posts: 3

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

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.

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 357

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

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

embhorn's Website

Share

  • Registered: 2020-11-13
  • Posts: 3

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

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,

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 357

Re: Difficulty using MqttClient_Publish_ex with PIC32 Harmony 3.00

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

embhorn's Website

Share