This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

serial_lte_modem app gets stuck after multiple AT#XHTTPCREQ commands

We are using nrf9160 as an LTE-M modem with the serial_lte_modem app running on it. Another chip (ESP32) communicates with it using AT commands and after a few minutes of successful communication (~tens of AT#XHTTPCREQ commands) the nrf chip gets stuck and no longer responds to requests.

serial_lte_modem & sdk version: 1.4.0

modem fw version: 1.2.2

network: NB-IOT, Vodafone Czech Republic

nrf log:

00> [00:05:52.526,519] <inf> httpc: Partial data received (235 bytes)
00> [00:05:52.557,861] <inf> httpc: Partial data received (42 bytes)
00> [00:05:52.557,861] <inf> httpc: All the data received (277 bytes)
00> [00:05:52.622,161] <inf> at_host: RX_DISABLED
00> [00:05:52.635,223] <inf> httpc: send header: 20 bytes
00> [00:05:52.635,620] <inf> httpc: wait until payload is ready
00> [00:05:52.644,042] <inf> httpc: send 51 bytes payload
00> [00:05:52.644,195] <inf> at_host: RX_DISABLED
00> [00:05:52.644,226] <wrn> at_host: UART RX buf rsp: -13
00> [00:05:52.644,317] <err> at_cmd: Invalid command
00> [00:05:52.644,317] <err> at_host: AT command error: -22
00> [00:05:52.646,118] <inf> at_host: RX_DISABLED

following two lines repeat aprox. 500 times:

00> [00:05:52.647,827] <err> at_cmd: Invalid command
00> [00:05:52.647,827] <err> at_host: AT command error: -22

00> [00:05:53.708,984] <inf> httpc: Partial data received (277 bytes)
00> [00:05:53.708,984] <inf> httpc: All the data received (277 bytes)

Sometimes the nrf chip reboots on its own, but most of the time it gets stuck and manual reboot is required.

The log contains `[00:04:22.522,003] <wrn> at_host: UART RX buf rsp: -13` but we have also captured logs without this error.

Parents
  • I have discovered that this error happens after the ESP sends the payload of the XHTTPCREQ command. Instead of receiving #XHTTPCREQ:0 we receive something else. I have captured two different instances of this problem:

    Log #1 - Ready is received after the payload has been accepted (via OK) by the NRF. The Ready message signalizes (reboot? reinit?) of the modem, so nrf is not stuck.

    ESP>NRF91:
    AT#XHTTPCREQ="POST","/auth","Content-Length: 51
    ",51
    NRF91>ESP:OK
    NRF91>ESP:#XHTTPCREQ:1
    ESP>NRF91:
    {"data":"........."}
    NRF91>ESP:OK�Ready

    Log #2 - ERROR is received after the payload confirmation. Now the NRF modem is stuck, it never reconnects again.

    ESP>NRF91:
    AT#XHTTPCREQ="POST","/auth","Content-Length: 51
    ",51
    NRF91>ESP:OK
    NRF91>ESP:#XHTTPCREQ:1
    ESP>NRF91:
    {"data":".........."}
    NRF91>ESP:OK@
    NRF91>ESP:ERROR

Reply
  • I have discovered that this error happens after the ESP sends the payload of the XHTTPCREQ command. Instead of receiving #XHTTPCREQ:0 we receive something else. I have captured two different instances of this problem:

    Log #1 - Ready is received after the payload has been accepted (via OK) by the NRF. The Ready message signalizes (reboot? reinit?) of the modem, so nrf is not stuck.

    ESP>NRF91:
    AT#XHTTPCREQ="POST","/auth","Content-Length: 51
    ",51
    NRF91>ESP:OK
    NRF91>ESP:#XHTTPCREQ:1
    ESP>NRF91:
    {"data":"........."}
    NRF91>ESP:OK�Ready

    Log #2 - ERROR is received after the payload confirmation. Now the NRF modem is stuck, it never reconnects again.

    ESP>NRF91:
    AT#XHTTPCREQ="POST","/auth","Content-Length: 51
    ",51
    NRF91>ESP:OK
    NRF91>ESP:#XHTTPCREQ:1
    ESP>NRF91:
    {"data":".........."}
    NRF91>ESP:OK@
    NRF91>ESP:ERROR

Children
No Data
Related