• State Verified Answer
  • Replies 2 replies
  • Subscribers 90 subscribers
  • Views 802 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 261823
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why do the .hex files of projects based off Secure Bootloader example write to mbr_params_page page?

tomcatty

EDIT: I incorrectly reported the Secure Bootloader pca10040_s132_ble_debug .hex file included in SDK 16.0.0 wrote to addresses in the mbr_params_page, I have since identified it is only my custom bootloader that overruns into these addresses.

Hi,

In SDK 16.0.0, when examining the generated .hex file from my custom bootloader based upon the Secure Bootloader pca10040_s132_ble_debug example, I was suprised to find addresses from 0x0007E000 and onwards written.

I found this unexpected because I thought the linker reserved the mbr_params_page page. Does anyone know what is going on here?

I found this because I was unable to merge a bootloader settings page which includes backup settings (which is located at 0x0007E00, generated with nrfutil). My workaround is using the --no-backup option, but I'd like to understand why this is happening. 

Thank you for your help.

Parents
  • +1

    I have done some more digging and found that the SES project configuration for the Secure Bootloader in SDK 16.0.0 will permit program code to be placed in the reserved mbr_params_page and bootloader_settings_page. This has resulted in my bootloader based upon the Secure Bootloader example compiling with this overrun and no warning.

    This has the rather scary effect of the bootloader overwriting any of its own program code that may be placed by the compiler in mbr_params_page and bootloader_settings_page. This is what happened to me, where the bootloader_settings_page backup (done by the bootloader at runtime, as above I can't program this page myself at manufacture) overwrote program code that caused my device to break. 

    Thankfully this seems to have been fixed in SDK 17.0.2 (perhaps as part of "SES will now return a linker error if the bootloader is too large."). Looking at the Secure Bootloader project configuration in SDK 17.0.2, this can be patched by moving the mbr_params_page and bootloader_settings_page ProgramSections out of their own MemorySegment and to the main flash MemorySegment in the flash_placement.xml. When I do this in SDK 16.0.0, I now get SES linker errors, which can be fixed by giving the bootloader another page of flash (which is also done in SDK 17.0.2).

Reply
  • +1

    I have done some more digging and found that the SES project configuration for the Secure Bootloader in SDK 16.0.0 will permit program code to be placed in the reserved mbr_params_page and bootloader_settings_page. This has resulted in my bootloader based upon the Secure Bootloader example compiling with this overrun and no warning.

    This has the rather scary effect of the bootloader overwriting any of its own program code that may be placed by the compiler in mbr_params_page and bootloader_settings_page. This is what happened to me, where the bootloader_settings_page backup (done by the bootloader at runtime, as above I can't program this page myself at manufacture) overwrote program code that caused my device to break. 

    Thankfully this seems to have been fixed in SDK 17.0.2 (perhaps as part of "SES will now return a linker error if the bootloader is too large."). Looking at the Secure Bootloader project configuration in SDK 17.0.2, this can be patched by moving the mbr_params_page and bootloader_settings_page ProgramSections out of their own MemorySegment and to the main flash MemorySegment in the flash_placement.xml. When I do this in SDK 16.0.0, I now get SES linker errors, which can be fixed by giving the bootloader another page of flash (which is also done in SDK 17.0.2).

Children
Related