Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

bjorn-spockeli — Mon, 18 May 2020 06:47:56 GMT

Which SDK and SoftDevice version are you using? What RAM and ROM configuration are you using?

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

mac — Sat, 16 May 2020 11:08:33 GMT

Hi,

can you give me the final configuration of RAM,ROM for your custom board and the SDK (and sofdevice) version used?

I've same problem with my board (I'm using a module nRF51822_04AT xxAA ) but the upload procedure stops immediatly , DfuTargs service seems active but I think to have some problem with stack and heap.

To build the bootloader I've reduced Heap to 0x500 and stack to 0x600.

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

sosse — Thu, 06 Jul 2017 07:05:43 GMT

Here is much simple way to implement secure bootloader without changing the RAM/ROM size. https://github.com/CHAKAK/bootloader_secure_custom

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

bjorn-spockeli — Tue, 04 Apr 2017 09:18:32 GMT

@rogerclark: Its to late to add this to the SKD v13 release as it is already out and we're not going to do another SDK v12.x.x release. However, I will report this internally and hopefully its added in a future release, but keep in mind that the Secure Bootloader is not really designed for the nRF51x22 xxAA variants. I will update my answer with the correct RAM settings. :)

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

Roger Clark — Thu, 02 Mar 2017 02:28:36 GMT

Bjørn

Would it be possible for you to fix this in either SDK13 or if you release another version of SDK12, by either setting the QFAC address to the same as you indicated above, and using LENGTH of 0x5A20, as I presume there are no negative side effects of just optimising the RAM start and length

Otherwise people will need to do what I've had to do, which is to search for some time to find this comment.

You could update to update the answer to include the QFAA values, as that would make it slighly easier to find.

PS. I know I could edit your answer, but I don't feel comfortable doing that, as I'm not an expert like you are ;-)

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

bjorn-spockeli — Wed, 04 Jan 2017 14:49:39 GMT

@derpmo: I managed to compile the Secure bootloader for a nRF51 variant with 16kB RAM by lowering the RAM start address. The SoftDevice returns the application ram base address in the app_ram_base parameter given to sd_ble_enable. Thus, if you debug the Secure Bootloader and set a breakpoint after sd_ble_enable and add a watch to app_ram_base, you will see that the application RAM start address can be set to 0x200025E0 and the size can be set to 0x1A20, i.e.

RAM (rwx) :  ORIGIN = 0x200025E0, LENGTH = 0x1A20

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

Aply — Wed, 04 Jan 2017 12:41:14 GMT

Hi,

Finally I solved the problem. It wasn't a problem with the ROM/RAM settings or lack of external LFCLK on my custom board with nRF51822_xxAA SoC. I was analyzing code line by line and i detected that the problem was made by Scheduler. Scheduler Queue Size was to big.

To solve this problem was enought to reduce the size of Scheduler Queue. In file nrf_dfu.c need to be changed line 28 from:

#define SCHED_QUEUE_SIZE                20

#define SCHED_QUEUE_SIZE                10

Due to this change secure bootloader work properly on my custom board, I was able to download new application with nRF Connect on Android.

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

DerPMO — Wed, 04 Jan 2017 09:44:02 GMT

Hi Bjørn,

I've ran into the same problem, but am using armgcc to compile the bootloader. On the nRF51 DK everything works fine, but I wasn't able to get it to work (at first) on my BlueEva+S which is also based on the nRF51822 xxAA.

I assumed that I could just copy the values you provided into my linker script, whis is included in the example in SDK 12.2.0.

But RAM seems to be too small, it won't link that way, the stack with size 0x800 doesn't fit. The absolute minimum value for RAM length is 0x14AC, which makes the origin 0x20002AD4 when also leaving the space for the NOINIT region of length 0x80 (origin at 0x20003F80).

I haven't checked SDK 12.1 or the arm compiler, so I don't know why this extra space is needed, but thought I leave this here for future reference.

RE: Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

bjorn-spockeli — Wed, 21 Dec 2016 11:54:07 GMT

Hi Aply,

I managed to compile the Secure bootloader for a nRF51 variant with 16kB RAM by lowering the RAM start address. The SoftDevice returns the application ram base address in the app_ram_base parameter given to sd_ble_enable. Thus, if you debug the Secure Bootloader and set a breakpoint after sd_ble_enable and add a watch to app_ram_base, you will see that the application RAM start address can be set to 0x200025E0 and the size can be set to 0x1A20, i.e. the correct ROM/RAM settings for the Secure Bootloader on a nRF51822 xxAA variant are:

IROM1 Start: 0x3A000 Size:0x5000
IRAM1 Start: 0x200025E0 Size: 0x1A20

Is there a specific reason to why you're using the synthesized LFCLK instead of the internal RC oscillator(RCOSC)? Synthesizing the LFCLK from the HFCLK source will keep the 16MHz running at while the chip is in sleep mode(System On: Low Power), i.e. its not going to be low power anymore.

I would recommend using the NRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATION as clock source if your device is a battery powered device.

Best regards

Bjørn