DFU from SPI flash

[eyalasko]

Hi,

We're starting to develop a new BLE sensor that needs to be integrated into an existing legacy system.

The system is controlled by a 3rd party IoT board with 2G/4G cellular connectivity module.

As the system deployed remotely the only way to update the new sensor's firmware is to send it over cellular to the main controller and over UART link to the sensor.

The sensor can store the new firmware image in e.g. spi flash (or, less desired, sd card) and then do the DFU process locally from the image stored on the spi flash.

My questions are:

- What should be a recommended DFU strategy to such a use case?

- Is there any demo code for anything like this (SDK5 or NCS)?

- Can the bootloader support DFU over 2 transports - BLE and local file from spi flash? (again, both in nRF5 SDk & NCS)

- Any other advise will be greatly appreciated

THANKS

[Edvin]

Hello,

Is the SPI flash attached to the main controller or the nRF? 

This is a difficult question to give a straight answer to. DFU in NCS is quite complex. It is running on MCUBOOT, and the tool used to interact with it is mcumgr. We don't have any custom tools (other than a BLE app) on how to interact with the mcuboot. The MCUBOOT bootloader supports UART and BLE, but it is a very large project (that is used by Zephyr), so modifying it is not trivial. It really depends on how you interact with it. If you can have the main controller run mcumgr, things aren't that difficult, but we don't have any tools running it. 

You can read about the components here:

MCUBOOT: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/wrapper.html

mcumgr: https://docs.zephyrproject.org/3.2.0/services/device_mgmt/mcumgr.html

Either way, the way it is expected to work is that the main controller sort of tells the nRF what to do, and sends the application in chunks over either BLE or UART. The nRF is then capable to either update the application, or store it in flash to perform the swap later, but it really depends on what your main controller is capable of.

The story is more or less the same in nRF5 SDK. We don't support external flash for DFU purposes out of the box here, but it is a much (!) smaller bootloader, so it is probably more comprehensive to modify it to the desired functionality. Basically, the nRF5 SDK bootloader is an active bootloader, where the BLE or UART is running from the bootloader itself (that is also possible in MCUBOOT for UART, but not BLE). This means you can throw away the old application and receive the new one over UART/BLE, but if you want to read it out from an external flash, this is something that you need to implement yourself.

I think the best way to decide what approach you want to use is to test both. For the nRF5 SDK I can recommend that you check out this guide:

 Getting started with Nordic's Secure DFU bootloader, a step by step guide 

And for NCS, please try this guide:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/working_with_nrf/nrf52/developing.html#fota-updates

Test the unmodified guides, to get a bit more familiar, so you can learn the differences between the two methods.

BR,

Edvin

[eyalasko]

Hi Edvin , thanks for the comprehensive reply.

To address some of your questions:

- The main controller is pretty 'dumb'. it can support basic uart comm but can not implement any high-level DFU/mcumanager functionality.

- The expected functionality of the main controller is to push the dfu image, chunk by chunk, to the nRF sensor that will store it in the spiflash for a later spiflash-based dfu (from the bootloader)

- Carefully reading your response, it seem that going nRF5 is the way to go (given I don't have any past ncs experience and it doesn't seem the project to gain such an experience:). It will require adding spiflash driver to the nRF5 bootloader and doing some modifications to the DFU

- in such a case, theoretically, the bootloader does not need to support any transport (neither uart not ble) at all, right?

I'll play around with it and probably get back with some questions.

Thanks

[Edvin]

If the main controller is not that powerful, I would say that the nRF5 SDK bootloader is far easier to configure for your need, yes. 

So again, I suggest you just test the getting started with DFU link from my previous reply, just to get a bit familiar. 

Later, I would say that what you want to do is to generate the DFU image as it is done in the guide, but instead of transferring it from the computer via serial (UART), you should send it through your main controller. 

Then, in your application, instead of storing it in the internal flash (if you have room in the internal flash, I would recommend this for simiplicity), then you need to write code that saves it in the external flash.

Then, when you enter your bootloader, instead of waiting for someone to push the image through BLE or UART, you should copy it from the external flash, and then reset. You may want to do some validation of the new image before deleting the old application.

eyalasko said:

- in such a case, theoretically, the bootloader does not need to support any transport (neither uart not ble) at all, right?

That is correct. Only SPI for external flash. 

Originally, the application is pushed via e.g. BLE, chunk by chunk. When the transfer is complete, it will validate the image. If validation is successfull it will send the "execute" command, which will reset -> delete old application -> move new application to correct address -> reset.

I suggest you do something similar. If you validate the image in the external flash (to make sure that you don't have any bit flips or corruptions that could brick your devices), copy it into the correct address, and hook onto the "execute object" implementation. 

Best regards,

Edvin

[eyalasko]

very informative reply. THANKS  Edvin 

I will experiment with it in the next weeks and keep the questions flowing...

Thanks again