• State Verified Answer
  • Replies 13 replies
  • Subscribers 62 subscribers
  • Views 4641 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 120751
Options
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?

ashakya

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

Parents
  • 0

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

  • 0 in reply to Hung Bui

    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

Reply
  • 0 in reply to Hung Bui

    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

Children
No Data
Related

core_v2_widget.Hide()