Azure IoT Hub (MQTT) disconnect when using UART in

Hi,

I'm running into a strange issue with an application based on the azure_iot_hub sample using ncs v2.5.0 running on the nRF9160DK. Everything works fine when I run the code relevant for connecting to the Azure IoT Hub and sending messages in isolation. However when I include all the additional code of my application, the device connects just fine, it can send the first message correctly, but then I get a LOG_WRN indicating that Azure IoT hub is disconnected (result = -128). When debugging, I see that that this event happens during mqtt_input in the mqtt_helper_poll_loop function on line 650.

I have been able to isolate the occurrence of this happening to when I use a module of my code that uses UART2 (on the nRF9160) with Async API to communicate with the nRF52840 and receives responses. I'm not sure if it is relevant, but the processing of receiving messages is done in a dedicated work_queue with a priority set to -1. If I don't send anything over UART (and hence don't receive anything), it works as expected. After sending something over the UART (and receiving a response), the next message (the sample is set up to send the same message every 20 seconds) is sent successfully (Event was successfully sent) but then I get the DISCONNECTED message shortly after. I was wondering if there is some known 'interference' between using a UART (Async API) and MQTT or if this could be related to the work_queue starving the MQTT thread? I tried running the code with not running uart_rx_enable to prevent using the work_queue, but this doesn't seem to resolve it, so it seems to be mostly related to the UART functionality. 

I browsed for similar issues on here and most of it seems to be related to setting up certificates, but all that is fine since it works fine as long as I don't send something over UART.

Best,

Wout

Parents Reply Children
  • Hi Charlie, 

    Thank you getting back to me. I appreciate that it's not easy to support finding the cause of this without having the full context. I'll see if I can isolate the uart part more or find a more minimal example that I can share to have a go at yourself.

    I thought that setting up a dedicated work_queue (which I did) already uses a separate thread and that the work_queue object just helps to abstract the workings of the thread a bit. Am I wrong in thinking that? Would setting up an actual separate thread with it's own main function behave differently than having a dedicated work_queue?

    Best,

    Wout

Related