• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 91 subscribers
  • Views 1988 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288422
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NRF sometimes hangs on dfu initialization (?)

Jur

Hi,

I have an issue where sometimes after a restart of our device the nRF hangs on either:
ble_dfu_buttonless_async_svci_init()
or
ble_dfu_buttonless_init(&dfuButtonlessService)

I suspect these functions because:

1)  On a successful boot I see this in my RTT log:
00> <info> app: Setting vector table to bootloader: 0x00071000
00> <info> app: Setting vector table to main app: 0x00026000

While a failed boot logging stops at:
00> <info> app: Setting vector table to bootloader: 0x00071000

2) When I remove the calls to these functions the device seems to always start correctly.
3) Sometimes after executing a firmware upgrade using the DFU the same situation arises and we need to restart the device by removing and reinstalling the battery.

I would like to debug this but as we are using a softdevice this is near to impossible. I already assert on the return values of those functions (they need return NRF_SUCCESS), but those are never hit. Possibly because the nRF hangs within one of those functions.

Would you happen to have any idea what could be going wrong here? Does this have something to do with the softdevice sometimes not being ready? How could we fix this, or how could I find out what is really going on?

Thanks a lot Slight smile

SDK: 15.3.0
SD: S132
HW: nRF52832
We use FreeRTOS

Update: Through this thread which described quite similar behaviour I found: this thread. I will try the patch and see if that fixes the issue.

  • +1

    Hi,

    I believe threads you have found are relevant, including the fix in the original post here. This is unfortunately still an issue even in nRF5 SDK 17.1.0.

    (Note that you can debug even if you have a SoftDevice. The "only" issue is that if you continue after a breakpoint or pause, the SoftDevice will assert. So instead of for instance stepping you need to set a breakpoint and let it run to that. If you want to step further you instead of stepping move the breakpoint and reset so that execution goes a bit further next time. This can be somewhat annoying but you can get the same information this way in most cases.)

  • 0 in reply to Einar Thorsrud

    Hi Einar,

    It looks like the fix is actually working! I have tried really hard but could not reproduce the issue anymore after applying the patch. Can I ask why this is not fixed in the latest version of the SDK? In my opinion this is a really nasty bug:

    • It only triggers in certain situations (we missed it in testing)
    • It completely crashes the nRF (watchdog cant rescue you)

    Also the fix does not seem complicated at all and an example is already written.

    Thanks a lot for including the information about debugging with the SoftDevice! I was not aware of this and am ready to have some fun with GDB again!

  • 0 in reply to Jur

    Hi,

    I am glad to hear you have validated the fix in your product. I agree that this can be a serious bug that should be fixed. Unfortunately it was filed with some key tags missing in our internal bug tracker system, which I believe is why it was not fixed before. I have updated the internal ticket so that this will show up when considering fixes for a potential future bugfix release of the nRF5 SDK.

Related
Terms of service