configASSERT failure happens when an ACK message is received out of sequence

Libraries
1

Greetings,

I encountered another bug while developing a Fleet Provisioning (FP) application which runs on the Renesas RX65N MCU.
In rare occassions (~1 out of 500 attempts), the following ASSERTION failure (or similar) occurs.

ASSERTION FAILED: globalSubscribePacketIdentifier == usPacketIdentifier FILE C:/ws/iot-reference-rx/Demos/common/Mqtt_Demo_Helpers/mqtt_pkcs11_demo_h

(Note: The ASSERTION failure may also happen with globalUnsubscribePacketIdentifier == usPacketIdentifier)

I referred the reference code provided in this repo: FreeRTOS-Plus/Demo/../../mqtt_pkcs11_demo_helpers.c
This is my baseline code where I encountered the issue: mqtt_pkcs11_demo_helpers.c

After investigation, I found that the ASSERTION fails when the ACK packet is received out of sequence, maybe due to timing issue or network jitter.
(i.e: Device sends an Unsubscribe command, but received a prior SUBACK packet instead)

Request

  1. I believe the mqtt-agent is asynchronous, it does not wait for ACK before executing the next command.
    Based on this logic, I decided to remove the 2 failing configASSERT checks.
    →Is this acceptable?

  2. Additionally, I implemented a logic to return error in case no packet is received/processed within the timeout period.
    →Does this align with the original design policy?

I attached my modified code for reference: mqtt_pkcs11_demo_helpers.c (51.9 KB)

Thank you.

2

That should not be a problem because globalSubscribePacketIdentifier and globalUnsubscribePacketIdentifier are different? Or are you getting delayed SUBACKs?

3

@aggarg: Yes, I believe so. It’s either delayed or out-of-sequence.

4

The demo code that you linked does not use MQTT Agent. It uses MQTT instead: FreeRTOS/FreeRTOS-Plus/Demo/AWS/Mqtt_Demo_Helpers/mqtt_pkcs11_demo_helpers.c at main · FreeRTOS/FreeRTOS · GitHub. The sequence is:

  1. Get a packet ID and store it in globalSubscribePacketIdentifier: FreeRTOS/FreeRTOS-Plus/Demo/AWS/Mqtt_Demo_Helpers/mqtt_pkcs11_demo_helpers.c at main · FreeRTOS/FreeRTOS · GitHub.
  2. Send MQTT subscribe request: FreeRTOS/FreeRTOS-Plus/Demo/AWS/Mqtt_Demo_Helpers/mqtt_pkcs11_demo_helpers.c at main · FreeRTOS/FreeRTOS · GitHub.
  3. Wait for ACK: FreeRTOS/FreeRTOS-Plus/Demo/AWS/Mqtt_Demo_Helpers/mqtt_pkcs11_demo_helpers.c at main · FreeRTOS/FreeRTOS · GitHub.

Is it possible that you are not waiting long enough to get the ACK and proceeding with further operations? You can try increasing mqttexamplePROCESS_LOOP_TIMEOUT_MS: FreeRTOS/FreeRTOS-Plus/Demo/AWS/Mqtt_Demo_Helpers/mqtt_pkcs11_demo_helpers.c at main · FreeRTOS/FreeRTOS · GitHub.

5

@aggarg: Sorry for the late response.

Noted on your suggestion, that seems to be the most straightforward solution.

As mentioned in my post, this error very rarely happens.
I suppose we could try with a longer timeout period and re-test whether it helps with the issue.

Meanwhile, I’d still like to confirm the point below:

This process seems to be asynchronous (i.e: it does not wait for ACK before executing the next command.
In that case, is it acceptable if I were to remove the 2 failing configASSERT checks?

6

This is demo code and you are free to modify it as per your needs. The thing that you should verify is that the code is not written in such a way that ACK for one message may be mistaken for some other. As long as it is not the case, it should be fine.

1 Like
7

@aggarg : Thanks for the advice, I have no further questions.

I’ll mark you comment re: increasing timeout as the solution and close this ticket.
Thank you!