RE: Asset_tracker V2 run time buffer overflow in LTE

Sigurd — Fri, 24 Jun 2022 08:46:28 GMT

Hi,

Håkon is on vacation. Are you still having issues with this?

[quote user="mexco"]If custom data request s added to data_list[],[/quote]

Can you show the modifications you have made? Did you add a new new type toapp_module_data_type ?

RE: Asset_tracker V2 run time buffer overflow in LTE

mexco — Tue, 07 Jun 2022 11:25:34 GMT

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[] ?

RE: Asset_tracker V2 run time buffer overflow in LTE

Hakon — Tue, 07 Jun 2022 11:15:23 GMT

And what is the MFW version and NCS version?

RE: Asset_tracker V2 run time buffer overflow in LTE

mexco — Thu, 26 May 2022 10:04:00 GMT

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 ?

devzone.nordicsemi.com/.../4428.log.txt

RE: Asset_tracker V2 run time buffer overflow in LTE

Hakon — Fri, 20 May 2022 13:58:00 GMT

Hello,

[quote user=""]If required, I can send complete Log file.[/quote]

Yes, please. Also, you can provide as much information as possible, such as MFW version and NCS version.