• State Not Answered
  • Replies 7 replies
  • Subscribers 64 subscribers
  • Views 3702 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 240748
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52832-QFAB-R FLASH and RAM memory mapping

sboudaud

Hello,

I want to try the secure bootloader + softdevice 7.0.1 + ble app buttonless dfu example from SDK16

I want to test all that in our custom board NRF52832-QFAB (256k flash + 32k ram)

- what I found is that for softdevice I need at least 0x26000 bytes for flash and 0x1668 bytes for RAM

- The ble app dfu buttonless example size is 0xCDB0 (found wit running hexinfo.py: first: 0x00026000, last: 0x00032DAF, length: 0x0000CDB0)

- I suppose that this mean that the app mapping could be:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x12000
  RAM (rwx) :  ORIGIN = 0x20002270, LENGTH = 0x5d90
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
}

- The bootloader need 0x6000 bytes for flash, so the memory map for bootloader could be:

MEMORY
{
  FLASH (rx) : ORIGIN = 0x38000, LENGTH = 0x6000
  RAM (rwx) :  ORIGIN = 0x20003278, LENGTH = 0x4d88
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  bootloader_settings_page (r) : ORIGIN = 0x0003F000, LENGTH = 0x1000
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x0003E000, LENGTH = 0x1000
}

- In addition to the memory mapping I have to change in nrf_dfu_types.h:

FROM


#elif defined(NRF52832_XXAA)
    #define NRF_MBR_PARAMS_PAGE_ADDRESS         (0x0007E000UL)

...

#elif defined( NRF52832_XXAA )
    #define BOOTLOADER_SETTINGS_ADDRESS     (0x0007F000UL)

TO

#elif defined(NRF52832_XXAA)
    #define NRF_MBR_PARAMS_PAGE_ADDRESS         (0x0003E000UL)
...
#elif defined( NRF52832_XXAA )
    #define BOOTLOADER_SETTINGS_ADDRESS     (0x0003F000UL)

- As our custom board don't have buttons and leds I added new board:
  in board.h
  #elif defined(BOARD_PCA10040_ABW)
    #include "pca10040_abw.h"

  And changed in the make files BOARD_PCA10040 => BOARD_PCA10040_ABW

- After all changes I flashed my custom board:
$nrfjprog --program nRF5_SDK_16.0.0_98a08e2/components/softdevice/s132/hex/s132_nrf52_7.0.1_softdevice.hex --chiperase
$nrfjprog --program secure_bootloader_abw/pca10040_s132_ble/armgcc/_build/nrf52832_xxaa_s132.hex
$nrfutil pkg generate --application examples/ble_peripheral/ble_app_buttonless_dfu/pca10040/s132/armgcc/_build/nrf52832_xxaa.hex --application-version 1 --application-version-string "1.0.0" --hw-version 52 --sd-req 0xCB --sd-id 0xCB --softdevice components/softdevice/s132/hex/s132_nrf52_7.0.1_softdevice.hex --key-file private.key FW_abw.zip
$nrfjprog --reset
=> The device start advertising DfuTarg, So I start DFU by sending FW_abw.zip but after the upload finish the device still in DFU!
     Note: when tried on the Devkit (without changing anything listed before) while making the DFU process it seems that the phone sent 2 files (I suppose SD and App), but when updating the custom board the phone seems sending only one file.


Question:

1- The app flash mapping is correct?

2- The bootloader flash mapping is correct?

3- The app ram mapping is correct? can i do better than that?

4- The app flash mapping is correct? can i do better than that?

5- Beside all these change anything else to do?


Thanks by advance.

  • 0

    Hello,

    I think I found why after DFU the application don't start and my device stay in DFU:

    I set a led in pin 16 and this pin is LEDS_ACTIVE_STATE 1 so the default state is low, and I saw in pca10040.h that pin 16 is reserved for button 4 that is used to enter in bootloader mode after a reset, So I think that my device enter in bootloader because of that!

    I don't understand why this happen as I don't define pin 16 as a button! So where can I change the code in the bootloader to don't use a button to enter in bootloader mode?

    Thanks

  • 0 in reply to sboudaud

    Ok the button pin 16 was resolved by setting #define NRF_BL_DFU_ENTER_METHOD_BUTTON 0 in sdk_config.h

    If you can just help me to understand how I can configure the RAM mapping and then you can close this issue, because for the RAM I set start address like I found in some discussion but I don't know how exactly I can set it by my own.

    Thanks.

  • 0 in reply to sboudaud

    Just on thing is that when in my board I set "#define BUTTONS_NUMBER 0" when I build the secure bootloader it show this error:

    ../../../../../components/libraries/bootloader/nrf_bootloader.c:231:30: error: 'BUTTON_PULL' undeclared (first use in this function); did you mean 'BUTTONS_MASK'?

    Note that I set in sdk_config.h

    #define NRF_BL_DFU_ENTER_METHOD_BUTTON 0

    we shouldn't reach the line 231 in nrf_bootloader.c as the test below in line 436 should be invalid

        if (NRF_BL_DFU_ENTER_METHOD_BUTTON)
        {
            dfu_enter_button_init();
        }

    could you help?

  • 0 in reply to sboudaud

    Hi,

    Even though the function dfu_enter_button_init() may never be called, the compiler will still try to compile it. Since BUTTON_PULL is not defined when BUTTONS_NUMBER is 0, you get the error. This means the DFU bootloader does not work out-of-the-box when using a board with no buttons. I will report this in our internal issue tracker.

    As a workaround I suggest rewriting the if block into a preprocessor directive, as well as surrounding the definition of dfu_enter_button_init() in a preprocessor directive so that the code is only included if BUTTONS_NUMBER is not null (or maybe better if BUTTON_PULL is defined.)

    Edit: Even better, the check should be on NRF_BL_DFU_ENTER_METHOD_BUTTON, and only include the code if it is set to 1.

    Regards,
    Terje

  • 0 in reply to tesc

    Thanks for the response.

    Do you have any advice about RAM mapping for BL and APP?

Related