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

How to make sure that the Bootloader starts in DFU mode if a valid app is not present?

Hi,

I am trying to implement a Single Bank DFU over Bluetooth for my nRF51822 (256KB / 16KB RAM) using SDK v7.1 and Softdevice 110. I am using GCC to compile the bootloader and in order to switch from dual bank (which I was doing previously before my application size did not allow it anymore) to single bank mode, I changed from dfu_dual_bank.c to dfu_single_bank.c in the Makefile. The complied bootloader works fine as I can upload new firmware onto the chip using FOTA. But, if however the process is interrupted, the chip bricks and has to be flashed again.

I figured out that upon load, the bootloader checks if the app present in the chip is valid by comparing its crc16 checksum with the checksum saved in the bootloader settings. I believe that here lies my problem because if this check failed after an unsuccessful FOTA attempt, the chip should remain in DFU mode but that is not the case. Can anybody shed some light into where the problem may lie?

Any response is much appreciated.

-ashakya

  • @ahakya: Porting DFU from dual bank to single bank in SDK v7.1 may requires some more step than just replacing dfu_dual_bank.c with dfu_single_bank.c . I'm not sure if you already did what needed. Please have a look at section J in this guide.

    I assume that when the process is interrupted, your device didn't even advertise as "DFUTarg". And it's bricked ? You may want to set your bootloader into debug mode and try to step into the code (or put some UART logging) to check why it doesn't stay in DFU mode and start advertising as "DFUTarg". To be able to debug the bootloader, please have a look at section F in the same blog I quoted.

  • Hi Hung,

    Firstly, thank you for your answer. I realised what you said is true and simply replacing dfu_dual_bank.c with dfu_single_bank.c was not enough to get the results that I desired. Therefore, I looked at the link you posted and tried to compile the bootloader from your modified repository available here

    So what I did was:

    • copied the GCC Makefile from the Blinky example and added all the files from the above repository to its list of sources and headers
    • added a gcc compatible bootloader_util.c
    • made small change in main.c to use internal oscillator

    But however when I use srec_cat to merge the final app+sd+bootloader hex, I get the following error

    srec_cat:
    bootloader.hex: 1:
    multiple 0x00000000 values (previous = 0xC0, this one = 0x00)
    

    Do you have an idea what is causing this?

    Best ashakya

  • Also, I guess it is worth mentioning that I am developing in a Mac environment so I have no Keil development environment to debug my builds unfortunately.

  • Using the makefile from Blinky example might not be the best idea, as it will have wrong memory configuration (location of the bootloader in flash) and result in that both the bootloader and the softdevice is trying to write to address 0x0000000.

    I would suggest to use original bootloader and only update them with the .c files provided in the example. (and replace dfu_dual_bank.c )

    Why not moving to SDK v8 or later ? Then you don't need to do much modification.

  • Hi Hung, my application is based on a fork of the nordic SDK v7.1.0 and is based on S110. This is the reason why I have been trying go compile a bootloader using SDKv7. Is it possible to compile a bootloader from a newer SDK that is backwards compatible?

Related