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

DFU for different Chips - Guidelines request

Hello,

the past week I am trying to make the bootloader_secure example work for a custom hardware with no luck. This whole procedure give birth however to several questions.

(Should not matter, but I am using a nrf51 chip with 16KB RAM and 256KB flash. SDK 12.1.)

  1. Linker scripts secure_dfu_gcc_nrf51.ld and secure_dfu_gcc_nrf51_debug.ld define RAM/FLASH regions which are a bit of a mystery to me. So my question is, how are these regions computed given different chip variants (RAM/FLASH) and given different Softdevice versions? The only thing I could find in documentation is this. And this only mentions Softdevice 130 v2.0.x for nrf51 and 132 v3.0.x for nrf52 and only for the flash. And it is also not mentioning the differences when debug is on.

  2. How about external crystals of different frequencies? Anything else to configure other than this?

  3. How about boards that have zero or one button? How do you suggest people should deal with this? (Hint: BSP_BUTTON 4 would not exist)

I hoping that once Nordic clarifies those things, it would make the life of people with custom boards much easier :)

I hope you would agree. Thank you!

Parents
  • Hi Tanasis,

    1. The bootloader located on top of the flash, separated it from the application and the softdevice flash area. You might already find it in the "Memory Layout" section in the documentation. It doesn't matter which softdevice you use, because we simply locate the bootloader at the top of the flash. The only thing matter is the size of the bootloader and the size of the flash.

    Basically we need 2 pages, 8kB (on nRf52 and on nRF51 we need one page, 1kB) to store bootloader and MBR setting and then 24kB (0x6000) for the bootloader it self (on nRF51 it's 20kB).

    You can then use the size of the flash, minus (bootloader size + setting size) to get the start address of the bootloader.

    RAM's configuration shouldn't be changed. Note that we haven't tested the secure bootloader on other softdevices other than S130 v2.0 and S132 v3.0.

    1. It should be the same as a normal application. nRF52 only works with 32MHz crystal and nRF51 works with 16MHz and 32Mhz (XTALFREQ configuration needed)

    2. For buttonless DFU, have a look at experimental_ble_app_buttonless_dfu example in ble_peripheral.

  • Hi Tanasis,

    1 . It came a little bit from the legacy S130v1.0 that we need 11kB of RAM for the softdevice and the attribute table. If you are using the S130 v2.0 and don't add any more service or characteristic, you can use 0x200025E0 as the RAM start address (you can find the actual RAM required from the softdevice by adding a break point after you called sd_ble_enable() and check the app_ram_base return value. As I mentioned, the debug project is only for using with debug key, it has nothing to do with RAM and ROM configuration, nor with code optimization.

    Why should RAM setting be different when using debug ?

    3 . No, we only make generic DFU example. Specific implementation should be done by the user.

Reply
  • Hi Tanasis,

    1 . It came a little bit from the legacy S130v1.0 that we need 11kB of RAM for the softdevice and the attribute table. If you are using the S130 v2.0 and don't add any more service or characteristic, you can use 0x200025E0 as the RAM start address (you can find the actual RAM required from the softdevice by adding a break point after you called sd_ble_enable() and check the app_ram_base return value. As I mentioned, the debug project is only for using with debug key, it has nothing to do with RAM and ROM configuration, nor with code optimization.

    Why should RAM setting be different when using debug ?

    3 . No, we only make generic DFU example. Specific implementation should be done by the user.

Children
No Data
Related