Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
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

.bin file of Secure bootloader is too much

Hi,

I am using nordic52840 development kit board. and I am using sdk17.1 for development.

I tried to create .bin for secure bootloader code inside DFU. but the file size is very large. for my case its around 261MB.

Can any one help me here that why i am getting this much size for binary.

For hex its only 141KB.

Regards

Rohit Saini

Parents
  • Hi Rohit,

    Please see my answer in this thread: https://devzone.nordicsemi.com/f/nordic-q-a/47903/noload-directive-for-uicr_bootloader_start_address-and-uicr_mbr_params_page. The large file size is caused by byte padding needed to offset the UICR data that is part of the bootloader image.

    Best regards,

    Vidar

  • So looks like I need to remove the content related to uicr register from hex file and then creating bin file from it.

    Now,

    So in this case do i also need to program UICR register separately or not....?

    And also to creating .bin from .hex which command need will be used....?

    Regards

    Rohit Saini  

  • I am using nrfjprog only to flash my chip. And also i am using .hex file for programming.

    .bin is only used for creating signature separately.

    Writing UICR with nrfjprog
    
    > nrfjprog --memwr 0x10001014 --val <bl_start>
    
    > nrfjprog --memwr 0x10001018 --val <mbr_param_page>

    But this process will be manually right. First need to build the code then remove the UICR content from the .hex file. 

    creating .bin based on that hex file and then i need to create the signature on that bin. 

    Is it possible to avoid this much manually intervention..?

    Regards

    Rohit Saini

  • And i have one more doubt.

    LIke i am erasing the flash then loading softdevice code. and then my Blinky application code which started from 0x27000 location in flash.

    nrfjprog.exe --family NRF52 --eraseall

    nrfjprog --program s140_nrf52_7.2.0_softdevice.hex  --family NRF52 

    nrfjprog --reset --program blinky_pca10056.hex --family NRF52  

    once it reset the LED start Blinking. 

    That means its jumping to the 0x27000 memory location. But my question is how he knows that this location it need to jump.

    Because when i did same for the open bootloader code. I created the hex file and i deleted the uicr Address register from hex file and then performed below steps.

    nrfjprog.exe --family NRF52 --eraseall

    nrfjprog --program s140_nrf52_7.2.0_softdevice.hex  --family NRF52 

    nrfjprog --reset --program open_bootloader_usb_mbr_pca10056.hex --family NRF52

    But in this case its not jumping to my bootloader code. why is that so. why in blibky application its jumping from mbr to its location(0x27000) but for open bootloader code its not jumping to its loaction(0xBE000)....?

    How it knows in case of blink application code and not in Bootloader code...?

    Regards

    Rohit Saini

  • OK, so you should not have to set the UICR registers if your are programming the .hex.

    R_S said:
    .bin is only used for creating signature separately.

    Yes, and for DFU.

    R_S said:
    Is it possible to avoid this much manually intervention..?

    You will have to decode the intelhex format somehow before you can compute the signature. But this is usually something you will automate through a script (shell, python, etc), so not something you should have to do manually.

    R_S said:

    How it knows in case of blink application code and not in Bootloader code...?

    The MBR will jump to the bootloader on startup if it sees the bootloader address at 0x10001014 or 0xff8. Please see the "Master boot record and SoftDevice reset procedure"  section of the Softdevice specification for more details.

    Regards,

    Vidar

  • But Right now i am removing the UICR data from my hex file.

    in this case its not jumping to the bootloader part.

    And I checked the link you shared. But one thing again i didn't understand that where exactly in bootloader we are assigning the address to the UICR register. 

    one place is this i know.

    That means without including the UICR register in hex file we cant jump to the bootloader location from the MBR..?

    Regards

    Rohit Saini 

  • Yes, you have to program the original bootloader hex that has the UICR data at 0x10001014 and 0x10001018. The MBR will not start the bootloader if this data is missing.

    The start address is set here as you said:

    And the MBR paramater page address at 0x10001018 here:

        __root uint32_t const m_uicr_mbr_params_page_address
            @ UICR_PARAM_PAGE_ADDR = NRF_MBR_PARAMS_PAGE_ADDRESS;

    Regards,

    Vidar

Reply
  • Yes, you have to program the original bootloader hex that has the UICR data at 0x10001014 and 0x10001018. The MBR will not start the bootloader if this data is missing.

    The start address is set here as you said:

    And the MBR paramater page address at 0x10001018 here:

        __root uint32_t const m_uicr_mbr_params_page_address
            @ UICR_PARAM_PAGE_ADDR = NRF_MBR_PARAMS_PAGE_ADDRESS;

    Regards,

    Vidar

Children
Related