DFU SDK15 CRC problem.

[Mikhail]

Hi!

nRF52832, SDK15, S132.

I try to use DFU. I already implemented same DFU on a SDK13. All works correct. 

When flash SD132 and merged firmware with bootloader_setting.hex, always DFU targ started in a air.

 0> <info> app: Inside main
 0> <debug> app: In nrf_bootloader_init
 0> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
 0> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
 0> <debug> app: Enter nrf_bootloader_fw_activate
 0> <info> app: No firmware to activate.
 0> <debug> app: Enter nrf_dfu_app_is_valid
 0> <debug> app: Return false in CRC
 0> <debug> app: DFU mode because app is not valid.
 0> <info> nrf_bootloader_wdt: WDT is not enabled
 0> <debug> app: in weak nrf_dfu_init_user
 0> <info> app_timer: RTC: initialized.
 0> <info> app: Entering DFU mode.
 0> <debug> app: Initializing transports (found: 1)
 0> <debug> nrf_dfu_ble: Initializing BLE DFU transport
 0> <debug> nrf_dfu_ble: Setting up vector table: 0x00072000
 0> <debug> nrf_dfu_ble: Enabling SoftDevice.
 0> <debug> nrf_dfu_ble: Configuring BLE stack.
 0> <debug> nrf_dfu_ble: Enabling the BLE stack.
 0> <debug> nrf_dfu_ble: No advertising name found
 0> <debug> nrf_dfu_ble: Using default advertising name
 0> <debug> nrf_dfu_ble: Advertising...
 0> <debug> nrf_dfu_ble: BLE DFU transport initialized.
 0> <debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
 0> <debug> app: Enter main loop

Therefore, problem in a CRC that DFU can't calculate CRC of the app.

        if (crc != s_dfu_settings.bank_0.image_crc)
        {
            // CRC does not match with what is stored.
            NRF_LOG_DEBUG("Return false in CRC");
            return  false;
        }

If I changed to return true; , all work fine.

One more time, I use same merge code for get bootloader_setting.hex in the SDK13 and it wors fine.

I use example from

https://devzone.nordicsemi.com/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader

Should make any changes for calculate CRC in the SDK15?

[Einar Thorsrud]

Hi,

Clearly the calculated CRC of the application does not match the CRC in the bootloader settings. Can you verify that you are using the exact same application .hex file when you generate the bootloader settings page using nrfutil as you actually program on the device? If the .hex file is not the same, then the CRC will not match.

[Mikhail]

I use .bat file

nrfutil pkg generate --hw-version 52 --application-version 1 --application my_app.hex --sd-req 0x98 --key-file private.key app_dfu_package.zip
nrfutil settings generate --family NRF52 --application my_app.hex --application-version 0 --bootloader-version 0 --bl-settings-version 1 bootloader_setting.hex
mergehex --merge bootloader_setting.hex nrf52832_xxaa_s132.hex my_app.hex --output boot_my_app.hex
pause

When this .bat works, it use compiled bootloader file and generate boot_my_app.hex

after that I flash via nrf go studio SD 6.0 and this boot_my_app.hex. Is it correct?

Same I made with SDK13- all works fine.

[Mikhail]

I lockated my data __at_0x6EC00

and seems works good. 

But this location __at_0x6EC00 posiible to store data between DFU?

[Einar Thorsrud]

The data will never be preserved between DFU if they are between the start address and end address of the application .hex file. So if you want to preserve the data after DFU you cannot include it in the application like you do (with __attribute__((section(".ARM.__at_0x71400")))...) as we have discussed. This will mean that everything between the application start address and the page with the data section will be erased when you do DFU, which is expected and correct behavior.

To keep the data during DFU, make sure to not include the data in the application hex, and put it on the page right beneath FDS. Then adjust DFU_APP_DATA_RESERVED accordingly so that the bootloader does not overwrite the data during a DFU upgrade.

[Mikhail]

I have now in the bootloader project

#ifndef DFU_APP_DATA_RESERVED
#define DFU_APP_DATA_RESERVED (CODE_PAGE_SIZE * 3)

and located my data at the main app at 0x6EC00 right beneath FDS.

Therefore ,  can I count on normal storage data between DFU or no?

[Einar Thorsrud]

No, you cannot. FDS uses three pages, and you would need to reserve an additional page for your data (starting at 0x6E000). Your current DFU_APP_DATA_RESERVED value will only tell the bootloader to leave the three pages used by FDS alone (0x6F000-0x71FFF), so you must set DFU_APP_DATA_RESERVED higher to reserve the additional page:

#define DFU_APP_DATA_RESERVED (CODE_PAGE_SIZE * 3)

[Mikhail]

Let's speak one more time again.

FDS used (0x6F000-0x71FFF). Is it right?

Therefore, I should plase data below 0x6F000. Right?

Is it incorrect to locate data at 0x6EC00? 

Why?

Or should set DFU_APP_DATA_RESERVED  more than 3? Because this means for total reserve FDS and my storage data?

[Einar Thorsrud]

Mikhail said:

FDS used (0x6F000-0x71FFF). Is it right?

Yes, that is correct. FDS uses flash pages directly beneath the bootloader. In your case your bootloader starts at 0x72000, and as you use 3 pages for FDS, this means that FDS starts at 0x6F000.

Mikhail said:

Therefore, I should plase data below 0x6F000. Right?

Yes.

Mikhail said:

Is it incorrect to locate data at 0x6EC00? 

 No, that is OK.

Mikhail said:

Or should set DFU_APP_DATA_RESERVED  more than 3? Because this means for total reserve FDS and my storage data?

 YES! You need to set it to 4, as that is the total amount of pages below the bootloader you want to preserve.

[Mikhail]

Thanks. But DFU_APP_DATA_RESERVED  where should to set? In the bootloader or app projects?

[Mikhail]

ofcourse in the bootloader project. I'll check all.

[Mikhail]

seems, work. But I need check with real DFU update. I'll write later.

Einar, one more question-

I need into bootloader insert a crypto library. For this reason I expand size of bootloader from 0x72000 to 0x6D000. All works. 

Could you explain me chain of work. After reset, starts SD, than transfer management to bootloader? But how SD known wich address of bootloader starts? 0x72000 or 0x6D000 or another?

[Einar Thorsrud]

Mikhail said:

After reset, starts SD, than transfer management to bootloader?

 Yes.

Mikhail said:

But how SD known wich address of bootloader starts? 0x72000 or 0x6D000 or another?

The SoftDevice checks the UICR.NRFFW[0] register for the bootloader start address, and this is set by the bootloader .hex file (you can search for uicr_bootloader_start_address in the bootloader code and linker script / flash placement to see how it is done). See Bootloader in the SoftDevice specification for details.