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

[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

[RAS_ID]

Hi Jorgen,

Thanks for your reply! Really appreciate!

Before I start code modifications for the upgrade, I would like you to verify if my understanding is correct about the upgrade process. 

Please verify all the steps below and write your comment as appropriate.

1. I believe that CBOR encoding in mcumgr is done just to speed up the data transfer process. I will use the frames as per SMP for the data transfer.

Is it okay to send the binary from the master without encoding?

In that case, I will exclude packet decoding in slave before writing the data from the packet to flash-memory. 

2. The master, another MCU, will read a signed binary file (app_update.bin) and send the binary data packet  formatted as per SMP with or without encoding.

3. The slave (nRF52840 with MCUboot and a sample application) will wait for the SPI packet in the function (identical to) boot_serial_start().

Once a packet is received, slave processor will continue from line#609.

     if (in_buf[0] == SHELL_NLIP_PKT_START1 && …….

 4. If encoding was necessary (I would follow your reply in 1), and it was done in the master before sending the packet, I don't need any further changes other than commenting out the code related to serial output.

5. If encoding was not done in the master, I need to comment out the function calls related to decoding as well.

Any other comment?

Thanks,

Ram

[Jørgen Holmefjord]

Hi Ram,

Sorry for the slow response. I consulted with our developers and received some feedback on your questions.

RAS_ID said:

1. I believe that CBOR encoding in mcumgr is done just to speed up the data transfer process. I will use the frames as per SMP for the data transfer.

It is not necessary to implement/use mcumgr protocol with SPI, if you are using MCUboot in serial recovery mode. Implement your own protocol for DFU via SPI would simplify things a lot. Both base64 and CBOR encoding is not necessary for SPI transfer for instance.

RAS_ID said:

2. The master, another MCU, will read a signed binary file (app_update.bin) and send the binary data packet  formatted as per SMP with or without encoding.

As described above, it is not required to follow the SMP format, if you are using serial recovery mode. 

RAS_ID said:

3. The slave (nRF52840 with MCUboot and a sample application) will wait for the SPI packet in the function (identical to) boot_serial_start().

Once a packet is received, slave processor will continue from line#609.

     if (in_buf[0] == SHELL_NLIP_PKT_START1 && …….

In mcuboot the path that serves the serial recovery is:

boot_serial_start -> boot_serial_input -> bs_upload. bs_upload calls CBOR decoder and performs flash writes.

RAS_ID said:

 4. If encoding was necessary (I would follow your reply in 1), and it was done in the master before sending the packet, I don't need any further changes other than commenting out the code related to serial output.

5. If encoding was not done in the master, I need to comment out the function calls related to decoding as well.

Encoding is not required.

RAS_ID said:

Any other comment?

Note that the serial recovery implementation in MCUboot currently does not support updating MCUboot itself. The application can overwrite the MCUboot slot, but this would be risky, as a reset/crash may leave the device bricked. Updating MCUboot would require B0 (Immutable bootloader) with S0 and S1 slot, and you need to add support for writing either S0 or S1 in MCUboot.

Best regards,
Jørgen