Watch dog and while statement

[Hansome]

Based on nRF5_SDK_15.3.0_59ac345 at NRF52810 development board,
1. Enable the watchdog with reload value = 2000, and feed it per 1000ms by app_timer
2. Initialize the FDS and wait its ready

static void _on_fds_event(fds_evt_t const* evt)
{

switch(evt->id){

case FDS_EVT_INIT:
if(evt->result == FDS_SUCCESS){
_fds_ready = true;
}
break;

case FDS_EVT_WRITE:
break;

case FDS_EVT_UPDATE:
break;

default:
break;

}

}

_fds_ready = false;
fds_register(_on_fds_event);
if(fds_init() == NRF_SUCCESS){
while(!_fds_ready){};
}

Each time the power is turned on, a watchdog reset is triggered. The reason is while(!_fds_ready){};
It looks like the while statement affecting the watchdog app_timer.
How can I solve this problem? Thanks!

[Edvin]

Hi  Hansome,

It sounds like the app_timer interrupt is not allowed to access the CPU until you are done with your FDS events. They are probably running on the same interrupt priority.

I don't know whether you are using the softdevice, but you can take a look at the interrupt priority levels for the nRF52810 here.

Try to increase the interrupt priority (lower number = higher priority) on the app_timer.

Look for APP_TIMER_CONFIG_IRQ_PRIORITY in sdk_config.h. Try to set it to 3, and see if that helps.

Best regards,

Edvin

[Hansome]

// <o> APP_TIMER_CONFIG_IRQ_PRIORITY  - Interrupt priority
 

// <i> Priorities 0,2 (nRF51) and 0,1,4,5 (nRF52) are reserved for SoftDevice
// <0=> 0 (highest) 
// <1=> 1 
// <2=> 2 
// <3=> 3 
// <4=> 4 
// <5=> 5 
// <6=> 6 
// <7=> 7 

#ifndef APP_TIMER_CONFIG_IRQ_PRIORITY
#define APP_TIMER_CONFIG_IRQ_PRIORITY 0
#endif

There has been no improvement with the value=0 or value=1 or value=5.

[Hansome]

Only setting APP_TIMER_CONFIG_IRQ_PRIORITY to 2 can works, why?

[Edvin]

I don't know if you actually opened the link from my previous reply.

levels 0, 1 and 4 are reserved for the softdevice. 

 

Edvin said:

I don't know whether you are using the softdevice

 Do you use the softdevice?

 

Edvin said:

Try to set it to 3, and see if that helps.

 so you tried 0, 1 and 5. Did you try 3?

Check out the link, and pick a value that is higher than the softdevice's "none-time-critical processing" and "SoftDevice memory protection" So you can choose either 2 or 3. If 2 works, then it is fine.

[Edvin]

Hi Hansome,

I gave this some more thought after consulting with my colleague who handles this ticket.

Maybe you shouldn't set the app_timer's priority so high. It may result in some unexpected behavior because other threads that possibly needs access faster can't get it.

I suggest that you bump the priority on app_timer back to the default value (6?) and then rather skip the while(!fds_ready){}.

I agree that sometimes you need to wait for _fds_ready, but I suggest that you do this update in your main context instead of in the FDS interrupt.