The Bootloader - PowerFilm-Solar/REF-IN-BLE-NS_4 GitHub Wiki

The ability to update device firmware (DFU) over-the-air (OTA) of field deployed units is an important function for many applications.

Compared to steady state BLE operation, the standard DFU process requires a high constant power consumption over a long period of time, much more power than a small indoor PV cell could supply.

This low power optimized bootloader spreads out the DFU process to achieve a very low average power consumption, able to operate from an indoor PV cell at 200 lux.

PF_secure_bootloader allows for a user to update the application running on the nRF52832 over the air. To get started setting up the code for the bootloader, follow Nordic's guide.

Merging all the hex files

Creating a "all in one" hex file that contains the application data, bootloader data, and softdevice data is useful and sometimes required by specific applications. The PF_ble_app_blinky example requires both the bootloader and softdevice, and therefore requires the user to merge the three hex files into one or use post-build scripts in SEGGER to flash over the soft device and bootloader after the application. This section guides the user on how to merge the three hex files for proper flashing.

  1. If you haven't already, check out the getting started section and follow Nordic's guide to compiling the bootloader, completing the guide up to step 3, compile the bootloader, using PF_secure_bootloader.
    • Once PF_secure_bootloader is compiled, you can test it by flashing it to the device using SEGGER studio.
  2. Copy the hex file for the bootloader (located at PF_secure_bootloader\pca10040_s132_ble\ses\Output\Release\Exe) into a temporary folder.
  3. Navigate to your desired application (in this case PF_ble_app_blinky) and compile it if you haven't already. Copy the hex file of your application to the same temporary folder where you copied the bootloader hex file.
  4. Copy the soft device (located at nRF5_SDK_17.0.2\components\softdevice\s132\hex) into the temporary folder
  5. Copy the mergehex and nrfutil programs provided from Nordic into the temporary folder
  1. Open a terminal or command prompt, change the working directory to the temporary folder and copy the following commands, replacing the various hex file names with the names of your specific application, bootloader, and softdevice and replace the E:\ with the location of your J-Link device:
nrfutil settings generate --family NRF52 --application PF_ble_app_blinky.hex --application-version 0 --bootloader-version 0 --bl-settings-version 1 SETTINGS.hex
mergehex -m PF_ble_app_blinky.hex SETTINGS.hex -o APP+SETTINGS.hex
mergehex -m APP+SETTINGS.hex PF_secure_bootloader_ble_s132_pca10040.hex -o APP+SETTINGS+BL.hex
mergehex -m APP+SETTINGS+BL.hex s132_nrf52_7.2.0_softdevice.hex -o out.hex
nrfjprog -e
copy out.hex E:\
  1. Congratulations! The PF_ble_app_blinky application should be running on your device, and it should be able to enter the DFU once you connect to it!

To create a DFU package that can be transmitted:

  1. Copy the hex file to the application you want to transmit to a temporary folder
  2. Copy your private key to the same temporary folder
  3. Run the command nrfutil.exe pkg generate --app-boot-validation NO_VALIDATION --hw-version 52 --sd-req 0x101 --application-version 0xff --application APP_NAME.hex --key-file ../priv.pem APP_NAME.zip
    • Note: You will get a large warning stating that using NO_VALIDATION is not recommended for production builds. Currently, the validation process takes too much power and will be modified in a future version of this repository to reduce power usage.

Flashing combined bootloader and application with SEGGER

When testing applications, it is often required to have the bootloader installed alongside the application. For example, PowerFilm's blinky application (which was built on top of the buttonless service template) will crash if the bootloader is not installed. The easiest way to test your applications which require the bootloader is to set some build options in SEGGER. This section goes over how to add the proper build options and what each option does.

  1. Open the PF_secure_bootloader example in SEGGER studio.
  2. Click on "Project->Options" and then select "Common" from the drop down menu next to the search bar
  3. Inside of "User Build Step" add the following command to "Post-Build Command": cp $(ProjectDir)/$(OutDir)/$(ProjectName).hex" "../../../Hex Files"
    • This creates a copy of the bootloader hex files that can be used by SEGGER
  1. Clean and rebuild PF_secure_bootloader and then exit
  2. Open the application you are wanting to test with the bootloader.
  3. Click on "Project->Build Configurations..." and add a public configuration called "Release with Bootloader" and a private configuration called "Bootloader"
  4. Click the arrow next to "Release with bootloader" and make sure "Bootloader" is checked
  5. Close the build configurations window and go into "Project->Options"
  6. Select the "Bootloader" configuration from the drop down menu and then go into "User Build Step"
  7. Add the following command to "Post-Build Command": nrfutil settings generate --family NRF52 --application "$(ProjectDir)/$(OutDir)/$(ProjectName).hex" --application-version 0 --bootloader-version 0 --bl-settings-version 1 "$(ProjectDir)/$(OutDir)/SETTINGS.hex"
  1. Under the "Loader" loader section, add the following file to "Additional Load File[1]": $(ProjectDir)/Output/Release/Exe/SETTINGS.hex and add the following file to "Additional Load File[2]": "$(ProjectDir)/../Hex Files/PF_secure_bootloader.hex"
  1. Close the project options window and switch the build configuration to "Release with Bootloader"
  2. Clean and then "Build and run". Your device should now have a bootloader alongside your application!

Performing an OTA DFU

We recommend using the nRF Connect desktop application when performing an OTA DFU. Other programs, namely nrfutil, do not perform a connection parameter update request when the device is connected. This causes the average current consumed by the nRF52832 to be much higher than what the LL200-2.4-37 can provide.

Simply scan and connect to the device, wait for the device name to appear in connection window, then click on the perform OTA DFU button. Select the package to send over and watch as the package is transmitted over. Failure to wait for the device name appear will cause the DFU to fail every time.

Ready Not Ready

If the error "Timed out while waiting for BLE_EVT_TX_COMPLETE" occur, or any other errors for that matter, find where the installation of NRF Connect is. On Windows it is located at C:\Users\%USER%\AppData\Local\Programs\nrfconnect. Open the resources folder, then right click and edit the "app.asar" file. This is a large file so it will take a while to load in on slower computers. Use the find function to search for 'Timed out while waiting for BLE_EVT_TX_COMPLETE'. Once it's found, under that line should be the number 2000. Change it to 9000. This changes the timeout value and makes the DFU more reliable with longer connection intervals. Save the file, and the DFU process should timeout much less often.

Nordic has been told about this timeout issue, and hopefully in a future update they change it so the timeout period can be user configurable. Until then, this hacky solution should be enough to bandage the problem.

Changes in PF_secure_bootloader

Quite a few things are changed versus Nordic's provided secure_bootloader. The changes most beneficial to power usage are:

  • Modified crc32.c slow down large CRC checks. The CRC takes a large amount of power when processing sections of memory larger than 8kB. Delaying the CRC check and processing the the section of memory in chunks allows for the solar cell to restore the charge in the capacitors.
  • Validation is currently disabled in nrf_dfu_validation.c and nrf_bootloader.c. This currently takes too much power and will later be modified to reduce its average current consumption.
  • Decreased MTU size
  • Increased advertising and connection intervals
  • Decrease connection parameter update interval
  • Decrease NRF_BL_FW_COPY_PROGRESS_STORE_STEP, writes to FLASH more often allowing the DFU to resume closer to where it was powered down. Assists in very low light areas where constant DFU operation can't be guaranteed.