I ported the FreeRTOS 20210700 to STM32, when I used none-agent version mqtt to publish to AWS, if set qos0, then it is working fine and reliable. But when I use qos1, the it shows publish failed.
When I use the OTA which is agent version of MQTT, the publish is failed, I found it is using qos1 too.
May I know if any setting affect this?
requestJob_Mqtt:Failed to publish MQTT message:publish returned error: OtaMqttStatus_t=OtaMqttPublishFailed
Failed to subscribe to MQTT topic: subscribe returned error: OtaMqttStatus_t=OtaMqttSubscribeFailed, topic=$aws/things/350999901/jobs/notify-next
thanks aggarg, I port to STM32H7 with LwIP stack. I can connect to AWS and report using none-agent mqtt version with qos 0.
then I run the code of agent version mqtt:
here is some logs when I run the simple_sub_pub_demo.c
It seems the prvPublishCommandCallback never got called.
I know it maybe my port issue as the windows simulator works, so it should not be a problem of mqtt agent. Any hints is great.
simple_sub_pub_demo. +387 prvSubscribeToTopic Sending subscribe request to agent for topic filter: /filter/Publisher0 with id 1
simple_sub_pub_demo. +414 prvSubscribeToTopic Received subscribe ack for topic /filter/Publisher0 containing ID 1
simple_sub_pub_demo. +490 prvSimpleSubscribePublish Sending publish request to agent with message "Publisher0 publishing message 0" on topic "/filter/Publisher0"
simple_sub_pub_demo. +505 prvSimpleSubscribePublish Task Publisher0 waiting for publish 0 to complete.
simple_sub_pub_demo. +516 prvSimpleSubscribePublish Demo completed successfully. 0, 0
simple_sub_pub_demo. +490 prvSimpleSubscribePublish Sending publish request to agent with message "Publisher0 publishing message 1" on topic "/filter/Publisher0"
simple_sub_pub_demo. +505 prvSimpleSubscribePublish Task Publisher0 waiting for publish 1 to complete.
configASSERT:../Core/MQTT_Agent/simple_sub_pub_demo.c:513
prvPublishCommandCallback should get called from here which should get called when MQTT_ProcessLoop is called here. Are you calling MQTTAgent_CommandLoop function in a loop like here?
Can you set breakpoints at above three locations to see where is it failing?
it appears stuck in MQTT_ProcessLoop. But first time call, it is OK, then not returning.
I suspect there is some socket option on receives etc, as I change to use LwIP stack.
here is the logs: (Interesting to see number 8 package actual reaches AWS IoT )
It looks like QoS 0 does not need reply, so it works, but when get QoS 1, it needs ACK, then stop working. Stuck in readFunc in MQTT_GetIncomingPacketTypeAndLength:
Really appreciate if can shot further light on it. thanks
MQTTStatus_t MQTT_GetIncomingPacketTypeAndLength( TransportRecv_t readFunc,
NetworkContext_t * pNetworkContext,
MQTTPacketInfo_t * pIncomingPacket )
{
Seems like an error in receive. Can you check what this error code means?
You probably need to increaseMQTT_COMMAND_CONTEXTS_POOL_SIZE. For debugging, you can reduce the number of publisher tasks and enable them later once you get one task working.
Seems like you are hitting an assert. What is this assert?
Another thing to try. You are right in that QoS1 will definitely take more time because you will need to send a PUBACK to the broker in addition to just receiving the actual message. Although, it seems you mentioned that you are stuck at the recv call, and this can happen when the transport recv function has no configured timeout. Have you enabled LWIP_SO_RCVTIMEO and used netconn_set_recvtimeout to set the recv timeout of the socket as shown in this tutorial? You will likely want to do the same for send.
thanks @aggarg and @abrinao ,
today I solved this problem.
The reason is when I port the lwIP, the socket set_option parameter takes the one from FreeRTOS Plus stack. But they have different defines. After I set the socket option timeout correctly, it is working now.
The stuck of recv call is because timeout does not work, and it hang there.
Thanks again.