Secure bootloader - SDK12.2.0

[kagislason]

While using the secure bootloader image and test application works consistently using the development kit I have not been able to port the solution reliably for our custom PCB. I suspect the image generation is done incorrectly on my behalf.

Tools used

1. NRF52832
2. Softdevice S310 v3.0
3. SDK v12.2.0
4. nrfutil version 2.0.0
5. mergehex version: 8.0.0
6. nRF Toolbox 4.2.0

I created a hex file containing SD132 v3 and the secure bootloader. The secure bootloader is slightly modified to look at GPREGRET to see if my main application has flagged the bootloader.

During first start the bootloader is alive and I can successfully upload my main application using nRFToolbox app. The application starts correctly.

I restart the device into bootloader mode but using the same hex file the CRC fails after the download/copy process.

 0> :INFO:CRC computation: Main app start: 0x0001f000, img size: 104884
 0> :INFO:CRC computation failed for copied app: src crc: 0x6ae723ad, res crc: 0xb3b939d

During the third attempt the same hex file is accepted and the device is live again.

 0> :INFO:Setting app as valid
 0> :INFO:CRC computation succesful: src crc: 0x6ae723ad, res crc: 0x6ae723ad

When I compare the log for run 2 and 3 I see there is a restart in the middle of the erase/write process after the download, this happens always in the same spot.

 0> :INFO:2 Target address: target_addr: 0x00041000, src_addr: 0x464e493a
 0> :INFO:Erasing: 0x00027000, num: 1
 0> :INFO:Erasing: 0x00041000, num: 1
 0> :INFO:Erasing old settings at: 0x0007f000
 0> :INFO:Erasing: 0x0007f000, num: 1
 0> :INFO:Writing 0x00000057 words
 0> :INFO:Writing settings...
 0> :INFO:Erasing: 0x00028000, num: 
 0> :INFO:Inside main
 0> :INFO:In nrf_bootloader_init

I have a feeling that this might be due to bootloader settings but I have not been able to generate the correct settings. I tested builing a settings file for the application but when I try to install that with DFU I get a error message stating the application is too big and will not fit.

 0> :INFO:Image verified
 0> :INFO:DFU REGION TOTAL SIZE: 344064
 0> :INFO:DFU APP DATA RESERVED: 12288
 0> :INFO:FREE SIZE: 331776
 0> :INFO:Enter nrf_dfu_find_cache
 0> :INFO:No way to fit the new firmware on device
 0> :INFO:Prevalidate FAILED!

These are the app settings that I merged with the same firmware.hex file that works every other time:

Bootloader DFU Settings:
* File:                 app-settings.hex
* Family:               nRF52
* CRC:                  0x4DE475AF
* Settings Version:     0x00000001 (1)
* App Version:          0x00000001 (1)
* Bootloader Version:   0x00000001 (1)
* Bank Layout:          0x00000000
* Current Bank:         0x00000000
* Application Size:     0x000199B4 (104884 bytes)
* Application CRC:      0x7B0FA160
* Bank0 Bank Code:      0x00000001

Any suggestions?

Thanks.

[WestCoastDaz]

kagislason,

Do you have the watchdog turned on? If so you need to keep kicking it in the boot loader.

Also, are you willing to share the changes you made to return to using GPREGRET? I'm just about to do this on our design.

Cheers

[kagislason]

This was indeed a watchdog issue, thanks!

I was not aware that the watchdog would keep running after a soft reset. I had already done a WDT reload in the wait_for_event() function but I fixed the issue by also kicking the dog while processing the new firmware. I don't like modifying SDK files (for future updates and clarity) so I will try to find a more elegant solution.

[kagislason]

As for the GPREGRET solution I set the register in my main application when receiving a firmware update request from our iOS app. This feature is protected with user roles and then using a unique static pin code/MITM protection.

On the application side I set the register and then call my power reset function (housekeeping then restart):

sd_power_gpregret_set(0, (uint32_t)BOOTLOADER_DFU_START);

In the bootloader I override the __WEAK nrf_dfu_enter_check() function. I removed the button/flash logic and added a check for GPREGRET:

   if (NRF_POWER->GPREGRET == BOOTLOADER_DFU_START)
   {
      NRF_POWER->GPREGRET = 0;
      return true;
   }
   return false;

[WestCoastDaz]

kagislason,

Thanks for the help, I really appreciate it!

As for the WDT issue I'm glad I was able to help. Beware Nordic's implementation of the WDT is very different that anything I have used in previous micro's. Once it's turned on it can't be turned off via software! It can only be stopped by a hardware reset or BOR/PUR.

[WestCoastDaz]

kagislason,

I am I correct in assuming that you either rewrote or modified ble_dfu.c to achieve the desired functionality? You said "On the application side I set the register and then call my power reset function (housekeeping then restart):" Where did you add this functionality, did you care about the bond data?

[kagislason]

Sorry for the late answer, did not get a notification of this comment.

I added this to my main application, after receiving a firmware update request from the central I set the GPREGRET register as "some hex code" and then restart the chip. Afterwards it wakes up in bootloader and checks if NRF_POWER->GPREGRET == "some hex code", if so I start DFU else boot up into main.

As for the bond information I did not implement anything there for now, I will need to take another spin at this soon.

Hope this helps.