• State Verified Answer
  • Replies 2 replies
  • Subscribers 64 subscribers
  • Views 2491 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101634
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problems with Reset loop S110 softdevice

bart

Hello All,

Since yesterday I have been getting a problem where my project using the S110 softdevice enters a reset loop. This runs on a unmodified PCA10001 that plugs into a carrier board.

After stepping through the code I reach a point where my code just resets and hits the breakpoint I have put at the beginning of main, without informing me what has happened. This "reset" occurs in the file "Source\ble\ble_stack_handler.c", in function ble_stack_handler_init at line sd_nvic_EnableIRQ(SWI2_IRQn); .

As I am working on a project that uses strong AC magnetic field I have taken a brand new PCA10001 out of its packaging and retested this. Same problem occurs with this board so I have eliminated hardware failure, strange thing is that this problem only showed up today. I am completely out of ideas, this worked last friday without a problem.

I can deliver the source code but this is based on a non public SDK and uses some propietary code.

Anyone from the nordic team that can look into this?

With kind regards,

Bart

Parents
  • 0

    A reset loop usually indicates that some function returns an error, that is caught by an APP_ERROR_CHECK(), resulting in app_error_handler() being called.

    By default, this function contains a reset, but for development I'd strongly recommend removing this reset and instead uncommenting the call to ble_debug_assert_handler(), or inserting an infinite loop and possibly some UART printing on your own. The app_error_handler() function gets the error code, file name and line number where the error occurred as arguments, so if you either halt the chip with a debugger or print this over UART, you should be able to easily find both the place at which the error occurred and hopefully also the cause.

    If you have trouble understanding the cause of the error, I'd strongly recommend you to post a question about this separately, since there are any number of possible causes here.

Reply
  • 0

    A reset loop usually indicates that some function returns an error, that is caught by an APP_ERROR_CHECK(), resulting in app_error_handler() being called.

    By default, this function contains a reset, but for development I'd strongly recommend removing this reset and instead uncommenting the call to ble_debug_assert_handler(), or inserting an infinite loop and possibly some UART printing on your own. The app_error_handler() function gets the error code, file name and line number where the error occurred as arguments, so if you either halt the chip with a debugger or print this over UART, you should be able to easily find both the place at which the error occurred and hopefully also the cause.

    If you have trouble understanding the cause of the error, I'd strongly recommend you to post a question about this separately, since there are any number of possible causes here.

Children
Related