Bootloader to applocation switching issue

RE: Bootloader to applocation switching issue

Edvin — Mon, 27 Jan 2020 08:25:43 GMT

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.

RE: Bootloader to applocation switching issue

mayuri — Fri, 24 Jan 2020 12:36:07 GMT

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 ??

RE: Bootloader to applocation switching issue

Edvin — Fri, 24 Jan 2020 07:55:07 GMT

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

RE: Bootloader to applocation switching issue

mayuri — Fri, 24 Jan 2020 05:06:09 GMT

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 ..??

RE: Bootloader to applocation switching issue

Edvin — Mon, 13 Jan 2020 09:04:12 GMT

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

RE: Bootloader to applocation switching issue

mayuri — Sat, 11 Jan 2020 05:13:00 GMT

thanks , now its working fine ...

now i am tryingto update nrf52840 from my third party (esp32)

i am able send to init packet and receiving response as per the dfu protocol .

i am strucking in sending my bin file ... my question is how to send the bin file as 12 objects from my third party ??

In nrf connect application when send as zip file ,gets parsing first its sending init packet which is dat file and then parsing the bin file as 12 objects ..and for each objects calculating crc and its updating ...

can you please tell me ??

RE: Bootloader to applocation switching issue

Edvin — Wed, 08 Jan 2020 10:16:41 GMT

If you call:

NRF_POWER->GPREGRET = BOOTLOADER_DFU_START;
NVIC_SystemReset();

right after one another, it may not actually get time to write to the register before the reset. Try to add a small delay between the two (you can use nrf_delay_ms(10); ). Does that work?

RE: Bootloader to applocation switching issue

mayuri — Wed, 08 Jan 2020 09:18:35 GMT

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 ,

RE: Bootloader to applocation switching issue

Edvin — Tue, 07 Jan 2020 09:22:16 GMT

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