Programming nrf52840 via SPI

[RAS_ID]

Hi,

I have to program the application on an nrf52840 chip that is connected to another MCU via the SPI interface. Since I have to send the image from the MCU to program the Nordic chip, I have the following questions.

1. I should send a .hex file (used by the nRF programmer) or a .bin file (used my mcumgr)

2. I know the .hex file has the address, but I don't know if the MCU software has to read the .hex file and create SPI frames with the proper address or any other way it has to be done.

3. If I have to use a .bin file, how to get the address from a .bin file? 

Looking forward to your reply to move forward with my application updates.

Thanks,

Ram

[awneil]

Implementing a complete & reliable Hex file interpreter is non-trivial - in particular, there is no guarantee that the data will be in order.

Therefore I'd suggest not sending a Hex file!

With a Bin file, you just need to know the start address.

[Jørgen Holmefjord]

Hi,

Which SDK are you using?

You can reference the examples found in the blog post Getting started with Nordic's Secure DFU bootloader, a step by step guide. The section 6. DFU Master code contains C example projects for both SPI DFU master and SPIS bootloader.

Best regards,
Jørgen

[RAS_ID]

Hi Jorgen,

Thank you very much for your reply!

In your link, C example project for the SPI DFU master is really useful. However, I am not clear on the slave side so far. I am tying to understand it.

Let me clarify a few things first before I ask questions.

1. I am using nRF Connect SDK v1.4.0, which creates hex and binary files.

2. I have B0, MCUboot, and application code on a nRF52840-DK.

3. My application would use buttonless DFU mode.

4. Another MCU (nRF52840-DK at this time) connected to nRF52840-DK via SPI will act as a DFU master to send the application/MCUboot code. These may be signed.

5. The master will update either application or MCUboot at a time, not both together.

Could you please clarify the following?

a. Shall DFU master use the hex file or the binary file (Awneil has suggested to use the binary file)?

b. Since the device will be in DFU mode to update the firmware, I need to make the code changes in the bootloader, not in the application. Is it correct?

\ncs\bootloader\mcuboot\boot\zephyr\serial_adaptor.c and other files.

Thanks,

Ram

[RAS_ID]

Hi Jorgen,

Please see my setup and other details in my previous reply.

I looked at the SPI DFU Master code in the link provided by you. It looks straight forward and simple.

-Will it work for a hex file, if we needed to send the hex file to update the firmware?

-Will it work to send a binary signed application if we needed to send the binary file?

On slave:

The example code in link has functions to receive SPI packets and send reply. There is nothing beyond that. Please correct me is I am missing anything.

Presently, MCUboot in ncs supports upgrades through serial interface (see main.c),

BOOT_LOG_INFO("Enter the serial recovery mode");
rc = boot_console_init();
_ASSERT(rc == 0, "Error initializing boot console.\n");
boot_serial_start(&boot_funcs);

My plan was to replace the two functions above with spi_init() and boot_spi_start() to initialize and read data over SPI and write to flash location identified by the type in the first SPI packet. 

Is this the right way to do, especially with the signed binary file? Please suggest.

Thanks,

Ram

[Jørgen Holmefjord]

Hi,

The code in the link I posted is intended to use with nRF5 SDK and the Secure DFU Bootloader, not with nRF Connect SDK. This is why I asked which SDK your are using. I'm not sure how easily transferable these examples are to nRF Connect SDK and MCUboot.

RAS_ID said:

a. Shall DFU master use the hex file or the binary file (Awneil has suggested to use the binary file)?

The nRF5 Secure DFU solution uses a ZIP-package generated by nrfutil, which includes the bin-file along with a manifest (json-file) and init-packet (dat-file).

RAS_ID said:

b. Since the device will be in DFU mode to update the firmware, I need to make the code changes in the bootloader, not in the application. Is it correct?

\ncs\bootloader\mcuboot\boot\zephyr\serial_adaptor.c and other files.

Yes, that sounds reasonable. However, if you are using multiple Image Slots, you may also be able to fill a new slot from the application (background update), and only use the Bootloader for the Image Swapping part.

I believe that you should use the same packet format as the console example if using MCUboot. The following links should provide some useful information:

• MCUboot Boot Loader
• SMP Server Sample
• SMP over Console

Best regards,
Jørgen