I am building the Qorvo NI on the DW3001CDK-C2 with DWM3001C.E1.0. We would like to have the QNI and application run with a dual banked DFU due to the application requirement. It seems the QNI sample code (Including BLE softdevice) seems to be about 300KB to 390KB depending on the QNI version used (after doing the optimizations for size and removing logging).
Assuming QNI is about 300KB:
The S113 softdevice is about 112KB so the QNI w/o BLE is about 300-112=186KB.
The nRF52833 is 512KB so a dual banked DFU application using the S113(112KB) is limited to only 200KB including the QNI and we keep a separate 200KB bank for the DFU.
Is my understanding correct ?
Are there methods and processes to reduce the code size of the QNI so a dual banked DFU with an QNI application is made possible.
You can slightly reduce the code size, but I think better method for DFU/OTA is to use method 2 below.
Method 1:
You can have a dual-banked Application, where each part of the application has the code to do the update of contra-part. This is heavy method. For example you may want to do a DFU over USB update, and you have to carry all USB inside your normal application, which is never connected to the USB.
Advantages:
possibility to run the previous Application if something went wrong during the update process.
no need to have a high-quality code for DFU/OTA itself, because it can be replaced with next update.
Disadvantages:
high Flash memory requirements
the fact that if something went wrong the application is running, can be considered as a disadvantage as well.
Method 2:
You can have “S113”, “DFU/OTA updater” and an “Application”, all located in different segments of the Flash. Once the DFU/OTA update is triggered inside old “Application”, you are passing the responsibility to update it to the “DFU/OTA updater”. In this case you are not duplicating the unnecessary functionality, such as USB, DFU, OTA protocol in the Application. All these functionality lives in the “DFU/OTA updater”.
Advantages:
smallest code size; a lot left for the Application and only necessary is implemented in the Updater.
Disadvantages:
hight requirements to the quality of the DFU/OTA update application
maybe need a method to update the DFU/OTA itself using RAM as a temporary container, which in case of power loss can brick the device.
Method 3:
The combination of methods 1 and 2, where the “DFU/OTA updater” is downloaded and located in RAM. This is a risky method, but is actually used in a lot of modern devices (for example when PC does Bios update).
Whatever method you’ll chose is your IP, your know-how.
Thanks for the detailed response. Does the current NI code support Method 2 DFU which I think is a possible option to use for more consumer grade applications ? If the current NI code does not support method 2 DFU, does qorvo have plans to add it to the NI code.