nRF91 BLE FOTA and nRF52 FOTA from nRF91 or BLE.

Hello,

We have a custom PCB with both the nRF9160 and nRF52832. Currently, the nRF52 functions as an HCI controller connected via LPUART to the nRF9160. We're at the stage of selecting a FOTA architecture for both chips on our PCB, and we need some clarification on certain aspects. Your help here would be much appreciated.

Our Ideal Update Scenario

We'd like to use both BLE and LTE to update both the nRF52 and nRF91, with the following approach:

  • Use a mobile app to update the nRF52 over BLE and potentially the nRF91 as well.
  • Download firmware over LTE to update both the nRF91 and the nRF52.

What We Know So Far & Our Thoughts

1. Current HCI Setup

Currently, the nRF52 acts as an HCI controller while the nRF91 functions as the HCI host. In this setup, we should be able to update the nRF91 over BLE without requiring serial recovery mode by only adding CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y to the configuration file.

The main question here is how to update the nRF52 in this setup. From what we understand, using MCUboot on the nRF52 in HCI controller mode causes communication errors on the LPUART driver. We believe this may be due to the resetting process of the nRF52 for synchronization in HCI. Are we correct in this assumption?

2. Standalone BLE Firmware on the nRF52

Alternatively, we could implement standalone BLE firmware on the nRF52 and communicate with the nRF91 over LPUART/UART. This would allow us to update the nRF52 over BLE and send firmware from the nRF52 to the nRF91 in serial recovery mode. In theory, we could achieve the same process in reverse through LTE.

The advantage here is that memory on the nRF91 is freed up from BLE-related functions. However, this setup requires supporting two separate firmware builds and creating custom commands for communication over UART between the two chips.

I like more the 1st solution, but it looks like we are already close to the memory limit because we also have WIFI chip and all this together almost take all the RAM and FLASH. We don't have the external memory chip on the PCB and we will work on the optimization a bit later. Need to understand if we may somehow to update the BLE in case of using 1st scheme. 

Parents
  • Hello,

    Are we correct in this assumption?

    I’m not sure, but I believe there won’t be an issue with LPUART as you mentioned. A better approach would be to test MCUboot in serial recovery mode on the nRF52832 to see if it impacts HCI communication over LPUART. This will give you a clear understanding of how MCUboot and its reset/recovery processes interact with the HCI and LPUART configuration. If MCUboot handles the LPUART cleanup well, then you can use the approach you mentioned. Please update me on how it goes.

    Kind regards,
    Abhijith

Reply
  • Hello,

    Are we correct in this assumption?

    I’m not sure, but I believe there won’t be an issue with LPUART as you mentioned. A better approach would be to test MCUboot in serial recovery mode on the nRF52832 to see if it impacts HCI communication over LPUART. This will give you a clear understanding of how MCUboot and its reset/recovery processes interact with the HCI and LPUART configuration. If MCUboot handles the LPUART cleanup well, then you can use the approach you mentioned. Please update me on how it goes.

    Kind regards,
    Abhijith

Children
No Data
Related