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  

  • The UICR registers used by the bootloader are only meant to be written once when you first program the device. They cannot be included a DFU image.

    Now i question. How many ways we can write the data into UICR register..?

    What are you currently using for programming the chip? nrfjprog, jlink commander, or something else? Also, it is a must to use the .bin file for programming, or can you use the .hex?

    Writing UICR with nrfjprog

    > nrfjprog --memwr 0x10001014 --val <bl_start>

    > nrfjprog --memwr 0x10001018 --val <mbr_param_page>

    Regards,

    Vidar

  • 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 

Reply
  • 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 

Children
Related