DFU for different Chips - Guidelines request

RE: DFU for different Chips - Guidelines request

Tanasis! — Thu, 10 Nov 2016 12:42:13 GMT

Hello Hung, Thanks for clearing this! (Regarding the RAM, I don't have insights on the implementation, so there might be a case - for example - where you needed to allocate buffer(s) to store debug info, so stack becomes larger. I am not saying it should, I was wondering if it is happening...)

RE: DFU for different Chips - Guidelines request

Hung Bui — Thu, 10 Nov 2016 12:35:04 GMT

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.

RE: DFU for different Chips - Guidelines request

Tanasis! — Thu, 10 Nov 2016 10:41:29 GMT

@Hung

I am not gonna do this of course. :) I am trying to understand the logic.

How about the RAM? How is 0x20002C00 for nrf51 / S130 computed? And why are RAM requirements NOT different when using debug?

Buttons. Yes I agree - this is obvious. But I was hopping that there was a more elegant solution. Perhaps detect long press of the Button after startup and enter Bootloader. Or maybe detect a looooong press (5 secs or so) during normal operation and then reset chip and force it to the Bootloader, etc.

THanks!

RE: DFU for different Chips - Guidelines request

Hung Bui — Tue, 08 Nov 2016 15:08:42 GMT

Sorry about that :(

RE: DFU for different Chips - Guidelines request

Kyle Krueger — Tue, 08 Nov 2016 15:00:20 GMT

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

RE: DFU for different Chips - Guidelines request

Hung Bui — Tue, 08 Nov 2016 14:45:14 GMT

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

RE: DFU for different Chips - Guidelines request

Kyle Krueger — Tue, 08 Nov 2016 13:39:00 GMT

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

RE: DFU for different Chips - Guidelines request

Hung Bui — Mon, 07 Nov 2016 08:49:39 GMT

@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.

RE: DFU for different Chips - Guidelines request

Tanasis! — Fri, 04 Nov 2016 18:00:09 GMT

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

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!

OK that's clear :)
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?

RE: DFU for different Chips - Guidelines request

Hung Bui — Wed, 02 Nov 2016 10:11:08 GMT

Hi Tanasis,

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.

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)
For buttonless DFU, have a look at experimental_ble_app_buttonless_dfu example in ble_peripheral.

RE: DFU for different Chips - Guidelines request

Roger Clark — Wed, 02 Nov 2016 00:06:36 GMT

Just to add a "me to" to this

I need to create a secure bootloader for a new product, using the nRF51822QFAA (256k flash 16k RAM)

I do not have a button on the board either (well not one that is user accessible).

I was hoping that the bootloader could be called from the application code, but I am not at the point in our development where I have time to investigate how that could be done.

I have looked at the example code, and as far as I can tell, the bootloader would run straight after power on, which is not much use to us, as the device will be powered permanently by a battery which is not user accessible.

So I'd be interested to learn how to do this.