• State Verified Answer
  • Replies 11 replies
  • Subscribers 73 subscribers
  • Views 3981 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 117457
Options
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

Tanasis!

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
  • 0

    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.

Reply
  • 0

    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.

Children
  • 0 in reply to Hung Bui

    Hello Hung. Thx for the reply. Some follow-up questions please:

    1. Actually the following needs to be satisfied: bootloader address > Softdevice (mbr is inside) + App size Correct? (Of course if there are application data this is adjusted.) And of course bootloader + settings address < flash size. In simpler words, we can place the bootloader where-ever there is space left and update the UICR reg accordingly?
    • How about the RAM? How is 0x20002C00 for nrf51 / S130 computed? And why are RAM requirements NOT different when using debug?
    • "Note that we haven't tested the secure bootloader on other softdevices other than S130 v2.0 and S132 v3.0." <--- Very important remark thank you!
    1. OK that's clear :)
    2. For zero buttons this is clear. For 1? Anything to be done here? And I am guessing we can assign the BSP_BUTTON_4 to something random that is not used of course?
  • 0 in reply to Hung Bui

    @Tanasis:

    1 . I don't understand why you want to locate the bootloader in different address ? You should always locate it at the top end of the flash. This way gives you the maximum free space to receive the new image of the application and/or softdevice.

    Note that the debug project is only about using the debug keys for secure DFU. It's not about the optimization level and related. The size of the bootloader remains the same. And you still can't set break point and step in the code. If you want to debug and step in the code, you would need to change the optimization level, and therefore change the start address of the bootloader as the size of it grows bigger.

    3 . What "1" ? You mean one button ? You can do whatever you want with the button, just remove the code in the bootloader to enter bootloader mode when the button is pressed.

  • 0 in reply to Hung Bui

    Hung Bui, is it a mistake that you have written 64 MHz instead of 32 MHz as the only option for the nRF52?

  • 0 in reply to Hung Bui

    Hi Kyle, Sorry, my mistake :( Yes it's 32MHz crystal which runs the 64MHz oscillator. I updated the answer.

  • 0 in reply to Hung Bui

    Gave our hardware guys a bit of a scare with that one, thanks for the update.

Related
Terms of service