Information on how to perform a FOTA update on nRF52811

[keegretupmoc]

Hello,

I am looking for information on how to perform a FOTA update on our nRF52811 BLE chip.  I have some information in general about some of the options on nRF52* but I haven't seen anything specific to the 52811.

We have a board with the nRF9160 and nRF52811.  The two are connected via a UART connection.  The 9160 has an SPI external flash (MX25L25645G), the 52811 does not have external flash.  We are using the NCS 2.0.0 currently.

So the question is what are our options for being able to do a FOTA update?  From the docs I have already read it seems like we would not be able to have two partitions and would have to flash to one directly.  I know this isn't the best way, but at this point, this is where we are and when we redesign the board we can make some upgrades.

Since I don't specifically know what options are available for the 52811, I can't really figure out what to try.  Some of the docs that I was sent talked about setting up the other partition on external flash.  Like I said, the 9160 has flash, and I know the 52811 has 2 SPI's.  Is it possible to wire up one of the 52811's SPI's to the flash along with the 9160.  I'm not an EE so not sure if that would even work.  It's probably not the best idea.  I was thinking of we could have different regions available only to the 9160 and the 52811, and maybe a shared region.  Not sure if if that is possible (I am asking internally as well).  Then the 9160 could download the new FW for the 52811 onto the external flash and notify the BLE chip it was there via the UART?  Again, maybe that sounds crazy.  Or if it can download via BLE on a service.

While we are at it, if you have any docs on trying to trim down the size the app is taking on the 52811, that would be good as well.  We are not trying to do anything fancy right now with the BLE like bonding, encryption, etc.  I would like to see how small I could get the app because it takes up probably 85% of the flash already and I have a feeling if there are options to enable FOTA on the 811, they are going to take up some space as well.

Looking forward to hear what you have to say.  Hopefully you aren't laughing too hard...

h.

[Sigurd Hellesvik]

Hi,

Which interfaces connect the nRF52811 and the nRF9160?
How will they communicate in normal operation?

When you say FOTA: you mean over LTE and not over Bluetooth LE, right?

Regards,
Sigurd Hellesvik

[keegretupmoc]

Sigurd,

They are connected by a UART.  On the 9160 it is UART1 and on the 52811 it's UART0 I believe.  We have this working one way so far, from 9160 to BLE sending text.

As far as how we would upgrade the FW on the 52811, I am looking for any and all ways, so it could be LTE and/or Bluetooth LE.  It would probably be better if it were Bluetooth LE as we do have an iOS app that connects to us and there will be situations where the LTE is not activated.

h.

[Sigurd Hellesvik]

Hi,

I have an unofficial GitHub repo explaining bootloader concepts for MCUboot. Have l look at that to see which options for DFU you have in the nRF Connect SDK.

You want to be able to update both the nRF52 and the nRF91.
And you want to download the updates over Bluetooth Low Energy (LE) and/or LTE.

So I do two things:

• Suggest another solution.
• Discuss your solution

Ultimately, it will be up to you to decide what you want to do.

SMP Client on the nRF9160

I think it makes sense to have 1 of the nRF microcontrollers be a "DFU host".
Then the other microcontroller just receives the DFU.

As the nRF9160 has an external flash, I suggest that you use the nRF9160 as the DFU host.
In that case, the flash layout would look like the following:

Then you can run Serial Recovery on the nRF52.
Since the nRF52811 has limited flash space available, I think Serial Recovery is a good idea.

To write the updates from the nRF91 to the nRF52, you can run an SMP Client over UART on the nRF9160.
The downside is that you have no official SMP Client over UART.
you also do not have an unofficial SMP Client over UART yet.
However, I am working on one at https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/client_smp/smp_client_uart.

Next up you need to download the updates.
Since the nRF9160 is the host, you can download images over LTE and save them to its external flash.
I do not have a lot of experience with LTE, so I can not say exactly how, but I guess it would be similar to our Serial LTE Modem (SLM) FOTA.
Headsup: I think that the SLM use the DFU Target library, which reads the header of a DFU package, and applies this to the application core if MCUboot is detected. You might need to implement something to make it detect MCUboot updates for the 52.

To download packages over Bluetooth Low Energy (LE), you need some way to receive packages to the nRF91 via the nRF52.
As with the LTE download, you also need a way to differentiate the 52 and 91 updates, and this might have to be handled by the application.
The way I see it, you have two options for nRF52-applications:

1. Stand-alone application:
   You need some custom way to receive updates and forward them to the nRF91.
   Could be based on a SMP Server over Bluetooth LE. However, this will not forward images by default.
2. hci_uart:
   By running the hci_uart on the nRF52, you can use it as a Bluetooth LE Controller, while having the Bluetooth LE Host running on the nRF91.
   Headsup: When I build this sample for the nRF52840dk_nrf52811, I get errors due to too little flash. You likely have to do some Memory footprint optimization to make it work.
   But it would be a good idea to test this memory optimization before going for this solution
   In our LTE Sensor Gateway sample, the nRF9160 runs as Bluetooth LE Host.
   Then you receive the DFU Image  "directly" to the nRF91.
   The downside here is that all your other Bluetooth LE operations also will have to use the nRF91 as a Bluetooth LE Host for all other Bluetooth LE operations, I think.

To sum it up, I will list the parts that you need.
I will split the FOTA into two parts: Download Image and Perform Update.

• Download Image:
  • Bluetooth LE, either A or B:
    • A: Custom transfer application on both nRF91 and nRF52
    • B:
      • nRF52: Bluetooth LE Controller (Example: hci_uart)
      • nRF91: Bluetooth LE Host (Example: LTE Sensor Gateway)
  • LTE, download images from LTE (Example: SLM)
• Perform Update:
  • nRF91:
    • MCUboot: Will swap nRF91 application if Secondary is tagged with "test"
    • SMP Client over UART: Will update nRF52. (Example: SMP Client over UART under construction)
  • nRF52:
    • MCUboot with Serial Recovery: Can trigger Serial Recovery on boot. (Example: My unofficial Serial Recovery Samples)

Shared External Flash

Depending on how you design your project, using a shared external flash as you suggest may be easier and better than my solution above.
The main downside is that it requires changes to hardware: You need to connect the external flash to the nRF52811.
I talked to a colleague about this, and he reported to have found that the nRF52810 has too little RAM for use with External Flash.
Before you go for this solution, make sure to test the nRF52811 with an external flash, to find out if it is even possible!

The software design is easier here, as MCUboot will have two slots for both the nRF52 and the nRF91: nRF52 Primary, nRF52 Secondary, nRF91 Primary and nRF91 Secondary:

While booting, the respective nRFs will perform a software swap at startup if the secondary slots are tagged with "test".

To receive a DFU image on the nRF52, you can run an SMP Server feat Bluetooth Low Energy.
Headsup: When I build this sample for the nRF52840dk_nrf52811, I get errors due to too little flash. You likely have to do some Memory footprint optimization to make it work.
But it would be a good idea to test this memory optimization before going for this solution.
Images received in this way will be written to nRF52 secondary slot by default. Some custom handling is likely needed to make it write to nRF91 secondary slot instead.

To receive a DFU image on the nRF91, I will say the same as for the other solution:
I do not have a lot of experience with LTE, so I can not say exactly how, but I guess it would be similar to our Serial LTE Modem (SLM) FOTA.
Headsup: I think that the SLM use the DFU Target library, which reads the header of a DFU package, and applies this to the application core if MCUboot is detected. You might need to implement something to make it detect MCUboot updates for the 52.

The last part here would be to handle the External flash communication.
I asked a colleague if two chips can use the same external flash, and he said:
"You need to manage access to the flash, akin to flow control in UART communication as the two micros will have to share a bus where both acts as masters. Static partitions are probably needed. "
In other words, it seems possible, but you have to handle external flash access.
This would be a generic microcontroller challenge, so I am sure that you can find a lot of designs on how to do this on the internet.

To sum it up, I will list the parts that you need.
I will split the FOTA into three parts: Download Image, Perform Update and Handle External Flash

• Download Image
  • Bluetooth LE: SMP Server over Bluetooth LE (Example: MCUboot SMP Sample feat Bluetooth Low Energy)
  • LTE, download images from LTE (Example: SLM)
• Perform Update
  • Assuming the DFU image is written to the correct secondary slot, MCUboot will handle this automatically based on tag.
• Handle External Flash
  • You need to handle flash access somehow.

Conclusion

There are no right and wrong answers here, so it is up to you.
Both solutions require that you do some of the work.
Here are the biggest potential downsides with the solutions:

• SMP Client on the nRF9160:
  • The SMP Client over UART is not finished, you might have to write some of it yourself, depending on your timetables.
  • hci_uart for the nRF52811 limits the nRF52811 functionality
• Shared External Flash:
  • The nRF52811 might not have enough RAM for External Flash
  • The nRF52811 might not have enough RAM for the SMP Server, which would limit DFU over Bluetooth LE-
  • The External flash needs to be routed in hardware

I hope this was useful.
Let me know if you have any questions about this.

Regards,
Sigurd Hellesvik