• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 74 subscribers
  • Views 1550 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 277869
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Memory layout for secure dfu bootloader + main application + softdevice 332 (SDK17.1.0)

jfpastrana

Hi,

Memory layout for secure dfu bootloader + main application + softdevice 332 (SDK17.1.0)

We are currently migrating from SDK 14.2.0 to SDK 17.1.0 it also affects to soft device version which we want to upload it to 7.0.1.

We are facing some problems related to memory layout, in order to not introduce more complexity, we are trying to update the following examples of the SDK 17:

  • Bootloader: pca10040_s132_ble_debug
  • Main application: ble_app_uart_c_pca10040_s132
  • Softdevice: ANT_s332_nrf52_7.0.1

We have managed to work with s132, but when we upload to s332 it throws the following error:

 

The current memory layout that we are using is (starting address and size):

  • Bootloader: [ROM]0x72000 - 0xC000 [RAM] 0x20005968 - 0xA698
  • Main application: [ROM]0x30000 - 0x5A000 [RAM] 0x20002A28 - 0xD5D8

You can find see it here:

 

Which is the correct memory layout for s332? Including the three applications? Do we have to include some missing configuration in the project?

 We do not find information about that, only for s132:

Best regards and may thanks,

Javier

  • 0

    Hi,

    Regarding the memory layout, S332 7.0.1 is 196 kB, so that means that the application should start at 0x30000, which I see you write is the case. Regarding the bootloader the start address depends on the size of your bootloader. If you are in doubt, you could move it a bit down. The main point here is that there should be two available pages after the end of the bootloader, for MBR params and bootloader settings. As long as it is, that should be fine.

    When it comes to RAM you should check the RAM start address you get when initializing the SoftDevice (as this is configuration dependent). If in doubt, just set the bootloader RAM start address higher (and size correspondingly lower). That does not have any negative impact as long as there is still enough.

    Are you migrating for S132 to S332 via DFU here, or are you testing using S332 from scratch? What is it you are doing when this fails? Is it only after a specific type of update  (say application only, or SoftDevice + bootloader) or something else? Please elaborate.

  • 0 in reply to Einar Thorsrud

    Hello Einar,

    Many thanks for your recommendation, it help to me to find few mistakes, I am going to explain them more.

    As I was migrating the SDK examples which have included the s132, I forgot to change the preprocessor symbol from S132 to S332 as it is show in the following picture:

     

    Moreover, following your recommendation about ROM and RAM size I did the following:

    • Bootloader: [ROM] 0x71000- 0xD000 [RAM] 0x20002C00- 0xD380
    • Main application: [ROM]0x30000 - 0x20000 [RAM] 0x20002F70- 0xD090

    Now it is working, but I am not sure if it is the best solution. As you can see it is some RAM memory shared between Boot and Main application, I tried to change the Main app RAM before to Boot reserved RAM but it did not work.

    Which are the RAM addresses used by s332? I have only found the following information, but it is not completely clear:

     

    Source: s332 SDS v2

    Regarding your questions, I am flashing the unit using the cmd line tools, mergehex, nrfutil and nrfprog.

    At the beginning we were migrating the examples that I showed you in my first post. However, once we found that bugs. We started the migration of our application. Therefore, we have the following environment:

    • Main APP:

    Previous -> SDK 14.2.0. s332 v5.0.0  Now: SDK 17.1.0 s332 v7.0.1

    • Bootloader (pca10040_s132_ble_debug):

    Previous -> SDK 17.1.0 s132 v7.2.0   Now SDK 17.1.0 s332 v7.0.1

    Best regards,

    Javier.

  • +1 in reply to jfpastrana

    Hi Javier,

    jfpastrana said:
    Now it is working, but I am not sure if it is the best solution. As you can see it is some RAM memory shared between Boot and Main application, I tried to change the Main app RAM before to Boot reserved RAM but it did not work.

    The bootloader and application are not active at the same time, so there is no problem using the same RAM region for both. (this is different form the SoftDevice, which is used at the same time as the application, and at the same time as the bootloader).

    jfpastrana said:
    Which are the RAM addresses used by s332? I have only found the following information, but it is not completely clear:

    The important point here is that APP_RAM_BASE is not a constant, but is dependent on configuration. From the S332 SDS: "The value of APP_RAM_BASE is obtained by calling sd_softdevice_enable, which will always return the required minimum start address of the application RAM region for the given configuration". As long as you reserve enough RAM for the SoftDevice and you still have enough for your application there is no problem. If you need to optimize in order to get more RAM for your application (or bootloader), you can do that. See Adjustment of RAM and Flash memory for details.

    Einar

Related
Terms of service