MQTT on 54L15

[Allan-led]

Hi all,

Has anyone implemented an MQTT client on an 54L15 before? I have been searching the web and I have not seen a sample program or anyone talking about MQTT with 54L15 only. I would appreciate any sample programs, it doesn't need to be complicated, I just want to verify that we can indeed implement the callback functions and its functionalities on 54L15. Thanks.

[Hieu]

Hi Allan-led,

I don't think anyone has tried MQTT over Thread on the nRF54L15 before, but it seems to have been attempted on the nRF52840. The nRF54L15 has improvements compared to the nRF52840, so perhaps it could handle TCP better. However, it hasn't been tried, to my knowledge.

As for the error you are having, it is going to be challenging to figure out from just reading the code alone. Could you please use the debugger to get the full call stack to where it failed? That will give us more ideas to work with.

Hieu

[Allan-led]

Hi Hieu,

I don't think the debugger has taken us very far; the error that I encountered occurred during the call to mqtt_connect(), but it did not lead to a total halt of the device. tried re-initializing the client and re-connecting it in the main while loop, and it keeps producing the same error. After the errors are produced, I am still able to interact with the device through the command line, which indicates that the device is still alive. 

Here are the outputs:

In the image above, I verified that the connection between my device and the OTBR is indeed established. I can continue interacting with the device even if the error message was produced. 

Then, I tried using the debugger: 

Here is where the debugger took me.

However, I tried pressing continue and pausing past this point, it led me to a fatal halt with reason 3. This is actually the case with all of my projects, am I using the debugger incorrectly or is there a common issue among all of my projects? 

Best regards,
Allan

[Hieu]

Hello Allan,

The protocol stack requires strict interrupt and execution timing to control the radio properly, so a debugging will cause a fault when we resume operations.

What we want to do with debugging here is to use stepping or breakpoint to identify where in the call stack the error originates from. In this case, we just want to identify where in the mqtt_connect() call stack the error was initially returned.

Best regards,

Hieu

[Allan-led]

Hi Hieu,

Thank you for resolving my confusion about the fatal halt with reason 3, this has puzzled me for a while.

In terms of the debugger, there's another unexpected behavior:

When my code lands at the highlighted line, it cannot go further to the breakpoint on the next line, as running it causes a system halt, which is something that I haven't encountered in regular execution of the program. 

When I step into this line and continue stepping, 

I land at the memset. Trying to continue or stepping over this line will result in the system halt. 

It still seems like reason 3 to me, but I don't come across this while just executing the program.

This is the same case if I try stepping in the mqtt_connect function. I think the debugger might be interfering with the mutex, which causes a system halt. 

Since the mqtt_connect function returns -116 to me, I'm almost certain that the error was returned by the client_connect function. In client_connect, I added some logs, and I found that the function returns due to error_code -116 produced by mqtt_transport_connect. 

I went further into mqtt_transport_connect and had trouble understanding how the error code was produced. 

TLDR: the error code -116 was produced from mqtt_transport_connect, but I have trouble figuring out how this was produced, as the implementation for the .connect function is not visible to us. 

Best regards,

Allan