MQTT on 54L15

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.

Parents
  • 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

  • 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

  • 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

  • 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

  • Hello Allan,

    Allan-led said:

    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. 

    In mqtt_transport_connect(), a function pointer, which is a part of the transport_fn structure, is called.

    The transport_fn structure is defined here: sdk-zephyr/subsys/net/lib/mqtt/mqtt_transport.c at v4.0.99-ncs1 · nrfconnect/sdk-zephyr.

    You can see that the .connect field is set to this function: sdk-zephyr/subsys/net/lib/mqtt/mqtt_transport_socket_tcp.c at v4.0.99-ncs1 · nrfconnect/sdk-zephyr.

    Regarding the fatal error you are encountering, I agree that the halted execution from stepping and breakpoints might have caused it. It fits the fact that it originates from MPSL, the Multi-protocol Service Layer.

    To overcome this, I recommend that after you reached a certain point with stepping,

    • Set a breakpoint there
    • Remove any prior breakpoint
    • Reset
    • Let the application run freely to that point
    • Continue using either breakpoints or stepping to see where the application goes next.

    Best regards,

    Hieu

  • Hi Hieu,

    Due to the website outage today, I'm unable to provide you with my newest code at the moment. I have decided to transfer over to MQTT-SN, and it seems like all the setup functions were returning without errors, but I have never received anything from the callback function. 

    Regarding the debugger, I tried to follow your instructions this morning, but it was still the same issue; no matter where I set the breakpoint, it leads to the same system halt. 

    Essentially, my new code connects to the OTBR via thread, and waits until it is connected. After that is satisfied, I followed the steps specified at https://docs.zephyrproject.org/latest/connectivity/networking/api/mqtt_sn.html to set up my device as an MQTT-SN client. However, I don't really know which step I did incorrectly. I suspect it is my call to mqtt_sn_add_gw, where the third argument needed to be of type mqtt_sn_data. I created a new mqtt_sn_data struct, and set the data section to the IPv6 address of my raspi5. 

    It would be great if you could give me some guidance on how to set up the MQTT-SN client following the tutorial mentioned above, thanks!

    Best regards,

    Allan

Reply
  • Hi Hieu,

    Due to the website outage today, I'm unable to provide you with my newest code at the moment. I have decided to transfer over to MQTT-SN, and it seems like all the setup functions were returning without errors, but I have never received anything from the callback function. 

    Regarding the debugger, I tried to follow your instructions this morning, but it was still the same issue; no matter where I set the breakpoint, it leads to the same system halt. 

    Essentially, my new code connects to the OTBR via thread, and waits until it is connected. After that is satisfied, I followed the steps specified at https://docs.zephyrproject.org/latest/connectivity/networking/api/mqtt_sn.html to set up my device as an MQTT-SN client. However, I don't really know which step I did incorrectly. I suspect it is my call to mqtt_sn_add_gw, where the third argument needed to be of type mqtt_sn_data. I created a new mqtt_sn_data struct, and set the data section to the IPv6 address of my raspi5. 

    It would be great if you could give me some guidance on how to set up the MQTT-SN client following the tutorial mentioned above, thanks!

    Best regards,

    Allan

Children
No Data
Related