Entering DFU mode via SPI and updating firmware

RE: Entering DFU mode via SPI and updating firmware

Amanda Hsieh — Fri, 18 Dec 2020 08:05:14 GMT

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.

RE: Entering DFU mode via SPI and updating firmware

RAS_ID — Wed, 16 Dec 2020 17:13:43 GMT

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

RE: Entering DFU mode via SPI and updating firmware

Amanda Hsieh — Wed, 16 Dec 2020 13:49:26 GMT

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.

[quote user=""]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?[/quote]

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.

[quote user=""]2. Is it correct that I need to use nrf_target_ functions to initialize and write new application/MCUboot to the flash area?[/quote]

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

-Amanda H.

RE: Entering DFU mode via SPI and updating firmware

RAS_ID — Wed, 16 Dec 2020 02:26:48 GMT

Few more details on entering the DFU mode.

My west build is not entering the DFU mode, but the SES build enters the bootloader. I put the above code in the application main() to be called every 20 seconds, and the device prints the DFU messages every 20 seconds.

I don't know why the difference between the two builds.

Any suggestion is well appreciated!

Thanks,

Ram