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

Bus Fault after calling __get_FPSCR in FreeRTOS configPRE_SLEEP_PROCESSING(x)

I'm trying to set up a project with SDK 16.0.0 using FreeRTOS with the softdevice.  The device will be battery powered and therefore power management capabilities are required.

My freeRTOSConfig.h is the same as in the ble_app_hrs_freertos_pca10040_s132 with the following additions:

#if ( __FPU_PRESENT)
#define PWR_MGMT_FPU_SLEEP_PREPARE() pwr_mgmt_fpu_sleep_prepare()
extern void pwr_mgmt_fpu_sleep_prepare(void);
#else
#define PWR_MGMT_FPU_SLEEP_PREPARE()
#endif // NRF_PWR_MGMT_CONFIG_FPU_SUPPORT_ENABLED

#define configPRE_SLEEP_PROCESSING(x) PWR_MGMT_FPU_SLEEP_PREPARE()

#define configSUPPORT_STATIC_ALLOCATION

Based on this thread I tried to add pwr_mgmt_fpu_sleep_prepare in main.c, however my code gets a busfault any time I use the __get_FPSCR() or __set_FPSCR() macro.

My application works as expected except not sleeping when I comment out the FPSCR macros.

When I uncomment the macro's the busfault breakpoint triggers and the PC is stopped at address 0xA60.

Do I need to implement this sleep prepare step?

Why do these FPSCR macro's cause a bus fault?

Given:

1) I'm not even using the FPU.

2) This example only performs some I2C operations once per second

3) I have RTC2 enabled and operating at 32KHz with only overflow interrupt enabled ( for tracking time independent from freeRTOS )

4) I have an idle task hook that does NRF_LOG_FLUSH with NRF_LOG_ENABLED

Then will it be reasonable to expect the sd_app_evt_wait() call to sleep for some amount of time?  It seems at the moment it will never sleep despite every task being blocked/suspended.

Parents
  • Hi Anthony,

    my reply and its thread got deleted by  mistake. Sorry about that.

    What you said is correct, sorry for not seeing that the first time. The vApplicationIdleHook was being called too frequent to keep the logger thread active most of the time and your suggestions actually reduced the power consumption when logs are enabled.

    Without your change, the vApplicationIdleHook was unblocking the task that in turn tells the scheduler to abort the idle sequence. I thought that the scheduler will run the logger_task and resume the idle operation but then it would become a chain of block and unblock and the control never reaches to sleep.

    SDK example without changes and logs enabled.

    Anthony's change, the power consumption goes down

    Attaching the files with changes suggested by Anthony.

    Thank you for your work Anthony.

  • Thanks for following up on this!  I hope the improvements to the example will make it into the next SDK release!

  • I will personally make this change and push to the repo this week to avoid delay 

Reply Children