How to unblock the CPU during connection intervals with S110 v7.1.0?

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

hawk — Tue, 05 Jul 2016 05:35:59 GMT

I use the old SDK 5.2.0 and S110 6.0.0; I use the app timer to count sec,min,hour(make one time clock), and found that the second of mine is less after i set an initial sec/min/hour. how to avoid delay the app timer of old SDK.

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Nikolaus Wittenstein — Fri, 30 Oct 2015 14:09:36 GMT

Is this still required in SDK 9?

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Milan — Thu, 25 Jun 2015 10:54:59 GMT

I use SDK v8.0.0 and latest softdevice s110. Do I need to do this in my code for performance improvements?

C:\Program Files (x86)\Nordic Semiconductor\nrf51\bin>nrfjprog --memrd 0x1000005
C --n 4
0x1000005C: FFFF0086                              |....|

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Hung Bui — Fri, 05 Jun 2015 06:27:25 GMT

@Lucas: It's only safe to unblock the CPU on XLR3. On chip version 2 (QFAAG0) there are some PANs that don't allow CPU to be concurrent when the softdevice is active. Please have a look at the release note on S110 v8.0 at Changes section.

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Lucas — Mon, 15 Dec 2014 00:36:57 GMT

I attempted this on two chips:

nRF51822-QFAAG0

nRF51822-QFACA1

In both cases I saw performance increases. Similar to what you showed above it isn't perfect. The CPU does block occasionally regardless of if CPU blocking is disabled. I was under the impression that this would only improve performance for hardware revision 3. I guess it works for hardware revision 2 as well? Is this expected behavior?

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Lucas — Fri, 12 Dec 2014 01:14:47 GMT

Is it also required that this be on latest hardware revision?

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Hung Bui — Fri, 07 Nov 2014 12:44:22 GMT

@Jason: It's an design issue that we don't have enough memory bandwidth to handle CPU, encryption block, etc at the same time. And we have to block CPU to have enough memory bandwidth. But it's fixed now.

To use the new feature, you would need to use either SDK v7.0 or if you want to use SDK v6.1 you need to update the API header files from S110 v7.1

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Jason — Mon, 03 Nov 2014 15:55:46 GMT

I can not found the "common_opt.radio_cpu_mutex.enable" in SDK 6.1...

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Jason — Mon, 03 Nov 2014 15:31:21 GMT

Why nRF51 need to block the CPU to wait for Radio ?

RE: How to unblock the CPU during connection intervals with S110 v7.1.0?

Håkon Alseth — Thu, 30 Oct 2014 09:18:33 GMT

Hi,

To disable the CPU blocking with S110 v7.1.0 or newer, you will have to use this API call:

/**@brief Set a BLE option.
 *
 * @details This call allows the application to set the value of an option.
 *
 * @param[in] opt_id Option ID.
 * @param[in] p_opt Pointer to a ble_opt_t structure containing the option value.
 *
 * @retval ::NRF_SUCCESS  Option set successfully.
 * @retval ::NRF_ERROR_INVALID_ADDR Invalid pointer supplied.
 * @retval ::BLE_ERROR_INVALID_CONN_HANDLE Invalid Connection Handle.
 * @retval ::NRF_ERROR_INVALID_PARAM Invalid parameter(s) supplied, check parameter limits and constraints.
 * @retval ::NRF_ERROR_INVALID_STATE Unable to set the parameter at this time.
 * @retval ::NRF_ERROR_BUSY The stack is busy or the previous procedure has not completed.
 */
SVCALL(SD_BLE_OPT_SET, uint32_t, sd_ble_opt_set(uint32_t opt_id, ble_opt_t const *p_opt));

The options available as of now is only one, which is the mutual exclusion of radio activity and CPU usage (read block/unblock CPU in connection interval):

/**@brief Common Option IDs.
 * IDs that uniquely identify a common option.
 */
enum BLE_COMMON_OPTS
{
  BLE_COMMON_OPT_RADIO_CPU_MUTEX = BLE_OPT_BASE    /**< Radio CPU mutex option. @ref ble_common_opt_radio_cpu_mutex_t */
};

And here's a small snippet on how to disable the CPU blocking:

uint32_t opt_id = BLE_COMMON_OPT_RADIO_CPU_MUTEX;
ble_opt_t cpu_blocking_enabled;
cpu_blocking_enabled.common_opt.radio_cpu_mutex.enable = 0;
ble_stack_init();
err_code = sd_ble_opt_set(opt_id, &cpu_blocking_enabled);
/* continue init */

Cheers, Håkon

===============================

Additional images showing how the CPU availability is improved when advertising (same applies when in connection):

Before (CPU blocked during radio active):

After (Concurrent CPU when radio is active):

Black part showing the latency when CPU is blocked. [ADDED]: On the second trace, the CPU is still blocked at some periods because it's the softdevice active and preparing the radio packet, no the radio itself.

Cheers,

Hung Bui