Button 1-2 resets nRF51-DK

[Hieu]

I am trying to set up a GPIO interrupt, and found that whenever Button 1 is pressed, if Button 1 or 2 is pressed later, the app will reset. This is even if there is any other buttons are pressed in between the two button presses. For example:

• Pressing 1-1 resets the app
• Pressing 1-2 resets the app
• Pressing 1-3-4-3-3-4-2 resets the app

And I am not even setting GPIO button interrupt on Button 1 or 2. I am setting it up on Button 4. The application I am trying to add the button features to is based off the ble_app_uart example. Is this some kind of backdoor implemented by default in the nRF51-DK, or in the ble_app_uart example?

[RK]

no it's not a back door - you have a bug - I'd start in the app error handler because that's 99.99% of the time where errors are caught and the default behaviour is to reset the chip.

[Hieu]

@rols: I have set a break point in app_error_handler() in app_error.c. However, when the system reset, the break point is never reached. As a matter of fact, that break point is greyed out when I enter debug mode.

Another thing I tried to do is add the preprocessor DEBUG. This supposedly change the app_error_handler() behavior to trapping the application in an infinite loop. However, when I pressed the button as described, the app still reset. Do you have any other guesses what might be happening?

[Hieu]

Also to add, the above tests are all done with all of my GPIOTE related code removed.

[RK]

if the break point is greyed out then that probably indicates that's not the error handler compiled into your application. If that's not the one compiled in, defining DEBUG won't help. So that's the first thing to figure out, what app error handler is called from the app error check macro. Find it, put a breakpoint in it and force an app error check until you can hit your own debug point.

There are few other things which would cause a chip reset. A bad error would go to the hardfault handler (but you should go see what that one does too, perhaps that also resets the chip), pulling the reset line low would do it.

[Hieu]

I checked APP_ERROR_CHECK() macro. It runs the APP_ERROR_HANDLER() macro which in turns runs a call of app_error_handler().

Also a project wide search of nvic_systemreset shows that the only call in the entire project is in app_error_handler()