Bootloader nRF52

[Arepa]

Hi all,

I am trying to "add" the DFU bootloader to my application and I have some questions regarding it:

my thought are:

1. add to DFU bootloader example code, part of my code adding the BLE capitability

-my code will run normally until the button is pressed to jump to the bootloader and perform the DFU

2. add the DFU service to my current project and add the device manager, and more required libraries.

which option is most viable?

Update 03/06/17:

Softdevice $132

SDK 12.2

How can I swith from my aplication to the bootloader?

Thanks

[Hung Bui]

Hi Arepa,

I don't think option 1 would be a very good one. With this option, you have to do "bootloader update" whenever you want to update your firmware. Application update option has no use. When you do bootloader update, you are limited to the size of the bootloader which is written in UICR and can't be changed.

Option 2 is much better one.

You should consider Option 1 only when you want to do background DFU, where you device functional normally when you are receiving DFU. But this requires lots of change in the bootloader and on how to integrate it with your application.

[Arepa]

Hi Hung, Option 3 could be... Use the base DFU example and keep own my aplication apart.

I mean program the DFU example to the nRF52

Program my own apllication so doing the aplication jump to the DFU bootloader

I am adding on my aplication:

	err_code = sd_power_gpregret_clr(0, 0xFF);
APP_ERROR_CHECK(err_code);
err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);

APP_ERROR_CHECK(err_code);

sd_nvic_SystemReset();   

NRF_POWER->GPREGRET = BOOTLOADER_DFU_START;

NVIC_SystemReset();

at the moment I am able to flash the bootloader, aplication and softdevice to my nRF52 but It keeps stuck on the bootloader, I am able to make the DFU, but it still keeps in the bootloader. Is it related to the bootloader settings? or BOOTLOADER_SETTINGS_ADDRESS?

[Hung Bui]

Hi Arepa,

Which bootloader are you using ? If you are using SDK v12.2, there is no device manager library needed.

I don't see the difference between option 2 and option 3.

I would suggest you to test first with just the softdevice and the bootloader, try to do a DFU update with it. Please follow the documentation on how to do DFU. I assume you updated the bootloader with the public key you generated.

You don't need to modify your application to add anything related to the DFU bootloader if you don't plan to have buttonless DFU update.

To be able to flash all three softdevice, bootloader, application using your programmer (instead of DFU ) you need to generate the bootloader setting using nrfutil.exe tool. This is because the bootloader will check in the bootloader setting to see if a valid application if flashed and if CRC is matched.

After you have everything running you can start to add the buttonless option, which is writing to a flag in the bootloader setting and trigger a soft reset after the flash writing is finished. Please have a look at enter_bootloader() function in experimental_ble_app_buttonless_dfu example.

(Writing to GPREGRET was the way to enter bootloader in SDK v11 and earlier)

[Arepa]

Hi Hung,

I am using secure bootloader programing just the softdevice and the bootloader. The DFU works using my application with the public key I generated.

Inside my application itseft has nothing related to buttonless DFU so I am trying to jump to the bootloader to add buttonless DFU update or just initializate the bootloader_secure using the code I posted above (bad it only works for SDK11 and earlier :( ). Now I am looking at enter_bootloader() but it looks I have to include the ble_dfu to my project and the related items I want start the DFU bootloader from the application not using the DFU service.

[Arepa]

Hey Hung,

Please correct me If I am wrong:

inside the app I am setting flags using gpregret and softreset

I edited the Bootloader_secure to check for the flags I put in the app for perform the DFU

[Hung Bui]

Hi Arepa,

Yes you can do that also. This requires you to modify the bootloader. The reason I suggested you to follow what we did in SDK v12 is for the compatibility with the future bootloader. But if you are OK with modifying the bootloader, then what you do is totally fine.