MQTT return ERROR after 24 hours

[RobertT]

Hello!

 I am sending MQTT commands over UART from an NRF52840 DK to the NRF9160 DK which has the ibasis sim card inside. I noticed 3 times so far that after 24 hours , 1 hour tolerance, I get only  ERROR messages returned after sending the MQTT commands with the payload.  Basically I need to reset the NRF52840 DK and  re-send all the MQTT commands for connecting to the MQTT broker, autenthificating, opening connection and initialising the modem ( AT+CFUN = 1 etc) .

 I was wondering if there were previous experiences like this.  I did use an osciloscope and the NRF52840 DK is sending the right commands with the good payload over UART even after 24 hours, it's just like the modem closes the connection or something...

All the best,

Robert.

[Carl Richard]

Hi, Robert!

Thank you for reaching out! You're saying that you have to call AT+CFUN=1 in addition to all the MQTT procedures. This means that the modem has shut down at some point. Could you provide a short description of your application's behavior? How often does it upload data, and what does it do in between?

What kind of MQTT broker are you connecting to? It may be that it has some restrictions/timeouts for connected devices.

Any logs from the nRF9160 would also be appreciated. Please add "CONFIG_SLM_LOG_LEVEL_DBG=y" in the prj.conf.

Best regards,
Carl Richard

[RobertT]

 Thank you for the prompt reply, Richard!

 I will ad the "CONFIG_SLM_LOG_LEVEL_DBG=y" now to the NRF9160 and start it again. Until then:

 

- I am using a mosquitto on a google virtual macine to which I connect using username and password. Used before same set up but instead of the NRF9160 I used a raspberry to publish the data to the broker.  The NRF52840 was sending the data over USB to the raspberry and the raspberry to mqtt.

- the succesion of commands I give out when the NRF52840 starts running AT\r\n ; AT+CFUN=1\r\n ; AT+CFUN?\r\n ; AT#XMQTTCON=1,"test","USER_HERE","PASSWORD_HERE","34.105.208.xxx",10803\r\n ;  AT#XMQTTPUB="gw-event/received_data/",1,"PAYLOAD_HERE",1,0\r\n ; 

- the NRF52840 gets data over bluetooth from beacons and send the data over UART to the NRF9160; 

 

- testing phase now so only sends out data once every 24s , in between it does nothing , the nrf9160 runs in normal mode; once data is received over uart then callback function is triggerred and publishes the data over mqtt; 

- will get back to you with the logs also, once I have them;

All the best,

Robert!

[RobertT]

Hello, Richard!

 In the first instance I was giving the series of commands  only once in the function " void App_init(const app_global_functions_t * functions) " ...now I also Included those function with each callback when I have a message on UART, in the functions " lib_data->setDataReceivedCb(uart_write);
lib_data->setBcastDataReceivedCb(uart_write); " .

 The called function "uart_write " sends the series of commands "  AT\r\n ; AT+CFUN=1\r\n ; AT+CFUN?\r\n ; AT#XMQTTCON=1,"test","USER_HERE","PASSWORD_HERE","34.105.208.xxx",10803\r\n ;  AT#XMQTTPUB="gw-event/received_data/",1,"PAYLOAD_HERE",1,0\r\n ; " each time.

 For the last 3 days the modem worked continuously.  I

[Carl Richard]

Hi again!

Understood. It seems like a part of your answer was lost, but I take it as the application works now? The solution is arguably not clean, as you have to send the full series of commands every time, so we could look further into this if you would like that. Again, any logs are appreciated!

It seems like your device disconnects from the broker at some point, since it works when you do the connection procedure every time.

Best regards,
Carl Richard

[RobertT]

 I did enable logging "CONFIG_SLM_LOG_LEVEL_DBG=y"  ...a web-link with instructions on how to pass over the logs to you? ... in the sense that I've read that only development can read the logs...

[Carl Richard]

You can post the logs here either by uploading the file directly or by pressing "Insert"->"Code" and copying in the log contents. If the information is sensitive I can make this case private.

Best regards,
Carl Richard

[RobertT]

 I was saying I do not know how to access the logs. Thank you!

[Carl Richard]

Hi again!

This sample writes the logs over the RTT protocol. So if you connect to the device with the JLink RTT Viewer (or using the built in terminal in SES), the logs should be printed there.

Logs are not to be confused with a modem trace, which only can be read by us here. I don't need a modem trace from you yet, as I don't believe that this is a modem issue.

Best regards,
Carl Richard

[RobertT]

Yes, I did confuse the 2 of them. Will get on it and get back to you. All the best!

[RobertT]

An update + unknown:

 - after 3 days of working the modem stoped again transmitting over MQTT; connected the oscilloscope probe to the UART and got nothing back this time, no "ERROR" message or anything else. The NRF52840 was transmitting data to the NRF9160 continuously though. 

 I pressed " RESET" on the NRF52840 DK and it had no effect on the NRF9160 DK, still no reply on UART ...like an " OK " back from the at commands or an " ERROR " ; I pressed " RESET"  on the NRF9160 DK and I got the " READY" reply message and it started working again as expected with all the reply messages on UART.

- I started the RTT Viewer V6.98b on Windows and will get back with the logs when the modem stops next time. 

  All the best,

Robert.

[Carl Richard]

Thanks for the update. The nRF9160 must have crashed somehow, which is unfortunate. Hopefully the logs will provide some insight!

Best regards,
Carl Richard

[RobertT]

Hello, Richard!

 I attached 2 log files, data and terminal logging. 

The NRF9160DK stoped again without any reply on the UART channel, while the NRF52840 was sending data every 20 seconds as it should. I pushed " RESET " on the NRF9160DK and started working again.

 The NRF9160 DK USB is connected to the PC and the NRF52840 DK is connected to an USB mains adapter. The time when it worked for 3 days they were both connected to the mains through an USB adapter. The PC is set to never go to sleep so I do have power all the time. Doesn't make sense to mention this setup  but I though to add it in also...

 I started LOGGING after I connected to the NRF9160DK. If the logs are not the proper ones please let me know.

All the best,

Robert.

=====added by me manually because I started loging after I turned ON the RTT Viewer===

=====START HERE====
LOG: J-Link RTT Viewer V6.98b: Logging started.
LOG: Terminal 0 added.
LOG: Terminal 10 added.
LOG: Connecting to J-Link via USB...
LOG: Device "NRF9160_XXAA" selected.
LOG: ConfigTargetSettings() start
LOG: ---Setting ROM table---
LOG: ConfigTargetSettings() end
LOG: Found SW-DP with ID 0x6BA02477
LOG: DPIDR: 0x6BA02477
LOG: Scanning AP map to find all available APs
LOG: AP[7]: Stopped AP scan as end of AP map has been reached
LOG: AP[0]: AHB-AP (IDR: 0x84770001)
LOG: AP[1]: AHB-AP (IDR: 0x24770011)
LOG: AP[2]: JTAG-AP (IDR: 0x12880000)
LOG: AP[3]: APB-AP (IDR: 0x54770002)
LOG: AP[4]: JTAG-AP (IDR: 0x12880000)
LOG: AP[5]: JTAG-AP (IDR: 0x12880000)
LOG: AP[6]: MEM-AP (IDR: 0x128800A1)
LOG: Iterating through AP map to find AHB-AP to use
LOG: AP[0]: Core found
LOG: AP[0]: AHB-AP ROM base: 0xE00FF000
LOG: CPUID register: 0x410FD212. Implementer code: 0x41 (ARM)
LOG: Found Cortex-M33 r0p2, Little endian.
LOG: FPUnit: 8 code (BP) slots and 0 literal slots
LOG: Security extension: implemented
LOG: Secure debug: enabled
LOG: CoreSight components:
LOG: ROMTbl[0] @ E00FF000
LOG: ROMTbl[0][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33
LOG: ROMTbl[0][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT
LOG: ROMTbl[0][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB
LOG: ROMTbl[0][3]: E0000000, CID: B105900D, PID: 000BBD21 ITM
LOG: ROMTbl[0][5]: E0041000, CID: B105900D, PID: 002BBD21 ETM
LOG: ROMTbl[0][6]: E0042000, CID: B105900D, PID: 000BBD21 CSS600-CTI
LOG: RTT Viewer connected.
LOG: Terminal logging started.
LOG: Data logging started.
=====END HERE======

=====WHAT IS BELLLOW IS ALL THAT THE SYSTEM SAID AFTERWARDS====

# SEGGER J-Link RTT Viewer V6.98b Data Log File
# Compiled: 15:05:00 on Mar 12 2021
# Logging started @ 10 Apr 2021 22:18:33

logsRTT3.log