Bootloader to applocation switching issue

[mayuri]

Hi ,

I am working on NRF DFU firmware update. for that i am using secure bootloader code .

I tried with the of way of flasing bootloader code on my custom board and sent my application code through app(NRF CONNECT) .when want to change the bootloader its moving to bootmode and can able to update . its working fine..

then i tried to merge my applicartion and bootloader code ... ( in components file i took the softdevice hex file + application code hex file ) merged together usinng commad

mergehex.exe -m softdevice.hex application.hex -o new_app.hex

using the above command - my aplication working fine.... the with the new_app.hex file merged with my bootloader hex file using the command

mergehex.exe -m new_app.hex bootloader.hex -o final.hex

using the above command - got by final hex file .

using nrfjporg command flashed my final.hex file to my custom board ..

now my question is ....

in my custom board i flashed my merged file (which is my application + bootloader )

but at first time , it enters in bootloader mode only .. in my bootloader code i set 2 mins stand by time in bootloader mode .
after that it moves from bootloader mode to application mode.but it does not enter to application mode.

Once i sent my application code via app then its switching to application mode .. as i metioned above when i want to change to boot its switching to bootloader mode if i dont update my firmware ,its automatically moving to my appllication which is running before ...if i updates its updating ...

why my merged file only in bootloader mode at first ...

from my assumption it should switch to application after 2mins (which from the merged file )

Whats the issue of it does not enter into apllication mode at first time.??????

[Edvin]

Hello,

The behavior that you see is expected because the bootloader can see that there is an application in flash, but since the application is flashed directly and not via DFU (nRF Connect), the bootloader never verified that the application is signed with the correct private key. This is a safety mechanism.

Usually, when you generate a DFU image, you need to enter the private key as one of the parameters:

nrfutil pkg generate --application app.hex --application-version 1 --hw-version 52 --sd-req 0xAF --key-file private.key

This will create an image including the application, and a signature verifying that the person who generated this packet has access to the private key. When the bootloader receives this image, it will store the CRC of the application and the signature in something called bootloader settings. This means if someone changes the application in this image, the CRC will no longer match, and the singature is no longer valid. 

Luckily, there is a way to work around this. If you have access to the private key, you can generate the bootloader settings manually using your private key and merge it together with your application+bootloader, and flash it manually. Now, when this happens, the bootloader will see that the bootloader settings accepts the flashed application, and start the application as if you transferred the application via DFU.

To generate bootloader settings (bl_settings) you can use the following command:

nrfutil settings generate --family NRF52840 --application app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 --key-file private.key bl_settings.hex

(use "nrfutil settings generate --help" for more information)

now merge your hex file:

mergehex.exe -m final.hex bl_settings.hex -o final_with_bl_settings.hex

and program it using

nrfjprog --program final_with_bl_settings.hex --verify && nrfjprog --reset

And it should start the application.

Best regards,

Edvin

[mayuri]

Hai , 

 thanks for ur reply , tried as u said now its working fine ....but sometimes from apllication , its not jumpimg to bootloader mode ..

i am using the follwing command in my application part  to switch into bootloader mode 

#DEFINE  BOOTLOADER_DFU_START 0xB1    

NRF_POWER->GPREGRET = BOOTLOADER_DFU_START;

NVIC_SystemReset();

 by this way i am using this as buttonless to swtich over  ... sometimes i am having this issue ...

can you please tell me ??????

Thanks ,

[Edvin]

Hello,

I don't have much more to point to other than the documentation. 

I suggest that you check the documentation for the DFU Protocol, the Serial protocol, the Message Sequence Chart and the SLIP library to see how to transfer the objects.

We have an unofficial example that acts as a DFU master. I have not tested it, but perhaps you can look at this for inspiration.

Best regards,

Edvin

[mayuri]

hai ,

Thanks trying to transfer the objects  through ble ..i am strucking in this place to send my firmware file.

is it possible to update nrf through uart from esp32 . can you any source related on this ..??

[Edvin]

Unfortunately, we do not have any source code for esp32. We only have the protocol, so you would have to implement this yourself. 

For inspiration, you can look at the DFU Master (written for nRF52832). Perhaps you can use some of the files from that projects, but you need to use the UART drivers for esp32.

The DFU master firmware is linked to in the DFU getting started guide, close to the bottom of the page.

Best regards,

Edvin

[mayuri]

Thank for supporting   ,

 trying to work on this .... before that 

to transfer the firmware file into several objects u refered to see the slip library ..

i saw the slip library in that ,end of bytes as mentioned 300 , when i searched in my firmware file its showing lot of end byts ...i have no idea on transferring the object files ...if u have any idea on slip library and how to seperate the objects can you please tell me ??

[Edvin]

Have you checked the DFU master code? I haven't tested it myself, but it probably contains the slip libraries, and how to transfer the files already. You should be able to use some files from there in your esp project.