.bin file of Secure bootloader is too much

[R_S]

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

[Vidar Berg]

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

[R_S]

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  

[Vidar Berg]

What's the purpose of generating this bin file, is it for DFU or for programming through the debug interface. You will need to write the UICR registers separately if it's for the latter.

R_S said:

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

I usually use objcopy or hex2bin (link)

example with objcopy:

arm-none-eabi-objcopy --input-target=ihex --output-target=binary <input>.hex <output>.bin

Regards,

Vidar

[R_S]

bin I am using for Signature creation. 

But the size of that bin is very large.

and to run "arm-none-eabi-objcopy" command. which place i need to run this..?

Regards

R_S

[Vidar Berg]

The nrfutil script does this already. I.e. strips away the UICR section from the hex, converts it to a bin, and computes the signature with your private key as input. Is there are reason you can't use nrfutil?

R_S said:

and to run "arm-none-eabi-objcopy" command. which place i need to run this..?

It's from the command line. Objcopy is included in the GNU Arm Embedded Toolchain (link)

[R_S]

Actually i am using my won public key and certificate to create a signature on .bin directly. 

And i did as you mentioned by removing the UICR register from hex and then created bin file from hex by using "arm-none-eabi-objcopy" command.

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

Or anything else we can change here, so that our code directly jump to the Bootloader address..?

Can you help me here...

Regards

Rohit Saini

[Vidar Berg]

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.

R_S said:

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

[R_S]

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

[R_S]

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

[Vidar Berg]

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

[R_S]

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 

[Vidar Berg]

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