Bootloader with Custom DFU

RE: Bootloader with Custom DFU

Einar Thorsrud — Thu, 27 Apr 2023 06:25:17 GMT

I am no IAR expert, but as long as you specify the start of a page as the application start address (see under 7. Change start addresses for the IAR here), then that should work (?).

Regarding if you should be concerned I cannot recall ever dealing with an application that was not page aligned, but at the same time, I cannot immediately think of a reason why it should cause problems when using a bootloader (the address should be word aligned, though).

RE: Bootloader with Custom DFU

erk1313 — Wed, 26 Apr 2023 15:42:12 GMT

Einar Thorsrud What are your thoughts on IAR compiling binary files that are not page aligned? Should I be concerned? Is there a way to force it to be page aligned?

RE: Bootloader with Custom DFU

Einar Thorsrud — Wed, 26 Apr 2023 13:00:46 GMT

As the nRF5 SDK bootloader only supports booting applications in slot 0 which start right after the SoftDevice (or MBR if no SoftDevice is used), there is also no support in the accompanying tools like nrfutil for other configurations. That said, the you can clone pc-nrfutil and modify it to your needs for your custom bootloader / DFU solution.

RE: Bootloader with Custom DFU

erk1313 — Tue, 25 Apr 2023 12:26:07 GMT

Einar Thorsrud Thank you for your help! Is there a way to create bootloader settings for bank1 using the NRF Utilities? Our application requires a custom transport layer and I would like to create firmware offset for bank1 along with bootloader settings for bank1. I understand this is usually handled in the DFU transport layer.

RE: Bootloader with Custom DFU

erk1313 — Fri, 21 Apr 2023 13:20:27 GMT

For others, note that SDK15.3 places the bootloader start address elsewhere:

devzone.nordicsemi.com/.../how-to-read-flash_start-address-of-bootloader-in-application

RE: Bootloader with Custom DFU

erk1313 — Fri, 21 Apr 2023 13:15:03 GMT

I suppose an alternative would be to manually overwrite it using

nrfjprog -f nrf52 --memwr 0x10001014 --val <value>

RE: Bootloader with Custom DFU

erk1313 — Fri, 21 Apr 2023 13:07:53 GMT

Success, with some manual manipulation.

1. Uploading pending FW update. I place the pending FW update in Bank 2 and read the bootloader settings into a new structure (s_dfu_settings) by calling nrf_dfu_settings_init. After updating the fields below, I call nrf_dfu_settings_write() to write the settings to Flash.

s_dfu_settings

- Set bank-1.image size and .image_crc:
- Set bank_1.bank_code to 1 to indicate the bank had valid firmware
- Set .progress.update_start_address to the start address of bank-1

2. On Bootloader Startup, I call ret_nrf_bootloader_init(NULL) which handles the update, eventually calling app_activate()to copy the firmware to bank-0, then reset the device.

~~~QUESTION~~~

To step through the code, I have to set optimization to NONE and enlarge the space allocated to the bootloader by one page. This includes changing the ROM_region in the .icf file and the definition of the BOOTLOADER_START_ADDR:

From: #define BOOTLOADER_START_ADDR (CODE_START)
To: #define BOOTLOADER_START_ADDR 0x000F7000

However, should I be modifying CODE_START instead? How would one do that?

#define CODE_START ((uint32_t)&__vector_table)

Also, I'd like to avoid modifying the SDK, as it is a shared resource for other projects. But when I define BOOTLOADER_START_ADDR, I receive the error incompatible redefinition. How can I define this without touching the SDK?

RE: Bootloader with Custom DFU

Einar Thorsrud — Thu, 20 Apr 2023 11:52:37 GMT

Hi,

I do not have a full overview of your bootloader, but I will try to give some pointers and suggestions in hope that some may be useful.

Debugging an application that is optimized is difficult, but the SDK bootloader (that you have based your on) use RTT loggign extensively if you build the debug variant, and you could add more logging relevant for what you are currently debugging. Enabling logging (which is done in the _debug sample bootloader projects) does increase the size though, so you need to be able to fit that while debugging. Another option could perhaps be to build the bootloader without optimization and accept that it is larger while debugging the bootloader, and use a simpler test application while doing this if you are able to make it fit? (This would be just while working on the bootloader).

Regarding removing the transports, the transports are quite decoupled from the rest of the bootloader, and are registered build time via a section variable that holds the list of backends that is initialized one after another. You should not have to make many adjustments other than just remove all the files used for the transport (for instance serial UART if you based your bootloader on a project that used that).

RE: Bootloader with Custom DFU

erk1313 — Wed, 19 Apr 2023 21:23:21 GMT

Hmm... That did copy the pending firmware update, but put it higher. Need to look closer at the offset address. Maybe I should create bootloader settings based on the app before offset. Then load the pending update manually.

RE: Bootloader with Custom DFU

erk1313 — Wed, 19 Apr 2023 21:16:31 GMT

I just realized I need to set the address of the pending fw update. It did not help though. What other settings are normally handled by the DFU?

- s_dfu_settings.progress.update_start_address = 0x85000 // Bank-1

RE: Bootloader with Custom DFU

erk1313 — Wed, 19 Apr 2023 21:08:40 GMT

I tried setting the optimization lower than "high" but the bootloader is too large. That's probably why I can't follow it in the debugger. Is there an easy way to cut back on the bootloader, as I don't need the transport functions?

Disassembly of the app_activate() function responsible for copying the pending FW update. It gets to 0xf'a164 ADDS, then jumps out of the function.