High current when using BLE NUS

RE: High current when using BLE NUS

rmakl — Mon, 22 Feb 2021 10:36:46 GMT

Hello Einar,

Thank you very much, it solved the problem. I would have not suspected sprintf at all 😮. I think I should have read the errata in the first place.

Best Regards,

Roland

RE: High current when using BLE NUS

Einar Thorsrud — Mon, 22 Feb 2021 08:22:36 GMT

Hi Roland,

This issue is not related to NUS. You can see that by modifying your sensor_list_timeout_evt_handler() function to just send dummy data - in that case there is no increase in current consumption.

The actual problem here is triggered by the sprintf call, which uses the FPU (for doing correct rounding of the float value). However, you have not enabled the workaround for erratum 87. The fix is to enable the workaround by setting NRF_PWR_MGMT_CONFIG_FPU_SUPPORT_ENABLED in sdk_config.h to 1.

Einar

RE: High current when using BLE NUS

rmakl — Fri, 19 Feb 2021 15:56:14 GMT

Here is the project files. It resides in "nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8\examples\multiprotocol\ble_thread\"

RE: High current when using BLE NUS

Einar Thorsrud — Tue, 16 Feb 2021 14:37:40 GMT

Hi,

Can you share the code you use to reproduce this on a DK so that I can test on my side?

RE: High current when using BLE NUS

rmakl — Mon, 15 Feb 2021 18:45:32 GMT

Hi Einar,

I was able get back to my original problem. I replicated the issue on an nRF52840-DK. Same phenomenon: CPU usage goes up and stays there for the next reset.

RE: High current when using BLE NUS

Einar Thorsrud — Fri, 12 Feb 2021 13:10:50 GMT

Hi,

That is up to you 🙂

RE: High current when using BLE NUS

rmakl — Fri, 12 Feb 2021 11:57:42 GMT

Hi Einar,

Some other problems arised during development, for a couple of days I won't be able to investigate the original issue on the DK.

Should I close this post and reopen sometime later, or leave it as it is?

RE: High current when using BLE NUS

Einar Thorsrud — Wed, 10 Feb 2021 14:28:43 GMT

I do not have an explanation for what you are seeing. A shot in the dark could be a potential buffer overflow or stack overflow that could cause the loop in the code snippet to keep iterating for a long time. But you should see other side effects then as well.

Are you able to reproduce this on a DK? If so, can you share the code with me so that I can test on my side?

RE: High current when using BLE NUS

rmakl — Wed, 10 Feb 2021 12:09:56 GMT

I edited made some modifications:

#define NRF_SDH_BLE_GAP_DATA_LENGTH 251

and

/**
 * @brief 
 * 
 * @param p_context 
 */
void sensor_list_timeout_evt_handler(void *p_context)
{
	ret_code_t err_code;
	uint16_t length = 0;
	char str[512];
	size_t ptr = 0;

	if (m_conn_handle == BLE_CONN_HANDLE_INVALID || m_nus_connected == false) {
		return;
	}

	str[0] = '#';
	ptr = 1;
	for (int i = 0; i < ARRAY_SIZE(m_sim_datapoints); i++) {
		if (i > 0) {
			str[ptr] = ';';
			ptr++;
		}

		ptr += sprintf(&str[ptr], "%s,%d,%2.2f",
			m_sim_datapoints[i].name,
			m_sim_datapoints[i].enabled == true ? 1 : 0,
			m_sim_datapoints[i].values[m_sim_datapoints[i].index]);
	}

	length = ptr;
	str[ptr] = '\0';
	NRF_LOG_INFO("strlen: %d", length);

	err_code = ble_nus_data_send(&m_nus, str, &length, m_conn_handle);
	if ((err_code != NRF_ERROR_INVALID_STATE) &&
		(err_code != NRF_ERROR_RESOURCES) &&
		(err_code != NRF_ERROR_NOT_FOUND))
	{
		APP_ERROR_CHECK(err_code);
	}

	/*
	length = 5;
	err_code = ble_nus_data_send(&m_nus, "Hello", &length, m_conn_handle);
	if ((err_code != NRF_ERROR_INVALID_STATE) &&
		(err_code != NRF_ERROR_RESOURCES) &&
		(err_code != NRF_ERROR_NOT_FOUND))
	{
		//APP_ERROR_CHECK(err_code);
	}
	*/
}

I print out the string length.

Here is the RTT log:

<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<info> pwr_mgmt: CPU Usage: 0%
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 158 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<error> nrf_ble_gatt: sd_ble_gap_data_length_update() (request) on connection 0x0 returned NRF_ERROR_RESOURCES.
<error> nrf_ble_gatt: The requested TX/RX packet length is too long by 89/89 octets.
<debug> nrf_ble_gatt: ATT MTU updated to 158 bytes on connection 0x0 (response).
<info> pwr_mgmt: CPU Usage: 0%
<debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 123 bytes.
<debug> nrf_ble_gatt: Updating data length to 123 on connection 0x0.
<debug> nrf_ble_gatt: Data length updated to 123 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 123
<debug> nrf_ble_gatt: max_tx_octets: 123
<debug> nrf_ble_gatt: max_rx_time: 1096
<debug> nrf_ble_gatt: max_tx_time: 1096
<info> app: BLE NUS connected
<info> pwr_mgmt: CPU Usage: 0%
<info> app: strlen: 63
<info> pwr_mgmt: CPU Usage: 43%
<info> app: strlen: 63
<info> pwr_mgmt: CPU Usage: 58%
<info> app: strlen: 63
<info> pwr_mgmt: CPU Usage: 58%
<info> app: strlen: 63
<info> pwr_mgmt: CPU Usage: 57%
<info> app: strlen: 63
<info> pwr_mgmt: CPU Usage: 57%
<info> app: strlen: 63
<info> pwr_mgmt: CPU Usage: 57%
<info> app: strlen: 63
<info> pwr_mgmt: CPU Usage: 57%
<info> app: strlen: 63

So the stack negotiated a length of 123 and I want to send 63. Still, the problem persists.

RE: High current when using BLE NUS

rmakl — Wed, 10 Feb 2021 11:54:02 GMT

Hi,

That one, I totally forgot about. I commented out a few weeks ago, because I tried to send data before NUS connection is made. That's why I added later the m_nus_connected flag to check.
Now, I de-commented and debugged the code, but no error is reported by APP_ERROR_CHECK. The elevated current persists.

RE: High current when using BLE NUS

Einar Thorsrud — Wed, 10 Feb 2021 11:28:16 GMT

Hi,

I see you commented out the error check after calling ble_nus_data_send(). Why is that? Did you get an error there? If so, which error code?

RE: High current when using BLE NUS

rmakl — Wed, 10 Feb 2021 11:15:56 GMT

Hi Einar,

I think I narrowed down the problem to this code section:

/**
 * @brief 
 * 
 * @param p_context 
 */
void sensor_list_timeout_evt_handler(void *p_context)
{
	ret_code_t err_code;
	uint16_t length = 0;
	char str[512];
	size_t ptr = 0;

	if (m_conn_handle == BLE_CONN_HANDLE_INVALID || m_nus_connected == false) {
		return;
	}

	str[0] = '#';
	ptr = 1;
	for (int i = 0; i < ARRAY_SIZE(m_sim_datapoints); i++) {
		if (i > 0) {
			str[ptr] = ';';
			ptr++;
		}

		ptr += sprintf(&str[ptr], "%s,%d,%2.2f",
			m_sim_datapoints[i].name,
			m_sim_datapoints[i].enabled == true ? 1 : 0,
			m_sim_datapoints[i].values[m_sim_datapoints[i].index]);
	}

	length = ptr;
	str[ptr] = '\0';
	//NRF_LOG_INFO("sensor list: %s", str);

	err_code = ble_nus_data_send(&m_nus, str, &length, m_conn_handle);
	if ((err_code != NRF_ERROR_INVALID_STATE) &&
		(err_code != NRF_ERROR_RESOURCES) &&
		(err_code != NRF_ERROR_NOT_FOUND))
	{
		//APP_ERROR_CHECK(err_code);
	}

	/*
	length = 5;
	err_code = ble_nus_data_send(&m_nus, "Hello", &length, m_conn_handle);
	if ((err_code != NRF_ERROR_INVALID_STATE) &&
		(err_code != NRF_ERROR_RESOURCES) &&
		(err_code != NRF_ERROR_NOT_FOUND))
	{
		//APP_ERROR_CHECK(err_code);
	}
	*/
}

This function is called periodically by an app_timer every 1000ms, from the start of the app. If I send only "Hello", it works fine and consumption is not increased. If I send the originally intended content, it sends successfully, but consumption skyrockets.

Is it something to do with:

 0> <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 123 bytes.
 0> <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
 0> <debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
 0> <debug> nrf_ble_gatt: max_rx_octets: 27
 0> <debug> nrf_ble_gatt: max_tx_octets: 27
 0> <debug> nrf_ble_gatt: max_rx_time: 1096
 0> <debug> nrf_ble_gatt: max_tx_time: 1096

? Should these transfer sizes be increased to fit my needs?

RE: High current when using BLE NUS

Einar Thorsrud — Wed, 10 Feb 2021 10:12:24 GMT

Hi Rolan,

I do not immediately see how the NUS service implementation itself could cause this. The large increase in CPU usage is very interesting, though. Have you been able to see which part of your code is being run during this time? Perhaps just testing without optimization and pausing execution from a debugger could give some interesting observations on where time is being spent? If that does not provide any clues, can you share your code so that I can take a look?

Einar

RE: High current when using BLE NUS

Vojislav — Wed, 10 Feb 2021 09:44:53 GMT

Yes, I agree, hope that Nordic can help. Good luck

RE: High current when using BLE NUS

rmakl — Wed, 10 Feb 2021 09:42:44 GMT

RTT might add some cosumption, but when I'm not using NUS, my IDLE current can go <10uA, so the 7mA increase is nothing related to that.
I'm using a custom hardware, but then again, without NUS, I have no problem with consumption, BLE generally. I'm even using DFU and other services, all of them works fine (even those, which have NOTIFY attributes). Only the NUS is giving me trouble, so this purely a software issue.

RE: High current when using BLE NUS

Vojislav — Wed, 10 Feb 2021 09:38:27 GMT

I understand. I do not know your hardware configuration so just be aware that having programmer pins connected can cause an increase in power consumption.
Are you using NCS or nRF5SDK?
Also, RTT is adding to power consumption, so turning that off as well will help.

RE: High current when using BLE NUS

rmakl — Wed, 10 Feb 2021 09:33:45 GMT

Hi Vojislav,

I forgot to mention, that I'm not using UART, or any other peripheral. I would like to use NUS for raw data transfer. As for the programmer, I measure the elevated consumption after a power reset, so the nRF is not in debugger mode. Also, the project is compiled in 'Release' config and has no other problem whatsoever.

BR,

Roland

RE: High current when using BLE NUS

Vojislav — Wed, 10 Feb 2021 09:30:29 GMT

As I know you need to disable UART and disconnect the programmer so you get the real power consumption for the NUS example