• State Verified Answer
  • Replies 13 replies
  • Subscribers 62 subscribers
  • Views 4642 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

    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.

Reply
  • 0 in reply to Hung Bui

    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.

Children
No Data
Related

core_v2_widget.Hide()