This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SDK V12.2.0 sleep mode issue

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,

Parents
  • 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

Reply
  • 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

Children
No Data
Related