SDK V12.2.0 sleep mode issue

[pimvds]

We have written an application based on SDK V12.2.0 using S132_V3.1.0 for the nRF52832 and have been dealing with an issue where the module constantly enters a hardfault. Unfortunately debugging is not an option as the problem seems to be resolved when using a debugger. I've stripped down our application to simply start scanning for peripherals and go to sleep in the main loop using sd_app_evt_wait, yet the issue persists.

The issue appears to be related to the scan interval as the module resets at exactly the scan interval time. Furthermore increasing/decreasing the scan interval changes the time after which the module goes through reset.

I've noticed that removing sd_app_evt_wait from code or replacing the call with __WFE resolves the issue. As far as my understanding goes sd_app_evt_wait and __WFE should have the exact same behavior. What is the difference between the 2 calls?

Best regards,

[Simonr]

Hi

Due to the Easter holiday you will have to expect a delay in replies, sorry for the inconvenience!

Could you try adding an app_error_check, to see what values the interval timer function and sd_app_evt_wait returns? Only reason I see to why sd_app_evt_wait should cause a hard fault would be that the SoftDevice isn't initialized properly. How do you initialize the SoftDevice?

Sidenote: SDK12.2 and S132_v3.1 are old, and you should consider updating both to a more recent update.

Best regards and happy Easter,

Simon

[pimvds]

Hello Simon,

Thank you for the reply. Let me clarify that it is not an interval timer we're using, but it is the interval on which the softdevice repeats a scan as defined by the scan parameters handed to the softdevice when starting scanning for peripherals.

See the following segment where we initialize the softdevice:

static void ble_stack_init(void)
{
    uint32_t err_code = NRF_SUCCESS;
    nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC;
    
	/*Disable softdevice to delete any registered services,
    only a limited amount of services can be registered*/
    err_code = sd_softdevice_disable();
    APP_ERROR_CHECK(err_code);
    
	//Initialize the SoftDevice handler module.
    SOFTDEVICE_HANDLER_INIT(&clock_lf_cfg, NULL);
    ble_enable_params_t ble_enable_params;

    err_code = softdevice_enable_get_default_config(CENTRAL_LINK_COUNT,
													PERIPHERAL_LINK_COUNT,
													&ble_enable_params);
    APP_ERROR_CHECK(err_code);
    
	// Use the max config: 8 central, 0 periph, 10 VS UUID
    ble_enable_params.common_enable_params.vs_uuid_count = 10;
	
	//Check the ram settings against the used number of links
    CHECK_RAM_START_ADDR(CENTRAL_LINK_COUNT,PERIPHERAL_LINK_COUNT);
    
	//Enable BLE stack.
#if (NRF_SD_BLE_API_VERSION == 3)
    ble_enable_params.gatt_enable_params.att_mtu = NRF_BLE_MAX_MTU_SIZE;
#endif
    err_code = softdevice_enable(&ble_enable_params);
    APP_ERROR_CHECK(err_code);
    
	//Register with the SoftDevice handler module for BLE events.
    err_code = softdevice_ble_evt_handler_set(ble_evt_dispatch);
    APP_ERROR_CHECK(err_code);
	
	// Register with the SoftDevice handler module for BLE events.
    err_code = softdevice_sys_evt_handler_set(sys_evt_dispatch);
    APP_ERROR_CHECK(err_code);
}

As for the app_error_check, we do include that with our call to sd_app_evt_wait. The problem however occurs before sd_app_evt_wait returns, either in interrupt context or within the softdevice itself.

With kind regards,

Pim

[Simonr]

Hi

I talked to my colleagues on the matter, and there has been an issue in very old SDKs where MWU violations won't be handled while an application is in a critical section, and causes this hard fault.

The fix should be to replace __NRF_NVIC_SD_IRQS_1 with the following in nrf_nvic.h, and recompile the application:

#define __NRF_NVIC_SD_IRQS_1 ((uint32_t)(1U << (MWU_IRQn - 32)))

This will cause the MWU handler to not be masked by the critical section, and thus be run at the correct time.

Best regards,

Simon