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

[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