Asset_tracker V2 run time buffer overflow in LTE

I run the Asstet_tracker V2. The part of LTE log is as below:

.....
2022-05-19T07:58:34.234Z DEBUG modem << [00:00:33.314,788] [0m<dbg> azure_iot_hub_integration: azure_iot_hub_event_handler: AZURE_IOT_HUB_EVT_CONNECTED[0m
2022-05-19T07:58:34.425Z DEBUG modem << [00:00:33.504,974] [0m<dbg> azure_iot_hub_integration: azure_iot_hub_event_handler: AZURE_IOT_HUB_EVT_READY[0m
2022-05-19T07:58:34.441Z DEBUG modem << [00:00:33.514,892] [0m<dbg> cloud_module: cloud_wrap_event_handler: CLOUD_WRAP_EVT_CONNECTED[0m
2022-05-19T07:58:34.444Z DEBUG modem << [00:00:33.523,651] [0m<inf> app_event_manager: CLOUD_EVT_CONNECTED[0m

after this
[00:00:33.530,120] [0m<dbg> ui_module: state_set: State transition STATE_CLOUD_CONNECTING --> STATE_RUNNING[0m
2022-05-19T07:58:34.461Z DEBUG modem << * buffer overflow detected *

I could not understand the reason of the buffer overflow here and it's solution. If required, I can send complete Log file.

Parents

0 user73166 over 4 years ago

Hello,

If required, I can send complete Log file.

Yes, please. Also, you can provide as much information as possible, such as MFW version and NCS version.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 user111623 over 4 years ago in reply to user73166

HI, I added some DBG measages to data_get() function in main.c of asset_tracker_v2. I added bms_module to default code and made changes in every file where required. The get_data() function prepares the list of requested data. I observed that when

app_module_event->data_list[count++] = APP_DATA_BMS;

is added to get_data() functon, the buffer_overflow mesasge appears in LTE a shown in attached log file. When,

app_module_event->data_list[count++] = APP_DATA_BMS;

is not there in get_data() function, then there is no buffer_overflow and works well.

The code pf get_data() also is shown here below.

static void data_get(void)
{
	static bool first = true;
	struct app_module_event *app_module_event = new_app_module_event();
	size_t count = 0;

        LOG_DBG(" Main: Entered data_get()");

	/* Set a low sample timeout. If GNSS is requested, the sample timeout will be increased to
	 * accommodate the GNSS timeout.
	 */
	app_module_event->timeout = 1;

	/* Specify which data that is to be included in the transmission. */
	app_module_event->data_list[count++] = APP_DATA_MODEM_DYNAMIC;
        LOG_DBG(" Modem_dyn requested through data_list[]");
	app_module_event->data_list[count++] = APP_DATA_BATTERY;
        LOG_DBG(" APP_BATT requested through data_list[]");
	app_module_event->data_list[count++] = APP_DATA_ENVIRONMENTAL;
        LOG_DBG(" APP_ENV requested through data_list[]");

	if (IS_ENABLED(CONFIG_APP_REQUEST_NEIGHBOR_CELLS_DATA) && !app_cfg.no_data.neighbor_cell) {
		app_module_event->data_list[count++] = APP_DATA_NEIGHBOR_CELLS;
	}

        LOG_DBG(" APP_NBR_CELLS requested through data_list[]");
	/* The reason for having at least 75 seconds sample timeout when
	 * requesting GNSS data is that the GNSS module on the nRF9160 modem will always
	 * search for at least 60 seconds for the first position fix after a reboot. This limit
	 * is enforced in order to give the modem time to perform scheduled downloads of
	 * A-GPS data from the GNSS satellites.
	 *
	 * However, if A-GPS data has been downloaded via the cloud connection and processed
	 * before the initial GNSS search, the actual GNSS timeout set by the application is used.
	 *
	 * Processing A-GPS before requesting GNSS data is enabled by default,
	 * and the time that the application will wait for A-GPS data before including GNSS
	 * in sample requests can be adjusted via the
	 * CONFIG_APP_REQUEST_GNSS_WAIT_FOR_AGPS_THRESHOLD_SEC Kconfig option. If this option is
	 * set to -1, the application module will not request GNSS unless A-GPS data has been
	 * processed.
	 *
	 * If A-GPS data has been processed the sample timeout can be ignored as the
	 * GNSS will most likely time out before the sample timeout expires.
	 *
	 * When GNSS is requested, set the sample timeout to (GNSS timeout + 15 seconds)
	 * to let the GNSS module finish ongoing searches before data is sent to cloud.
	 */

	if (first) {
		if (IS_ENABLED(CONFIG_APP_REQUEST_GNSS_ON_INITIAL_SAMPLING) && request_gnss() &&
		    !app_cfg.no_data.gnss) {
			app_module_event->data_list[count++] = APP_DATA_GNSS;
			app_module_event->timeout = MAX(app_cfg.gnss_timeout + 15, 75);
                        LOG_DBG(" GNSS requested through data_list[]");
		}

		app_module_event->data_list[count++] = APP_DATA_MODEM_STATIC;
		first = false;
	} else {
		if (request_gnss() && !app_cfg.no_data.gnss) {
			app_module_event->data_list[count++] = APP_DATA_GNSS;
			app_module_event->timeout = MAX(app_cfg.gnss_timeout + 15, 75);
                        LOG_DBG(" GNSS requested through data_list[]");
		}
	}

        app_module_event->data_list[count++] = APP_DATA_BMS;
        LOG_DBG(" BMS requested through data_list[]");

	/* Set list count to number of data types passed in app_module_event. */
	app_module_event->count = count;
	app_module_event->type = APP_EVT_DATA_GET;

        LOG_DBG("Ready to launch APP_EVT_DATA_GET Event");
	APP_EVENT_SUBMIT(app_module_event);
        LOG_DBG("Launched APP_EVT_DATA_GET Event");
}

Where overflow occurs, I could not understand ?

Reply

0 user111623 over 4 years ago in reply to user73166

app_module_event->data_list[count++] = APP_DATA_BMS;

is added to get_data() functon, the buffer_overflow mesasge appears in LTE a shown in attached log file. When,

app_module_event->data_list[count++] = APP_DATA_BMS;

is not there in get_data() function, then there is no buffer_overflow and works well.

The code pf get_data() also is shown here below.

static void data_get(void)
{
	static bool first = true;
	struct app_module_event *app_module_event = new_app_module_event();
	size_t count = 0;

        LOG_DBG(" Main: Entered data_get()");

	/* Set a low sample timeout. If GNSS is requested, the sample timeout will be increased to
	 * accommodate the GNSS timeout.
	 */
	app_module_event->timeout = 1;

	/* Specify which data that is to be included in the transmission. */
	app_module_event->data_list[count++] = APP_DATA_MODEM_DYNAMIC;
        LOG_DBG(" Modem_dyn requested through data_list[]");
	app_module_event->data_list[count++] = APP_DATA_BATTERY;
        LOG_DBG(" APP_BATT requested through data_list[]");
	app_module_event->data_list[count++] = APP_DATA_ENVIRONMENTAL;
        LOG_DBG(" APP_ENV requested through data_list[]");

	if (IS_ENABLED(CONFIG_APP_REQUEST_NEIGHBOR_CELLS_DATA) && !app_cfg.no_data.neighbor_cell) {
		app_module_event->data_list[count++] = APP_DATA_NEIGHBOR_CELLS;
	}

        LOG_DBG(" APP_NBR_CELLS requested through data_list[]");
	/* The reason for having at least 75 seconds sample timeout when
	 * requesting GNSS data is that the GNSS module on the nRF9160 modem will always
	 * search for at least 60 seconds for the first position fix after a reboot. This limit
	 * is enforced in order to give the modem time to perform scheduled downloads of
	 * A-GPS data from the GNSS satellites.
	 *
	 * However, if A-GPS data has been downloaded via the cloud connection and processed
	 * before the initial GNSS search, the actual GNSS timeout set by the application is used.
	 *
	 * Processing A-GPS before requesting GNSS data is enabled by default,
	 * and the time that the application will wait for A-GPS data before including GNSS
	 * in sample requests can be adjusted via the
	 * CONFIG_APP_REQUEST_GNSS_WAIT_FOR_AGPS_THRESHOLD_SEC Kconfig option. If this option is
	 * set to -1, the application module will not request GNSS unless A-GPS data has been
	 * processed.
	 *
	 * If A-GPS data has been processed the sample timeout can be ignored as the
	 * GNSS will most likely time out before the sample timeout expires.
	 *
	 * When GNSS is requested, set the sample timeout to (GNSS timeout + 15 seconds)
	 * to let the GNSS module finish ongoing searches before data is sent to cloud.
	 */

	if (first) {
		if (IS_ENABLED(CONFIG_APP_REQUEST_GNSS_ON_INITIAL_SAMPLING) && request_gnss() &&
		    !app_cfg.no_data.gnss) {
			app_module_event->data_list[count++] = APP_DATA_GNSS;
			app_module_event->timeout = MAX(app_cfg.gnss_timeout + 15, 75);
                        LOG_DBG(" GNSS requested through data_list[]");
		}

		app_module_event->data_list[count++] = APP_DATA_MODEM_STATIC;
		first = false;
	} else {
		if (request_gnss() && !app_cfg.no_data.gnss) {
			app_module_event->data_list[count++] = APP_DATA_GNSS;
			app_module_event->timeout = MAX(app_cfg.gnss_timeout + 15, 75);
                        LOG_DBG(" GNSS requested through data_list[]");
		}
	}

        app_module_event->data_list[count++] = APP_DATA_BMS;
        LOG_DBG(" BMS requested through data_list[]");

	/* Set list count to number of data types passed in app_module_event. */
	app_module_event->count = count;
	app_module_event->type = APP_EVT_DATA_GET;

        LOG_DBG("Ready to launch APP_EVT_DATA_GET Event");
	APP_EVENT_SUBMIT(app_module_event);
        LOG_DBG("Launched APP_EVT_DATA_GET Event");
}

Where overflow occurs, I could not understand ?

Children

0 user73166 over 4 years ago in reply to user111623

And what is the MFW version and NCS version?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user111623 over 4 years ago in reply to user73166

I observed that in Main.c file, there is get_data() fn. If custom data request s added to data_list[], then buffer overflow occurs. I commented the request for environmental and added request for custom data in data_list[] then no buffer overflow occurred and custom data was visible and encoded in LTE. So, need to find that is there any limit to max requests to be passed through data_list[] ?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel