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

Button Causing CPU freeze/SystemOff

I have this odd issue which creeps up in field testing. Upon a button push the board goes immediately to System Off. 99.99% of the time Button pushes are handled normally, but in these rare cases while connected to a phone, the device will go straight to System Off upon a button push. Using SDK 6.1, S110 7.1

I was worried this could be happening because of one of the following reasons:

  • Stack, app_timer and app_button all use the Scheduler. Perhaps this is a corner case that occurs when the Scheduler Queue is full?
  • Perhaps the 32.768kHz crystal has drifted causing an assert according to DRGN-5153
  • A fault in the GPIOTE within the app_button is hardfaulting?
  • Noticed that in my on_sys_evt(uint32_t sys_evt) there is a system_off_mode_enter(); call on an NRF_EVT_FLASH_OPERATION_SUCCESS or NRF_EVT_FLASH_OPERATION_ERROR. Though it is unlikely to get here as I don't use pstorage anywhere in my application.

These are the only ways I can see this Button Freeze issue is occuring. I just thought I'd post this in case anyone else had seen this issue before. I read a similar post, which found a loop was blocking the Stack. I've verified none of my IRQ or scheduler handlers have any blocking.

Thanks guys,

DC

  • Hi Dave, Is this behavior reproducable even in debug mode? If you do not use pstorage anywhere, why dont you just delete all its code, escpecially the one calling system_off_enter. DRGN-5153, might not be the cause for this, because you say this happens only when button is pressed. This to me does not look anything softdevice related but seems like your application or button_library could be culprits.

    I did not understand fully your scheduler analysis, if the queue is full, it wont allow to add anything in the queue and hence the call should return with error. I would like to see some code and possible way to reproduce this error to help you further.

  • Hi Aryan, you are correct. I added a while(1) loop with LEDs to catch if it ever reached the Flash Error system_off code. However we again saw the fault and it didn't reach the while(1). So the fault lies somewhere else.

    How our button section works is on a Button push, I start a 1second Repeating timer. At each timeout I use app_sched_event_put() to scheduler events according to how long the button as been held.

    Looking into the differences between app_timer.c in SDK6.1 and later versions I see the use of rtc1_stop() which is not used in later version. I found if execute the following (psuedo) code on a Button Push Handler I can re-create the issue:

    button_handler()
    {
        if(PUSHED)
    {
    rtc1_stop();     //Added to simulate app_timer.c  error condition of SDK 6.1
    rtc1_start();    //to restart RTC1
    
    stop_button_hold_timer();
    start_button_hold_timer();
    }
    }
    
  • The above code will cause my Button hold state machine to rapidly execute. Normally the Button must be hold for 5seconds before the System_off event it pushed. However adding the above rtc1 code, causes the System off event to be executed immediately after the Button push.

    This tells me that during normal operation, somehow the SDK gets into a scenario where is executes rtc1_stop(); and rtc1_start();, which immediately seems to halt my system on Button pushes.

  • I do not know what your button hold timers are doing, can you upload your project and I can have a look at it.

  • @Dave_coupling

    Were you able to fix this issue?

    I am having the same problem with my timers suddenly executing instantly (devzone.nordicsemi.com/.../).

    I added the same rtc1_stop()/rtc_start() code into my button handler and can reliably re-create the problem too.

Related