This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Sequence for Bootloader to configure SoftDevice

Hi,

In our existing project, it has a Bootloader and MBR, but no SoftDevice. Transport is UART for DFU.

I need to port the Bootloader to work on another project that uses SoftDevice.

I read that Bootloader needs to configure SoftDevice by calling the APIs.

I have 2 questions:

1. What are the things in SoftDevice that need to be configured by the Bootloader? Or, what is the right sequence for Bootloader to initialize and configure SoftDevice?

2. In the Bootloader sct file, the start address is 0xD6000, and the size is 0x1A000. But when I checked the hex file, the address ended at 0xE7000, while according the sct file, it ends at 0xF0000. The Bootloader settings location is at 0xEF000. Should I move it to be higher than 0xF0000?

Thanks.

Parents
  • Hi Einar, thanks a lot for a quick response.

    Yes, I am using nRF5 SDK bootloader. (SDK 15.2 - S140 v6.1.1)

    All of the above include a lot of details, so the easiest is to compare/diff your bootloader project /Makefile to an example project/Makefile using the SoftDevice to see what you need to add.

    Where can I find the example project for Bootloader with SoftDevice? I couldn't find it under SDK 15.2. I don't need the OTA yet, for now I just need to make Bootloader coexists with SoftDevice - keep the UART as the DFU transfort.

    I am not sure bout this scatter (.sct) file you are referring to. Can you clarify? Which toolchain do you use, and what does it say?

    The scatter file I referred to was the Bootloader's. I use Keil toolchain. It says that in scatter file we define the start address and the size of the output. That's why I am confused, as if I add 0xD6000  with 0x1A000 = 0xF0000. While the actual hex file is smaller - ends at 0xE7000.

    We use the last address space, that's why everything became custom. The Bootloader shifted to 0xD6000, Bootloader settings was set at 0xEF000, and MBR Params at 0xEE000.

    Btw, I pick up this project from another team member.

  • Hi,

    Harry said:
    Where can I find the example project for Bootloader with SoftDevice?

    The BLE bootloader examples use the SoftDevice.

    Harry said:
    I don't need the OTA yet, for now I just need to make Bootloader coexists with SoftDevice - keep the UART as the DFU transfort.

    Then you can keep the serial bootloader as is. Whether the SoftDevice is present in flash or not has no impact as long as it is not used by the bootloader itself. (The nRF52840 dongle is an example of that, as it ships with a USB serial bootloader. The bootloader remains the same regardless of if you program a SoftDevice or not, and the bootloader never uses the SoftDevice in any case).

  • Hi,

    Harry said:
    1. How about MBR Params page? Do I need to generate it too?

    No. The MBR params page should not be programmed (if it contains any data, the MBR will erase it).

    Harry said:
    2. I saw somewhere in this forum that Bootloader need to call sd_softdevice_vector_table_base_set(). Bootloader forwarding interrupts and jumping to 0x1000, is it a new behavior? So, does it mean there is no need anymore for such init type SoftDevice API calls (i.e. sd_softdevice_vector_table_base_set)?

    sd_softdevice_vector_table_base_set() is still used, but not for this. The bootloader always starts "applications" at 0x1000 and does not care if it is a SoftDevice or application. As part of this, it also forwards interrupts there using nrf_dfu_mbr_irq_forward_address_set(). If the application is there, then it runs after the bootloader has branched to it. If the SoftDevice is there, it will in turn forward interrupts to the application, which always starts immediately after the SoftDevice, and will branch there.

  • Thank you so much.

    Btw, I generated bootloader settings using nrfutil, I entered the start address as integer (978944), it confirmed that the start address is at 0xEF000.

    But when I opened the hex file using J-Flash, it shows the start address is 0xEE000. I used nRF Connect, same thing, it occupies both 0xEE0000 and 0xEF000 (same data).

    What do I miss?

  • Hi,

    It seems my memory let me down.

    The "nrfutil settings generate" commons will populate the backup MBR settings region in the MBR params page unless the "--no-backup" option is used, and this is what you are seeing. This is correct.

  • Thank you so much.

    Just last thing to clarify, you mentioned:

    sd_softdevice_vector_table_base_set() is still used, but not for this. The bootloader always starts "applications" at 0x1000 and does not care if it is a SoftDevice or application. As part of this, it also forwards interrupts there using nrf_dfu_mbr_irq_forward_address_set().

    1. When sd_softdevice_vector_table+base_set() is used?

    2. Do I need to manually call nrf_dfu_mbr_irq_forward_address_set(), or Bootloader in the SDK has called it?

  • Hi,

    Harry said:
    1. When sd_softdevice_vector_table+base_set() is used?

    It is used when changing the vector table forwarding between the bootloader and the application, for instance in the buttonless DFU service implementations (ble_dfu_bonded.c and ble_dfu_unbonded.c, implemented in nrf_dfu_svi.c). It is also used to forward interrupts to the bootloader if it entering BLE DFU mode. (It is not used/needed to forward interrupts to the application at boot since this is the default configuration of the SoftDevice.)

    Harry said:
    2. Do I need to manually call nrf_dfu_mbr_irq_forward_address_set(), or Bootloader in the SDK has called it?

    Yes, but I assume you already do that in your existing bootloader, so no change is needed here. It should always forward to address 0x1000, which is either the start address of your application or the SoftDevice.

Reply
  • Hi,

    Harry said:
    1. When sd_softdevice_vector_table+base_set() is used?

    It is used when changing the vector table forwarding between the bootloader and the application, for instance in the buttonless DFU service implementations (ble_dfu_bonded.c and ble_dfu_unbonded.c, implemented in nrf_dfu_svi.c). It is also used to forward interrupts to the bootloader if it entering BLE DFU mode. (It is not used/needed to forward interrupts to the application at boot since this is the default configuration of the SoftDevice.)

    Harry said:
    2. Do I need to manually call nrf_dfu_mbr_irq_forward_address_set(), or Bootloader in the SDK has called it?

    Yes, but I assume you already do that in your existing bootloader, so no change is needed here. It should always forward to address 0x1000, which is either the start address of your application or the SoftDevice.

Children
No Data
Related