modem_info_short_get fails

[Andrea]

Same as Case ID: 234629  .

Calling modem_info_short_get for the parameters MODEM_INFO_MCC and MODEM_INFO_MNC fail.

I suspect the problem is in code. Tracing the MCC call shows that the call makes the correct AT query to the modem. However, the parameter returned is (rightly) a string. However the value expected for that parameter is a short so the call fails. Trying to call modem_info_string_get fails because the value is typed as a short in the parameter array.

This new ticket is to confirm that it fails on NCS 1.1.0 with modem firmware 1.1.0.

[Andrea]

The EINVAL is returned from lib/modem_info/modem_info.c:422.

err = at_params_short_get(&m_param_list,
modem_data[info]->param_index,
buf);

Look at lib/at_cmd_parser/at_params.c:264

if (param->type != AT_PARAM_TYPE_NUM_SHORT) {
		return -EINVAL;
	}

The code looks for a short but finds a string and returns EINVAL. When I call modem_info_short_get(MODEM_INFO_MCC, &mcc) param->type is 3.

To confirm this is the problem, if I change lib/modem_info/modem_info.c:173 from:

.data_type = AT_PARAM_TYPE_NUM_SHORT,

to

.data_type = AT_PARAM_TYPE_STRING,

it works.

This is consistent with AT commands reference:

infocenter.nordicsemi.com/.../cops_read.html

[Øyvind]

Thanks for pointing this out to us. I have now forwarded this to our NCS team, and they confirm the issue. 

Have a great day!

[Jan Tore Guggedal]

Hi Andrea,

Thanks for reporting the issue.

If I understand correctly what you're trying to achieve, it seems you would rather read out MODEM_INFO_OPERATOR instead and get the concatenated MCC and MNC string that you refer to in the AT command reference. Changing .data_type to AT_PARAM_TYPE_STRING would read out the same operator string for both MODEM_INFO_OPERATOR, MODEM_INFO_MCC, and MODEM_INFO_MNC.

To have MCC and MNC as numeric values, some more parsing has to be done. This is actually done under the hood if you call modem_info_params_get(). Then the .mcc.value and .mnc.value fields of the modem_param_info struct are populated correctly with numeric values. I know, it's inconvenient to have to use this giant struct instead of reading it out directly, but unfortunately that's the only way to do it in today's codebase.

Best regards,
Jan Tore