SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

MartinBL — Wed, 24 Jan 2018 13:10:46 GMT

Hi,

I have looked closer at your code and you are right of course. The timers are run from main context since you are using a scheduler. However, several places in your code you have these lines of code:

while(pstorage_wait_flag)
{
    power_manage();	
}

And I think you are suspicious about this yourself since at one point you have this comment

// if power_manage() function is replaced by  app_sched_execute() then the program passes the timer

This is probably the core of the matter. These while loops effectively act as deadlocks because you are waiting for an event that sets pstorage_wait_flag to false, but you never allow the scheduler to process the event. In other words, the system might trigger an interrupt when your flash operation is completed, but unless you call app_sched_execute() the event is never processed and the flag never cleared.

What you can try to do is to add app_sched_execute() to your while loops like this:

while(pstorage_wait_flag)
{
    app_sched_execute();
    power_manage();	
}

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

samo — Sun, 21 Jan 2018 15:36:28 GMT

I agree with your conclusion if I use app_timer without a scheduler. If you will look carefully at my code you will see that app_timer uses a scheduler and thus app_timer is not executed in interrupt context. If I know correctly the problem with interrupt context can arise only if the app_timer does not use a scheduler. The attached code is the simplified version of the original code in which the pstorage functions are called a few times. Due to this fact, it is good to track a flag.

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

MartinBL — Wed, 17 Jan 2018 13:58:24 GMT

This looks very similar to this:

devzone.nordicsemi.com/.../

and this:

devzone.nordicsemi.com/.../

It seems like you are starting the pstorage operation from within an interrupt context (app_timer) and then wait in a while loop in that very same interrupt for another interrupt to happen (example_cb_handler). But example_cb_handler() never gets called and your flag never gets set.

Do you even need the while loop in your timer handler?

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

control — Wed, 10 Jan 2018 21:45:06 GMT

I added the program to my first post, in which I implemented a similar situation which happened in my original code. I use one time called m_mass_battery_timer_id and it is executed 2500ms after power on. When the timer is executed four bytes are stored in flash but the program does not pass through the while loop where the power_manage() is located. If I replace power_manage() function with app_sched_execute() then the program works fine. the program is located in the pca 10028 file. I will be very pleased with any feedback.

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

control — Tue, 09 Jan 2018 22:42:23 GMT

Hi Martin,

I use app_timer library and APP_TIMER_APPSH_INIT(APP_TIMER_PRESCALER, APP_TIMER_OP_QUEUE_SIZE, true) function for the timer scheduler.Tomorrow I will try to do additional experiments and I will reply to your second question as fast as possible

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

MartinBL — Mon, 08 Jan 2018 13:10:40 GMT

Hi,

What kind of timers are you using? The app_timer library? With scheduler?
Can you confirm that your code is actually looping in this standard power_manage function

static void power_manage(void)
{
    uint32_t err_code = sd_app_evt_wait();
    APP_ERROR_CHECK(err_code);
}

And that no other code is executed? If this is an issue with interrupt priorities and the softdevice it seems strange that you don't get hard faults.

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

control — Sat, 30 Dec 2017 13:15:41 GMT

Hi Martin,

I think that I found out the problem. I will be really appreciated if you can confirm my assumption. In my code, the times are executed in the main loop because I am using the scheduler. The softdevice is also executed in the main loop which means that BLE event does not have higher priority compared to the application timers (where pstorage_update function and subsequently power_manage() function are called). Both of them are loaded in the queue according to schedule rule. Because BLE event and timers are executed with the same priority, the code waits for a p_storage flag longer than the critical interval for execution of BLE event. Due to this fact, I guess that BLE event cannot be executed just in time. I use SDK 10. If my assumption is not true then I will upload the code.

RE: SOFTDEVICE_HANDLER_APPSH_INIT + pstorage

MartinBL — Thu, 28 Dec 2017 10:29:31 GMT

Hi,

What SDK and softdevice versions are you using?
Do you mind uploading your code? (You can edit your first questions and attach files)
power_manage() is located in the main while forever loop in main() right? What do you mean stuck? The code is supposed to loop forever and wake up on system and BLE events.