• State Verified Answer
  • Replies 13 replies
  • Subscribers 63 subscribers
  • Views 4677 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, I have determined the problem and it is as I suspected. After a failed DFU OTA (I quit the app when the firmware is transferring), I read the bootloader settings from the chip. They were:

    0x0003FC00: 00000001 00000000 00000000 00000000   |................|
0x0003FC10: 00000000 00000000 00000000 00000000   |................|

    From what I understand, the DFU before it starts should set the bank_0 to BANK_INVALID_APP or BANK_ERASED such that if the DFU fails we know that a new application has not been uploaded. But from what we see here, that is not the case. Also, the CRC for the app is not set. If I then erase the page at 0x3fc00 and then write 0xFF(BANK_INVALID_APP) then DFU starts as expected.

    So what I need help with is to isolate the code which sets the bootloader settings at the start of the DFU and make sure it does its job.

Reply
  • 0 in reply to Hung Bui

    Hi Hung, I have determined the problem and it is as I suspected. After a failed DFU OTA (I quit the app when the firmware is transferring), I read the bootloader settings from the chip. They were:

    0x0003FC00: 00000001 00000000 00000000 00000000   |................|
0x0003FC10: 00000000 00000000 00000000 00000000   |................|

    From what I understand, the DFU before it starts should set the bank_0 to BANK_INVALID_APP or BANK_ERASED such that if the DFU fails we know that a new application has not been uploaded. But from what we see here, that is not the case. Also, the CRC for the app is not set. If I then erase the page at 0x3fc00 and then write 0xFF(BANK_INVALID_APP) then DFU starts as expected.

    So what I need help with is to isolate the code which sets the bootloader settings at the start of the DFU and make sure it does its job.

Children
No Data
Related