Button 1-2 resets nRF51-DK

RE: Button 1-2 resets nRF51-DK

Hieu — Wed, 04 May 2016 08:00:03 GMT

Thanks to the tips from @RK, I found that this is a behavior of the BSP Button Module, which is documented here: infocenter.nordicsemi.com/index.jsp

RE: Button 1-2 resets nRF51-DK

Hieu — Wed, 04 May 2016 07:59:06 GMT

Couldn't find it mentioned in the UART Example page, but I finally found the behavior documented here: infocenter.nordicsemi.com/index.jsp

As always, thanks RK for pointing me in the right directions.

RE: Button 1-2 resets nRF51-DK

Hieu — Wed, 04 May 2016 04:17:20 GMT

I think that is what is going on. After I pressed Button 1, the advertising LED stop blinking. So I am guessing this behavior is configured in bsp_btn_ble.c or app_button.c?

RE: Button 1-2 resets nRF51-DK

RK — Wed, 04 May 2016 04:11:59 GMT

What does the documentation for that particular example say the buttons are supposed to do? Perhaps button 1 is default configured to put the chip into sleep mode, at which point you'd expect to see an LED light up and another button press of whatever button is default configured to wake it up, to wake it up again.

All the examples are documented - go see what it says about the particular one you're using.

RE: Button 1-2 resets nRF51-DK

Hieu — Wed, 04 May 2016 04:05:55 GMT

@rols: Are you sure this is a bug? I just tested with a fresh ble_app_uart example, with the only modification being UART config (baud 9600, no HWFC). The same behavior remains.

RE: Button 1-2 resets nRF51-DK

RK — Wed, 04 May 2016 03:46:48 GMT

The softdevice could reset the chip, the hardfault handler could reset it and none of those would show up in a project wide system search for nvic_systemreset. There's only 3 options here, either a soft reset is being requested by something writing the register, error handler, hardfault handler, softdevice etc .., the reset pin is being pulled low or it's resetting because power was removed and replaced due to an electrical issue.

Wy don't you clear the RESETREAS (by writing 0xffffffff) to it, then breakpoint in main() and find out after you get reset what the reason was.

Or put a data breakpoint to find out when the register is written to (I think that ought to work).

RE: Button 1-2 resets nRF51-DK

Hieu — Wed, 04 May 2016 03:26:23 GMT

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()

RE: Button 1-2 resets nRF51-DK

RK — Wed, 04 May 2016 03:18:29 GMT

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.

RE: Button 1-2 resets nRF51-DK

Hieu — Wed, 04 May 2016 03:13:26 GMT

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

RE: Button 1-2 resets nRF51-DK

Hieu — Wed, 04 May 2016 03:11:04 GMT

@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?

RE: Button 1-2 resets nRF51-DK

RK — Wed, 04 May 2016 02:58:14 GMT

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.