DFU (no bonding) getting stuck

RE: DFU (no bonding) getting stuck

nrbrook — Tue, 18 Aug 2020 14:01:11 GMT

It is getting the bank1 offset, which is bank 0 start address + bank 0 size. But how is that defined? Here is the output when generating the bootloader DFU settings:

Bootloader DFU Settings:
* File:                     ...DevKit_bootloader_setting.hex
* Family:                   nRF52
* Start Address:            0x0007F000
* CRC:                      0x21811082
* Settings Version:         0x00000002 (2)
* App Version:              0x0000271B (10011)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x0004C000 (311296 bytes)
* Application CRC:          0x4D0DA3C7
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x000248C0 (149696 bytes)
* Boot Validation CRC:      0xACDA1BA2
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

I noticed that nrfutil settings generate says that the settings get backed up to (settings address - 0x1000) which in my case is 0x7E000, which is the MBR params, is this correct?

After a bit more debugging I can see cache address = 0x72000, bootloader_start_addr = 0x72000 (correct), DFU_REGION_END(bootloader_start_addr) = 0x6E000 (correct: 0x72000 - 3 FDS pages (0x3000) - 0x1000 for the reserved flash).

However, for some reason the assert isn't triggering:

ASSERT(cache_address <= DFU_REGION_END(bootloader_start_addr));

And then this ends up being false (incorrect):

cache_too_small = required_size > (DFU_REGION_END(bootloader_start_addr) - cache_address);

I think under the assert should be something like this in case assert is disabled:

if(cache_address > DFU_REGION_END(bootloader_start_addr)) {
    cache_too_small = true;
    break;
}

However that doesn't explain why cache_address is incorrect. For some reason the bootloader settings indicates the application size is 0x4C000 which is the size of all the available application space (but the firmware itself is only 271609 = 0x424F8). How is the bank0/application size calculated when generating the dfu settings?

...it seems it converts to .bin and uses the size of the file. So why is the .hex converted to .bin 0x4C000? I confirmed it is that size using hex2bin.

...ah because of my provisioning block, need to remove the symbol. After modifying the arm-none-eabi-objcopy command to remove the symbol, it's working now!

RE: DFU (no bonding) getting stuck

Vidar Berg — Tue, 18 Aug 2020 12:03:17 GMT

I agree this must be a different issue. The question is why the bootloader attempts to erase the flash page at 0x72000 as the log says. It should have been a page in bank 0 or bank 1. I would suggest that you step through the nrf_dfu_cache_prepare() to try find out why it's returning the wrong address.

RE: DFU (no bonding) getting stuck

nrbrook — Mon, 17 Aug 2020 14:31:45 GMT

I don't think this is the issue. I'm using armgcc. My App linker file looks like this:

MEMORY
{
    /* MBR_FLASH (rx)        : ORIGIN = 0x00000000, LENGTH = 0x00001000 */
    /* SOFTDEVICE_FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 0x00025000 */

    FLASH (rx)               : ORIGIN = 0x00026000, LENGTH = 0x0004b000
    RAM (rwx)                : ORIGIN = 0x20003320, LENGTH = 0x0000cce0

    provisioning_data (rwx)  : ORIGIN = 0x00071000, LENGTH = 0x00001000

    /* BOOTLOADER_FLASH (rx) : ORIGIN 0x00072000, LENGTH = 0x0000c000 */
}

% arm-none-eabi-size FirmwareProject_DevKit.elf
   text    data     bss     dec     hex filename
 271608    7360   26880  305848   4aab8 FirmwareProject_DevKit.elf

Bootloader looks like this:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x72000, LENGTH = 0xc000
  RAM (rwx) :  ORIGIN = 0x20003320, LENGTH = 0xcce0
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  bootloader_settings_page (r) : ORIGIN = 0x0007F000, LENGTH = 0x1000
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0007E000, LENGTH = 0x1000
}

% arm-none-eabi-size bootloader.out
   text    data     bss     dec     hex filename
  44660    1400   22436   68496   10b90 bootloader.out

So addresses are

0x26000-0x71000 Firmware

0x71000-0x72000 Reserved flash storage

0x72000-0x7E000 Bootloader

0x7E000-0x7F000 mbr params

0x7F000-0x80000 bootloader settings

firmware size 271608 < flash space 0x4b000 = 307200

bootloader size 44660 < flash space 0xc000 = 49152

I've just tried 17.0.0 and it has the same issue.

RE: DFU (no bonding) getting stuck

Vidar Berg — Mon, 17 Aug 2020 11:15:32 GMT

Hello,

In case you are using Segger embedded studio and have made changes to the bootloader that may have increased the code size, please try to re-compile the bootloader with the updated flash_placement.xml file from SDK 17.0.0 as I recommend here: https://devzone.nordicsemi.com/f/nordic-q-a/64730/micro-ecc-a-file-not-included/264581#264581.The original one will not give you a linker warning even if the bootloader starts to overlap with the MBR params page, which may result in the behavior you described.

Best regards,

Vidar