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.

[Einar Thorsrud]

The only reason I can think of that would make the CRC not correct is if your application write something to flash within that region. Can you let me know your flash memory layout? Does the application store any other information to flash? Doe sit use FDS or similar for something? If so, how many pages? There seems to be somthing that is different within the application flash region once your application runs compared to when you calculate the bootloader settings page of the application image, but I cannot say what without knowing the details of what/how/when/where you use the flash.

[Mikhail]

My flash settings:

Yes, information stored into flash via fds. #define FDS_ENABLED 1, #define FDS_VIRTUAL_PAGES 3

Any idea?

[Einar Thorsrud]

Ah, there we have it, then. You write that you use a debug bootloader starting at address 0x72000. Below there you have three FDS pages, which is 3*4*1024 = 0x3000, so they start at 0x6F000, which is below your fixed data starting at 0x71400, so they overlap. This means that when your application initializes FDS it writes to the flash area that is within the application region, which in turn will result in a different CRC (as it should). You simply have to move the fixed below the FDS pages to correct this.

[Mikhail]

Good idea, I'll check it. But if I transfer this data before 0x6F000, have I unerased data after DFU update?

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