Entering DFU mode via SPI and updating firmware

[RAS_ID]

Hi,

My application needs to enter DFU mode based on a command from another device connected via SPI.

I see that I could use the following two statements once the application receives the SPI command. This resets the device but the device doesn't enter in DFU mode.

            NRF_POWER->GPREGRET = 0xB1;

            NVIC_SystemReset();

I also learned that I need to modify the bootloader code to enter the DFU mode. Which file do I need to update? Is it  \ncs\v1.4.0\bootloader\mcuboot\boot\zephyr\main.c?

On updating the application/MCUboot via SPI interface, 

1. Do I need to enable the SPI in my application prj.conf file to use the SPI functions to read data from the SPI bus?

2. Is it correct that I need to use nrf_target_   functions to initialize and write new application/MCUboot to the flash area?

Thanks,

Ram

[Amanda Hsieh]

Hi Ram, 

There are two possible places where you can drive DFU (in mcuboot or in the application).

Do you want 1) DFU to be served by the application, or 2) DFU served by mcuboot serial recovery protocol?

For 1) firmware download might be a background process and bootloader works as dual-bank, previous app recovery is possible if new couldn't run.

For 2) bootloader does the update directly to the executable bank (if it is only possible DFU channel, no sense to have collection bank at all), but if the download is corrupted - no recovery possible, the app has to be downloaded again.

1. Do I need to enable the SPI in my application prj.conf file to use the SPI functions to read data from the SPI bus?

Yes, One of my colleagues has an SPI sample on his personal Github account: https://github.com/Rallare/fw-nrfconnect-nrf/tree/nrf9160_samples/samples/nrf9160/spi

While it was written for the nRF9160, it should work without any modifications for other nRF devices (though the device might use different pins). Note that it has not been updated in a while, so it might not work on newer versions of NCS without some modifications.

2. Is it correct that I need to use nrf_target_   functions to initialize and write new application/MCUboot to the flash area?

You might use dfu_target_  API in your SPI protocol implementation in the application.

-Amanda H.

[RAS_ID]

Hi Amanda

Thanks for your reply! Appreciate it!

Presently, we are looking for option 2. The main application will initiate the DFU mode (using GPREGRET and System reset) but it will be served (processed) by the bootloader to overwrite the application.

I will look into SPI samples from the link provided by you. Thanks!

Also, I have seen the bootloader's main(), and there are these two functions, which I think, are responsible to do the upgrade. Is it correct?

rc = boot_console_init();
__ASSERT(rc == 0, "Error initializing boot console.\n");
boot_serial_start(&boot_funcs);

Since we would be using only SPI interface to update the firmware, it it okay to replace the two functions with the SPI functions to initialize the interface and upload the firmware?

Yes, I would use dfu_target_   APIs to update the target. While these APIs are listed as dfu_target_  , but one API is listed as nrf_target_image_type() in the DFU library documentation, and I picked this one in my message earlier.

Thank you very much!

Ram

[Amanda Hsieh]

Hi Ram, 

Yes. eventually, you can replace only the 1st one and re-work serial_adapter.c for spi. 

boot_serial_start(&boot_funcs) implements whole dfu protocol, compatible with the mcumgr. serial_adapter.c implements uart or Usb-serial communication backends. We have also embedded mcumgr client sample (https://github.com/nrfconnect/sdk-nrf/tree/6fdb224718bce0590aaff1ff5e3a9767dcac8d9d/samples/bluetooth/central_dfu_smp) in NCS. which might be modified to be spi counterpart on the second device.

If you need further support, please create a new support case. I will start the holiday next week. 

Merry Christmas & Happy new year.

-Amanda H.