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 think, I understand my problem.

I need use non updated storaged data. And like in the SDK13 I locate some structure before bootloader. In the SDK13 this works. I use in the SDK15 bootloader with debug and it starts from 0x72000. Therefore I can locate my data 3 KB before it. I lockated my data 

... __attribute__((section(".ARM.__at_0x71400"))) = 

but this is doesn't work. (like discribed in this topic)

When I located this struct in the main code

... __attribute__((section(".ARM.__at_0x26A00"))) = 

all works fine. I can run bootloader and starts my app correct.

How should locate my unupdatable data? 

[Mikhail]

Hi again!

I still wait any help from you. I can say that with lockated data struct at_0x71500

crc incorrect. With this struct located at_0x26B00 all works fine. 

???

Also problems in the calculate crc in the function 

bool nrf_dfu_app_is_valid(bool do_crc)

I print data from bootloader:

 0> <debug> app:      s_dfu_settings.bank_0.image_crc: 0xA067C472
 0> <debug> app:      s_dfu_settings.bank_1.image_crc: 0x00000000
 0> <debug> app:      s_dfu_settings.bank_0.image_size: 0x0004B514
 0> <debug> app:      crc: 0x217DC205

Therefore, crc is different.

Why?

And this only with struct located at_0x71500. 

[Einar Thorsrud]

Hi,

This is relevant information. When you place information in flash this way, the application area extends over the whole flash between the start of the application and the end of the data below the bootloader, and the CRC is calculated over the whole range. Do you for instance write any other data to flash between this regions from your application? In that case you will modify the flash within the (in this case large) application region, leading to the CRC mismatch.

[Mikhail]

Thanks. And what should I do for decide this problem? I only write flash data like an application and also located data 

... __attribute__((section(".ARM.__at_0x71400"))) = 

There are no any else data. 

Should at this case correct calculate crc? Why crc calculated not correct? Or I can't to lacate data at this memory region? 

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