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

SUPL library fails: at_cmd: Response buffer not large enough

Hi,

I am trying to do AGPS with the supl library. 
I obtained version 0.7 through the application and installed it (and enabled the required config options).

Unfortunately, this is now crashing the (asset_tracker_v2) application:

[00:00:19.456,542] <dbg> cloud_codec_ringbuffer.cloud_codec_populate_sensor_buffer: Entry: 1 of 9 in sensor buffer filled
[00:00:19.468,200] <dbg> agps.open_supl_socket: ip 74.125.193.192 (c0c17d4a) port 7276
[00:00:19.508,056] <wrn> modem_module: Unsupported modem firmware version: mfw_nrf9160_1.3.0
[00:00:19.517,150] <wrn> modem_module: Expected firmware version: mfw_nrf9160_1.2.3
[00:00:19.525,543] <wrn> modem_module: You can change the expected version through the
[00:00:19.534,210] <wrn> modem_module: EXPECTED_MODEM_FIRMWARE_VERSION setting.
[00:00:19.542,327] <wrn> modem_module: Please upgrade: http://bit.ly/nrf9160-mfw-update
[00:00:19.551,147] <inf> event_manager: MODEM_EVT_MODEM_STATIC_DATA_READY
[00:00:19.558,380] <dbg> modules_common.module_enqueue_msg: modem module: Enqueued: MODEM_EVT_MODEM_STATIC_DATA_READY
[00:00:19.569,549] <dbg> modules_common.module_enqueue_msg: data module: Enqueued: MODEM_EVT_MODEM_STATIC_DATA_READY
[00:00:19.580,535] <dbg> modules_common.module_enqueue_msg: cloud module: Enqueued: MODEM_EVT_MODEM_STATIC_DATA_READY
[00:00:19.591,644] <dbg> modules_common.module_enqueue_msg: app module: Enqueued: MODEM_EVT_MODEM_STATIC_DATA_READY
[00:00:19.602,661] <dbg> modules_common.module_get_next_msg: app module: Dequeued MODEM_EVT_MODEM_STATIC_DATA_READY
[00:00:19.613,922] <dbg> modules_common.module_get_next_msg: data module: Dequeued MODEM_EVT_MODEM_STATIC_DATA_READY
[00:00:19.625,305] <inf> agps: Starting SUPL session
[00:00:19.633,697] <err> at_cmd: Response buffer not large enough
[00:00:19.640,716] <err> supl_client: Fetching LTE info failed

The error is pretty straightforward, but I already increased the AT buffer size from 2700 to 4000, and I still get this error..

Is this normal? What is the recommended AT buffer size for use with AGPS?

(I am using SDK 1.5.0, modem firmware 1.3.0, revision 1 of the thingy91.)

Kind regards,

Arnout

  • Hmm, I increased it to 10K, and it still gave that error. Further enabled AT debugging, and it is now showing this:

    [00:00:09.109,619] <inf> agps: Starting SUPL session
    [00:00:09.115,051] <dbg> at_cmd.at_cmd_write: Awaiting response for AT+COPS?
    [00:00:09.122,741] <dbg> at_cmd.at_write: Sending command AT+CIMI
    [00:00:09.129,608] <dbg> at_cmd.socket_thread_fn: at_cmd_rx 22 bytes, 295050900992735
    OK
    
    [00:00:09.138,488] <dbg> at_cmd.socket_thread_fn: Enqueueing response for sync call
    [00:00:09.146,728] <dbg> at_cmd.socket_thread_fn: Writing any pending command
    [00:00:09.154,296] <dbg> at_cmd.socket_thread_fn: Listening on socket
    [00:00:09.161,254] <dbg> at_cmd.at_cmd_write: Awaiting response for AT+CIMI
    [00:00:09.168,731] <dbg> at_cmd.at_write: Sending command AT+CEREG?
    [00[00:00:09.176,147] <dbg> at_cmd.socket_thread_fn: at_cmd_rx 62 bytes, +CEREG: 5,5,"4E84","01042208",7,,,"11100000","11100000"
    OK
    
    [00:00:09.188,415] <dbg> at_cmd.socket_thread_fn: Enqueueing response for sync call
    [00:00:09.196,563] <dbg> at_cmd.socket_thread_fn: Writing any pending command
    [00:00:09.204,162] <dbg> at_cmd.socket_thread_fn: Listening on socket
    :00:09.175,750] <dbg> at_cmd.at_cmd_write: Awaiting response for AT+CEREG?
    [00:00:09.218,780] <dbg> at_cmd.at_write: Sending command AT%XMONITOR
    [0[00:00:09.232,421] <dbg> at_cmd.socket_thread_fn: at_cmd_rx 143 bytes, %XMONITOR: 5,"Stay Safe Orange B","Stay Safe Orange B","20610","4E84",7,20,"01042208",314,6400,54,37,"","11100000","11100000","01001001"
    OK
    
    [00:00:09.251,892] <err> at_cmd: Response buffer not large enough: 128 vs 139
    [00:00:09.259,765] <dbg> at_cmd.socket_thread_fn: Enqueueing response for sync call
    [00:00:09.267,944] <dbg> at_cmd.socket_thread_fn: Writing any pending command
    [00:00:09.275,573] <dbg> at_cmd.socket_thread_fn: Listening on socket
    0:00:09.232,116] <dbg> at_cmd.at_cmd_write: Awaiting response for AT%XMONITOR
    [00:00:09.290,130] <err> supl_client: Fetching LTE info failed
    

    FYI did this modif to check the error

    diff --git a/lib/at_cmd/at_cmd.c b/lib/at_cmd/at_cmd.c
    index 7f2f476f..4c49a478 100644
    --- a/lib/at_cmd/at_cmd.c
    +++ b/lib/at_cmd/at_cmd.c
    @@ -301,7 +301,7 @@ static void socket_thread_fn(void *arg1, void *arg2, void *arg3)
                        current_cmd.resp != NULL &&
                        ret.state != AT_CMD_NOTIFICATION) {
                            if (current_cmd.resp_size < payload_len) {
    -                               LOG_ERR("Response buffer not large enough");
    +                               LOG_ERR("Response buffer not large enough: %d vs %d", current_cmd.resp_size,  payload_len);
                                    ret.code  = -EMSGSIZE;
                                    goto next;
                            }
    

    This makes little sense. After the supl library is loaded, thing seem to be going south?

    I am trying to use the supl library version 0.7 with SDK1.5.0. Is this supposed to work?

  • And just to be clear, the "actual" final issue is that the application hits z_arm_exc_spurious after that last debugprint. I was assuming this was due the too-big AT CMD, but perhaps some other memory corruption issue due to the library loading is causing this.

    [EDIT]: Version 0.6.1 gives the same issue.

    [EDIT]: Tested with both modem 1.3.0 and 1.2.3 FWs

    In any case, I am not succesful in using the supl agps library.

  • Hello Arnout,

    I unfortunately do have limited knowledge about the SUPL client library and most of our experts are out of office due to the summer vacation period.

    But to start with, there are two things I can give you feedback on:

    1. Why are you using the Asset Tracker v2 to implement the SUPL client library? This application is quite heavy and the implantation might get complex pretty fast, so I wonder if it wouldn’t be more convenient to use applications like the nRF9160: A-GPS as a reference instead?

    2. Have you configured the SUPL library correctly and defined all necessary buffer sizes?

    Regards,

    Markus

  • Hi Markus,

    I am using the asset tracker v2, since the asset tracker v1 just worked out of the box but was not power efficient. the v2 does not have the NRF cloud by default, hence AGPS must be added.

    But fair enough, I tried to compile the agps example. For now, I am running into an issue that it wont compile because it thinks I have too little flash. This is a little off topic, but perhaps you know by heart how to fix this?

    Memory region         Used Size  Region Size  %age Used
               FLASH:         64 KB        48 KB    133.33%
                SRAM:        8768 B        64 KB     13.38%
            IDT_LIST:          88 B         2 KB      4.30c:/nordic/nordicsdk/v1.5.0/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: zephyr\zephyr_prebuilt.elf section `.gnu.sgstubs' will not fit in region `FLASH'
    
    
    (while e.g. the asset tracker v2 links perfectly, and reports:)
    
    Memory region         Used Size  Region Size  %age Used
               FLASH:      228356 B     425472 B     53.67%
                SRAM:      107120 B     178968 B     59.85%
            IDT_LIST:         184 B         2 KB      8.98%
    
    
    

    Regarding the buffer sizes, I simply unpacked the supl package (which includes the header file with its default values, and added the supl library config option and agps option to enable it

  • btw, for some reason I have to add CONFIG_BOOTLOADER_MCUBOOT=y to enable it fitting in flash on the thingie91 target.. (both on sdk1.5.0 and sdk1.5.1). Will test this now.. Stay tuned

Related