• State Verified Answer
  • Replies 9 replies
  • Subscribers 63 subscribers
  • Views 6683 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 118506
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Secure DFU Bootloader ROM / RAM configurations for nRF51822_xxAA

Aply

Hi,

I have a problem with Secure DFU Bootloader available from SDK 12.1 on nRF51822_xxAA SoC. I use example in SDK 12.1 and when i download it to nRF51822_xxAA it isn't working properly. SoC isn't advertising, and when i go to Debug in Keil uVision program go instatnly to HardFault_Hander in arm_startup_nrf51.s

Initilaly i was using nRF51 DK board with nRF51422_xxAC SoC. I fallowed instruction on Nordic InfoCenter. I compiled project in Keil uVision 5 and downloaded secure dfu bootloader to SoC. Then i created zip with new program and uploaded it with nRF Connect application on Android System. Everything worked properly.

Is this a problem with memory settings? The xxAC SoC has more RAM memory (32kB) then xxAA (16kB). What is the correct ROM/RAM settings for xxAA chip. For nRF51422_xxAC correct settings are:

image description

Also on custom board with nRF51822_xxAA which i use has lack of external LFCLK source. So for correct SoftDevice initilize i create my custom_board.h and set NRF_CLOCK_LFCLKSRC to Synthesized LFCLK from HFCLK. Could it be also the reason of problem?

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_SYNTH,           \
                             .rc_ctiv       = 0,                                \
                             .rc_temp_ctiv  = 0,                                \
                             .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM}
  • 0

    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

  • 0 in reply to bjorn-spockeli

    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.

  • 0

    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

    to

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

  • 0 in reply to bjorn-spockeli

    @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
  • 0 in reply to bjorn-spockeli

    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 ;-)

Related