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

DFU not working SD 3.0.0

Setup

nRF52 - Rev 1 SD 3.0.0

internal RC for timer

utilizing the provided secure bootloader, and the DFU buttonless template source.

Created/compiled the 2 images so I have:

  • bootloader
  • App
  • SD 3.0.0

perform the complex secure signing.

Setup loads to the dev board fine, and OTA via an iPhone 6 with nRF Toolbox completed just fine and the template app comes up.

Load the SD and bootloader to my production board works fine via nRFGo studio, OTA seems to work fine, indicates 100% complete at end of transfer, BUT the device resets back into the bootloader and the template app does not load.

So, exact same image files: APP, SD and bootloader, same rev of nRF52 chip: Rev 1, both boards indicate that the OTA has completed, the dev board loads the app but my production one does not.

Also please note that this same production board works fine with sd 2.0

What is up?

  • Could you use nrfjprog to read the bootloader settings flash page, i.e. nrfjprog -f nrf52 --memrd 0x0007F000 --n 32, and attach to the question?

  • I found the problem. I was expecting the use of defines such as BSP_SIMPLE to be still in effect and thus take out any board specific hardware usage but this was not the case. In previous version of the SDK, if you wanted to remove the button support from a template you would delete any support from the app specific files and use the defines to disable their use in the Libraries. It seems that SDK v12 has taken a step away from the old SDKs stylistically which is what got me.

    The problem was in nrf_dfu_enter_check() which utilizes a direct pin read of IO pin to determine if we enter bootloader mode or not. This was a line in the main.c of the old bootloader and the defines, such as BSP_SIMPLE, took care of board specific references in the libraries before.

    The new style uses weak functions with the expectation that the user will override them. This is a fine way of doing it but, perhaps, adding #warning to such functions so they are more apparent would be beneficial.

  • Happy to hear that you figured it out. I agree that it would be a good idea to add warnings to the weak functions make the user aware that they should override them.

Related