WDT & Bootloader: Multiple definitions of `WDT_IRQHandler'

[Nick_RA]

So I'm trying top add a bootloader+DFU to allow f/w updates via UART on my custom  board.

I'm already successfully using WDT in my app. Now I'm looking down the rabbithole of trying to integrate code from docs and/or examples into my own...

Using the example secure_bootloader_uart as my template for DFU, I've added the nRF-Bootloader files & updated the user include directories. But it seems that the bootloader WDT is duplicating driver WDT

nrf_bootloader_wdt.o: In function `WDT_IRQHandler':
nrf_bootloader_wdt.c:73: multiple definition of `WDT_IRQHandler'
\modules\nrfx\drivers\src/nrfx_wdt.c:61: first defined here

I'm not even sure if I need WDT support? Because my custom board has no buttons or LEDs I'll be using sd_power_gpregret_set() followed by a NVIC_SystemReset() - won't that clear the WDT anyway?

[Hung Bui]

Hi Nick, 

I'm not so sure what you are planning to do.  If you want to add DFU support to your device you don't need to modify the application. 
Please follow the documentation or you can follow my step by step guide here.
The bootloader is compiled and flashed as separated application to your application. 

The bootloader handle WDT automatically, so you don't really need to do anything. (you don't need to integrate the bootloader code into your code)

[Nick_RA]

OK, that makes sense.

As I mentioned, I do need to trigger the DFU from my application though as these will be installed at remote online  locations, so I'll still need to set the gpregret register.

I may not be able to check out your guide for a few days but I will update this ticket when I do.

Thanks

Nick

[Hung Bui]

Hi Nick, 

Sorry for the confusion. Let me try again. 

- You don't need to modify the bootloader.

- You need to modify the application if you are converting it from using S132 to S112. You need to change where you set the start address of your application. Again , this is only in your application. No modification in the bootloader. If your application is already working with S112 then you don't need to do anything. 

[Nick_RA]

Hi Hung

I think we've got out of sync in this thread

So, let me just reset...

My main application is built using S112. It's working, and I do not want to change it.

The example bootloaders provided for 10040 are only written for S132. so I need to change the bootloader not the application (as per your suggestion earlier when I was using 10040e example) to use with my application/softdevice.

I've rebuilt the secure bootloader changing the softdevice prefix, include folders etc according to your advice, it boots fine and the DFU actually transfers now, but the system crashes afterwards. So obviously the new image is being loaded incorrectly.

So I'm still at the stage where I need to tweak the bootloader to work with the application+S112 which I assume is defining flash addresses.

Hope this makes sense!

Regards

Nick

[Hung Bui]

Hi Nick, 

Sorry it's my mistake. I was thinking about the application address that you don't need to modify on the bootloader. The only thing you need to modify is to change from using S132 header to S112 header. In particular you need to change these to s112: 

And change this to S112: 

I noticed that you set the FLASH_START address to 0x19000. It's not correct, keep all of them as they are:

If you still have issue, please give us more info on how it crashed and have you checked if it crashed in the bootloader or in the application. 

[Nick_RA]

Hi Hung

Happy to say it works now! I can perform DFU over BLE on both NRF52DK and my custom board. All I need to do now is add UART transport but I'm hoping that should be a relatively simple task now I have a working platform...

Thanks for your help and patience - I admit this one has dragged on a bit!

Regards,

Nick

[Hung Bui]

Hi Nick, 
I'm glad that it's working now. It should be straight forward to add UART transport. As far as I remember it's suggested to initialize UART before BLE . You can have a look at this case.