CS GUIDE Programming Pinnacle 100 v1 0
CS GUIDE Programming Pinnacle 100 v1 0
Version 1.0
Version Date Notes Contributors Approver
1.0 24 Apr 20 Initial Release Jamie M cc ra e Jonathan Kaye
Micro-USB Cable
(J-Link Access) Buttons 1-4
Reset Button
Micro-USB Cable
(UART Access)
LED2 (Blue)
Power switch
Micro-USB Cable
(UART Access)
Nordic MBR
Nordic library for setting up the module and
0x00000 0x000FFF 0x1000 (Master boot x loading the bootloader.
record)
User
0x1000 0x0D6FFF 0xD6000
application
This is where your application goes.
The Pinnacle 100 comes pre-loaded with a bootloader that supports secure firmware upgrades. It is designed for use in end-
user applications with its own update system. It is not recommended that the secure bootloader update mechanism during
development of firmware or applications due to the overhead of using the bootloader and increased time of programming when
new firmware is available for testing for development purposes and leave using this mechanism until the testing stage of
product design.
Table 2 gives an overview of the supported firmware upgrade methods and the feature set of them.
Note: Segger J-Link supports CLI programming operation only using nrfjprog. The Pinnacle 100 development board has a
J-Link OB which allows for debugging and testing applications on the module present on the development board only.
For further details, see the Segger website: https://www.segger.com/products/debug-probes/j-link/
For ease of development, we recommend SWD when developing your application. It can also be used in production to flash
the required image to the modules. We recommend that you then disable SWD during mass production (after the flash
programming stage) to prevent readback of code or malicious code injection. This can be performed by enabling readback
protection directly via SWD or by downloaded a special configuration file to QSPI (whereby the bootloader enables readback
protection) or via enabling it by using the UART bootloader interface.
FTDI driver
J-Link driver
To download and install the FTDI UART drivers, follow these steps:
1. If UART access is required and drivers are not installed, visit the FTDI website:
https://www.ftdichip.com/Drivers/VCP.htm and download the drivers for your operating system and architecture.
2. Once downloaded, run the installer and any attached FTDI devices should be automatically detected by the installer.
Once installed, the FTDI ports can be used like they were a serial port from any supported applications such as
UwTerminalX, available to download from: https://github.com/LairdCP/UwTerminalX
To download and install the Segger J-Link drivers, follow these steps (note that V6.62b or newer is mandatory/required):
1. If Segger J-Link drivers are not installed or are outdated then visit the Segger download site:
https://www.segger.com/downloads/jlink/ and download the J-Link Software and Documentation Pack for your operating
system and architecture. At the time this document was written, the latest version was V6.64a.
2. Once downloaded, launch the installer which installs the drivers to your system and the corresponding Segger
applications to your computer.
To download and install the latest Nordic nRF command line tools, follow these steps (note that version 10.7.0 or newer is
mandatory/required):
1. Download the latest Nordic nRF command line tools from https://www.nordicsemi.com/Software-and-
Tools/Development-Tools/nRF-Command-Line-Tools for your operating system and architecture. At the time this
document was written, the latest version was 10.7.0.
2. Once downloaded, launch the installer which installs the utilities to your system.
If you are using Linux, ensure you follow the instructions available on the main Github project page.
UwFlashX is a cross-platform utility for transferring upgrade images to the Pinnacle 100 module (and other Laird Connectivity
modules) modules via UART, to download and install the latest version, follow these steps:
1. Download the latest version from https://github.com/LairdCP/UwFlashX/releases for your operating system and
architecture.
2. If you are using Windows and have downloaded the SSL version, ensure you follow the instructions on the releases
page for installing the visual studio 2015 redistributable.
If you are using Linux, ensure you follow the instructions available on the main Github project page.
UBUtil is the Laird Connectivity Universal Bootloader Utility which is used to generate firmware upgrade packages for the
Pinnacle 100 module. It is cross-platform and is required if using the Pinnacle 100 bootloader.
To download and install the latest version, follow these steps:
1. Download the latest version from the Laird Connectivity Pinnacle 100 website https://www.lairdconnect.com/wireless-
modules/cellular-solutions/pinnacle-100-cellular-modem for your operating system and architecture
There are different methods of updating firmware on the Pinnacle 100 module as described in Table 2 located in Upgrade
Types. We recommend using SWD to upload direct to nRF52840 flash during development as it does not require a signed
image and is instantly executed once uploaded; unlike using the bootloader which requires time for the bootloader to verify
and copy the image into place.
To begin, you need an application built using your desired toolchain in hex format. Please ensure that the application starts at
0x1000 and does not end at an address greater than 0xE9000. Refer to Table 1 in the Memory Map section for information on
the memory map.
14. If you have not yet loaded your application, load it to the module using the load command. For Zephyr applications, the
file to load is named zephyr.hex: load zephyr.hex
15. Load the file with debug symbols. For zephyr applications this is zephyr.elf, using the file command: file zephyr.elf.
Laird Connectivity provides the following two pre-built applications for use with the Pinnacle 100:
▪ Zephyr out of box demo – This application can be used to evaluate the Pinnacle 100 working with AWS. It simulates an
end device sensor node which reads data from a Laird BL654-based BME280 sensor (via Bluetooth) and sends this data
securely to the cloud (using Cat-M1 internet) to AWS which can then be viewed in a web browser or stored for analysis.
A pre-compiled application is available for testing and the source code is available for a demonstration of how to create a
Zephyr application for the Pinnacle 100. This is provided as an example application only, the source and pre-compiled
application is available for download from https://github.com/LairdCP/Pinnacle_100_oob_demo
▪ Hosted mode firmware – This firmware includes smartBASIC and the AT interface application. It can be used by a host
processor by sending AT commands over a UART to interact with the Cat-M1/NB-IoT modem, it also supports Bluetooth
connectivity and GPIO/I2C/SPI/NFC functionality. It is provided as a firmware package which programs everything
required to the module. There is an instruction guide available from the Laird Connectivity Pinnacle 100 website which
explains how to install the hosted mode firmware image on https://www.lairdconnect.com/wireless-modules/cellular-
solutions/pinnacle-100-cellular-modem
Note: To switch from this firmware back to Zephyr development requires a full erase from the bootloader. This is a
production-grade firmware which is designed for use on systems with a separate processor controlling the system.
For details on performing a full erase, see the Restoring to Factory Defaults (via UART) or Full-Chip Erase/Recovery
(via SWD) sections.
A private key is required to sign firmware images, for security purposes all projects should have unique private keys (and to
enhance the security further, albeit outside the scope of this guide, would be to have unique private keys per module) and
these keys should be stored securely on a server or system, ideally one that has no internet access.
The UBUtil application can be used to generate a private key by using the --create-key argument followed by the output
filename which stores the key. For example, using this command:
UBUtil --create-key Blinky.pem
An example output of this command is as follows:
Laird Connectivity Universal Bootloader Firmware Update Generation Utility
v1.0
Built Apr 24 2020
UBUtil can be used to output the private key or public key from a generated .pem file, to do this the --file-info argument is used
along with --file-key to specify the type of key (0 will show the private key and 1 will show the public key).
To show the private key, use:
UBUtil --file-info Blinky.pem --file-key 0
Laird Connectivity Universal Bootloader Firmware Update Generation Utility
v1.0
Built Apr 24 2020
Public Key:
d24deb7ab6c3922d1fd561d0917304c00ece98a4b8bad9b0bd09ed4647edeb0eb5f938693a03ed52ac3f716b0b5
00cfc386bf8a77f4f49ff3b8b4eb4a4ca0470
The public key can be loaded into the bootloader on a module so that it accepts the signed firmware updates you generate.
The following is a list of command line arguments which can be used per section (where X is a number between 0 and 15
inclusive and R is a number between 0 and 3 inclusive):
Header:
Update header version: 1
Sections present: 2
Checksum: 0x56f6cb3c
Section 0:
Section Start: 0x4000
Section End: 0x306df
Section Size: 0x2c6df
Target: 0 (Internal flash)
Target Start: 0x1000
Target End: 0x39ba0
Target Size: 0x38ba0
Compressed: Yes
Version: 1
Checksum Type: 32-bit
Image Checksum: 0x7bc86c9e
Target Checksum: 0x1e5c79e0
Signature Type: 1 (User key)
Application Type: 1 (Main Application)
Header Checksum: 0x947dc75a
Filename: Blinky.hex
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000
Signature (hex):
e448e2113de11a5fa80259cbcdcd2362a3d457ef83ad09fd594caf41d408109d272d05247ba7ffcb1332db8735a
f0a64ffdf1e7543129398b0b97300c62af32
Section 1:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
For a full list of file types, requirements, and validities, refer to the Section Application Types section.
From the steps given in Outputting a Private or Public Key, you can obtain a public key from a key file. Once you obtain the
key, you can program it into a Pinnacle 100 module which does not have a public key set.
With a Pinnacle 100 module connected to a computer, follow these steps to program the public key:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Type y2 and press Enter to check if a public key is loaded to the module. If it responds with a 0, then no public key is
programmed. If it responds with a 1, then a public key is programmed (and no public key can be set).
5. Press x3 and paste the public key from the UBUtil listing step. The line will appear similar to the following:
x30956845803d675ad448d4f9dec970abf06b4f64a6651661f01c9b1fc906f2760ea36eb0c43ee4305b59273cdf79bdc908
aa4eb6d503c78303812040c7d3cbb9a
6. Press Enter.
7. The unit should respond with a.
▪ If it responds with an f, then there was an error whilst setting the public key (most likely because it is already set
or because the module is lacking a license).
▪ If there is no response, then check to ensure you did not miss any characters of the key.
Reset the module and put it back into bootloader mode before retrying or an invalid key could be programmed to the
module.
8. Reset the module by pressing z and Enter. If a firmware update package is present on the module, then it will be
updated assuming that the public key is correct. Otherwise, the package will be removed.
Flashing a firmware using UwFlashX requires that a .ubu firmware package is created. It does not work with .hex or .bin files.
Refer to Generating a Firmware Update Package to generate a compatible firmware update package. UwFlashX is a cross-
platform utility for transferring firmware update images to wireless modules, it can be obtained from
https://github.com/LairdCP/UwFlashX
After opening UwFlashX, you are presented with a dialogue showing multiple tabs and options from which to select (Figure 4).
Note: MAC users are unable to use this option. Instead, these users must manually reboot the module into
bootloader mode. You can do this by holding P0.31 (pin 16 on the M.2 connector) low and rebooting the
module or powering it up which, on the development board, is achieved by holding down SW1 and pressing
the reset button).
2. A .ubu firmware file must now be selected. Click the … button and select the correct file to program to your module.
The Bootloader Unlock Key tab allows specifying a bootloader unlock key. This is a special key which can be programmed into
the bootloader. It prevents read/write access to the data on the device unless the correct unlock key is provided to the module
during the firmware update process. Details on setting a bootloader unlock key and how to use it are detailed in the
Setting/Using a Bootloader Unlock Key section.
The Advanced UART Settings tab contains options for setting a maximum or exact baud rate:
▪ Maximum Baud Rate – This can be used to set a maximum baud rate for the bootloader to use whilst transferring an
update image and is most useful when using an RS232 port or other hardware which does not support fast baud rates.
UwFlashX will negotiate the fastest UART speed it can with the bootloader which is below this speed (which can be up to
1M baud if this option is not set). If a compatible baud rate is not found, then the update will fail and not be transferred to
the module.
▪ Exact Baud Rate – This can be used to specify the baud rate which is used to communicate with the bootloader, if set
then UwFlashX will negotiate this speed to be used for transferring the update image. If the specified baud rate is not
supported by the module or is invalid, then the update will fail and not be transferred to the module.
The Advanced tab lists the following advanced options for the update process:
▪ Disable Enhanced Bootloader Functionality – Enabling this option disables newer bootloader functionality from
UwFlashX and uses the legacy bootloader commands. Only use this option if there are issues updating firmware on
legacy modules and if will cause issues with Pinnacle 100 modules if, for example, a Bootloader Unlock Key is set.
▪ Disable Bootloader Entrance Warnings – If this option is enabled, popup warning/question messages that open when
using the FTDI reset functionality for entering the bootloader do not display and are automatically accepted. This is useful
when running UwFlashX in an unattended or automated system and handling the error by a script or other application.
Please ensure you use the correct serial port as Laird Connectivity cannot take responsibility for any possible damage or
issues caused by use of the wrong serial port.
▪ Disable Bootloader Entrance Errors – If this option is enabled, popup error messages that can open when using the
FTDI reset functionality for entering the bootloader do not display and are automatically accepted. This is useful when
running UwFlashX in an unattended or automated system and handling the error by a script or other application.
▪ Check upgrade file validity before upgrading – Before the upgrade process starts, the .ubu file is checked to ensure it
does not contain any errors. If it finds errors, then the upgrade does not proceed.
▪ Verify written data – If this option is enabled, data that is written to the module is verified to ensure that it was
transferred correctly. This does not work if the Blocking UART Data Verification option is enabled on the bootloader.
▪ Restart Module After Update – If this option is enabled then, after the update process is complete, the module is reset
so that the bootloader can update the software on the module. Otherwise, after finishing, it keeps the unit in bootloader
mode.
▪ Use SSL for update checking – If this option is enabled, the upgrade check mechanism uses SSL. Otherwise it uses
standard unencrypted HTTP.
▪ Override FTDI ID – This option should only be used if there is an issue with the FTDI serial number of the Pinnacle 100
development board. If enabled, the FTDI serial number placed in the ID box is used for entering the bootloader.
Otherwise, UwFlashX attempt sto automatically detect the serial number.
The About tab displays licenses of software used in the creation of UwFlashX. These are also displayed at the end of this
document in the License Information section.
There is also an option to check if your version of UwFlashX is the latest and a link to the github page where a newer version
of the application (if available) can be downloaded.
Note: By using the check for update functionality, some details are stored by server in a log file when the request is made.
These details include IP address, time and date of request, web headers and URL, version number/name of the
application, and the operating system of your computer. This information is held for security purposes only and is not
used for any analytical purposes.
With the output hex file generated, open a command prompt window or terminal and flash the update image to QSPI using the
following:
nrfjprog -f NRF52 --program <file.hex> --qspisectorerase --reset
The output will look similar to this the following:
Once the application has been successfully programmed, the module will reboot and the bootloader will update assuming that
the public key has been programmed correctly or is present in the programmed update file.
Header:
Update header version: 1
Sections present: 2
Checksum: 0x56f6cb3c
Section 0:
Section Start: 0x4000
Section End: 0x306df
Section Size: 0x2c6df
Target: 0 (Internal flash)
Target Start: 0x1000
Target End: 0x39ba0
Target Size: 0x38ba0
Compressed: Yes
Version: 1
Checksum Type: 32-bit
Image Checksum: 0x7bc86c9e
Target Checksum: 0x1e5c79e0
Signature Type: 1 (User key)
Application Type: 1 (Main Application)
Header Checksum: 0x947dc75a
Filename: Blinky.hex
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Image checksum valid: Yes
Header checksum valid: Yes
Signature (hex):
e448e2113de11a5fa80259cbcdcd2362a3d457ef83ad09fd594caf941d408109d272d05247ba7ffcb1332db8735
af0a64ffdf1e7543129398b0b97300c62af32
Section 1:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
Header Checksum: 0xb471376d
Filename: Blinky.pem
Signed header files are header sections of files passed through UBUtil which have been signed with the private signing key.
They can be used to integrate into various update packages containing different images and features. This allows for the
signing process to take place on a secure build server which has the private signing key without needing to share the private
key or compromise the security of it. Signed header files contain all the information required for input files to be processed by
UBUtil on another PC without the need for the private key as they contain the pre-computed signature of the input file. To use
signed image header files, the input .hex/.bin files processed by UBUtil and the output .hdr files must be presented to UBUtil at
a later time to generate the final update package.
As an example, bootloader updates for the Pinnacle 100 module are distributed in paired .hex and .hdr files. These can be
incorporated into user update packages along with application updates.
Signed image header output can be applied to any UBUtil firmware generation command by appending:
--output-headers
When this command is used, all input sections with input files have a new file created with _header.hdr appended to the end of
them (the format of the name output is not configurable). Note that each generated header file is unique and matches up with
the input arguments which were used to generate the file. For example, if compression is used, then compression is
mandatory for that section; it is automatically enabled when that header file is used in future.
This section applies to signed image files generated by Laird Connectivity for bootloader and cellular modem firmware
updates. It also applies to any user-created signed image header files.
When using a signed image header file with UBUtil, the only parameters allowed are the input filename and the input signed
image header. No other arguments for these sections are allowed.
However, inputs to UBUtil can be of a mixed form: one section can be a user application and signed image header file, another
section could be a Laird Connectivity bootloader update and signed image header file, and a third section could be a user
configuration section with parameters supplied as normal and the private signing key supplied to sign this section. This will
generate a valid update file. The argument --aX-header <file > must be used to supply a signed image header file along with
the --aX-filename <file> argument to specify the input hex/binary file.
To use only signed image header files:
UBUtil --a0-filename Blinky.hex --a1-filename bootloader.hex --a0-header Blinky_header.hdr --
a1-header bootloader_header.hdr --output test_package.hex --ubu-platform 512A510F --ubu-
flash-size 8M --ubu-sector-size 4K --ubu-base-address 0 --ubu-align-length 4 --ubu-output
test_package.uwf
To use a mix of signed image header files and normal arguments:
UBUtil --application-key-file Blinky.pem --a0-version 1 --a0-compressed --a0-target 0 --a0-
startaddress 0x1000 --a0-filetype 1 --a0-filename Blinky.hex --a0-keytype 1 --a1-filename
bootloader.hex --a1-header bootloader_header.hdr --append-pub-key --output test_package.hex -
-ubu-platform 512A510F --ubu-flash-size 8M --ubu-sector-size 4K --ubu-base-address 0 --ubu-
align-length 4 --ubu-output test_package.uwf
Header:
Update header version: 1
Sections present: 3
Checksum: 0x04152166
Section 0:
Section Start: 0x4000
Section End: 0x306df
Section Size: 0x2c6df
Target: 0 (Internal flash)
Target Start: 0x1000
Target End: 0x39ba0
Target Size: 0x38ba0
Compressed: Yes
Version: 1
Checksum Type: 32-bit
Image Checksum: 0x7bc86c9e
Target Checksum: 0x1e5c79e0
Signature Type: 1 (User key)
Application Type: 1 (Main Application)
Header Checksum: 0xcc1012d5
Filename: Blinky.hex
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
e7aae7a83a5c45f84504e1de45c66962beb4f7db93650e5377d87af585168d313eb89332267f831c4e713d61ce4
ccbebe9cd7e392fa89d5088ba69b01ea157e0
Section 1:
Section Start: 0x31000
Section End: 0x3f7ea
Section Size: 0xe7ea
Target: 0 (Internal flash)
Target Start: 0xd7000
Target End: 0xea000
Target Size: 0x13000
Compressed: Yes
Version: 3
Checksum Type: 32-bit
Image Checksum: 0xd61ee013
Target Checksum: 0x144735ae
Signature Type: 0 (Bootloader key)
Application Type: 2 (Bootloader Update)
Header Checksum: 0x022ac000
Filename: Bldr_Release.bin
Section 2:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
Header Checksum: 0xb471376d
Filename: Blinky.pem
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
d24deb7ab6c3922d1fd561d0917304c00ece98a4b8bad9b0bd09ed4647edeb0eb5f938693a03ed52ac3f716b0b5
00cfc386bf8a77f4f49ff3b8b4eb4a4ca0470
The following table (Table 3) lists the application types available for use on the Pinnacle 100 and specified by using the --aX-
filetype ? argument. Bootloader updates and modem updates are available from Laird Connectivity only and should not be
generated using the UBUtil application. They arrive as a .hex and .hdr file which can be supplied when generating a firmware
update package to include them in it.
Table 3: Section application types
Self- Section Start Allow Allow
Type Name Description
Purge Size Address Compression Multiple
0 Reserved Reserved for future use
Stores executable applications, these
Main should start at 0x1000 if no Soft-Device Up to 0x1000 –
1 x x
application is used or at an address corresponding 0xD6000 0xD6000
to the Soft-Device address if one is used
Bootloader Stores bootloader updates which are
2 x x
update provided by Laird Connectivity
Stores Soft-Devices which start at Up to
3 Soft-Device x 0x1000 x
0x1000, if one is used by the application 0x50000
User
Can be used to store read-only user Up to 0x2000 –
4 Configuration x x x
configuration 0xD5000 0xD6000
A
User configuration sections are sections that can reside in QSPI flash. They are read-only and can be used to set
configuration for user applications or hold strings/data which can be used. Note that these sections are not for holding
executable (eXecute-In-Place – XIP) code. These sections mandate a signed section and do not support being updated from
the user application unless the entire section is replaced with a new section including a valid signature and header.
To add a user configuration section using UBUtil, the application type should be set to 5-7 depending upon the address of
where the section is to be placed as shown in the Section Application Types table (Table 3).
The following is an example
UBUtil --application-key-file Blinky.pem --a0-version 1 --a0-filetype 5 --a0-target 0 --a0-
keytype 1 --a0-startaddress 0x18000 --a0-filename ConfigInput.hex --append-pub-key --output
configuration_section_example.hex --ubu-platform 512A510F --ubu-flash-size 8M --ubu-sector-
Header:
Update header version: 1
Sections present: 2
Checksum: 0x56f6cb3c
Section 0:
Section Start: 0x4000
Section End: 0x1e627
Section Size: 0x1a627
Target: 0 (Internal flash)
Target Start: 0x18000
Target End: 0x32627
Target Size: 0x1a627
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0x42549f32
Target Checksum: 0x42549f32
Signature Type: 1 (User key)
Application Type: 5 (User configuration B)
Header Checksum: 0xf0c146f1
Filename: ConfigInput.hex
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
f62d414c5d1c71821a97b40dac71bfb121f0d1cb3878fc40572de999138993097e46c3a34fd3af8ba1d02450409
5a634d693f93636135a4bec4ea8627f64879a
Section 1:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
Header Checksum: 0xb471376d
Filename: Blinky.pem
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
d24deb7ab6c3922d1fd561d0917304c00ece98a4b8bad9b0bd09ed4647edeb0eb5f938693a03ed52ac3f716b0b5
00cfc386bf8a77f4f49ff3b8b4eb4a4ca0470
Erase sections can be used to erase a portion of internal nRF52840 flash space. There are two types of erase sections:
▪ Erase Once – These sections, when present, erase a section of nRF52840 flash and are then purged from the QSPI
flash. They do not erase data again.
▪ Erase Always – These sections, when present, always erase a section of nRF52840 flash and remain present in the
QSPI flash once the bootloader is finished. They erase the section every time the bootloader runs.
Note: If the area specified by an erase section is already erased (set to 0xff), then it skips the erase process. But if the
erase file is an erase once type section, then that section is purged from QSPI regardless of whether or not the flash
is erased.
In the following arguments, the version should be a number between 1-65535 and be incremented each time a section of that
type is generated, the start address should be the sector-aligned address of the area to erase, the size (if used) should be a
sector-aligned length to erase, the end address (if used) should be a sector-aligned address of the address to erase.
To add an erase once section using UBUtil, the following arguments should be used (where X is the section number):
--aX-version ? --aX-filetype 9 --aX-startaddress 0x? --aX-size 0x? --aX-target 0 --aX-keytype 1
Note: Start addresses, end addresses, and sizes must be sector aligned (0x1000 on the nRF52840) as sectors are erased
in full.
Header:
Update header version: 1
Sections present: 2
Checksum: 0x56f6cb3c
Section 1:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
Header Checksum: 0xb471376d
Filename: Blinky.pem
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
d24deb7ab6c3922d1fd561d0917304c00ece98a4b8bad9b0bd09ed4647edeb0eb5f938693a03ed52ac3f716b0b5
00cfc386bf8a77f4f49ff3b8b4eb4a4ca0470
In-Place User Storage Sections can be used for holding data in QSPI which can then be used for reading and optionally
writing data from the user application. Section sizes cannot be changed and are fixed to their initial size. There are two
supported types:
▪ One with verification and a checksum which requires a valid signed header. This is recommended for uses where the
data is not changed by the user application but can be upgraded;
For sections without verification/checksum, the application type should be set to 11 and target set to 2. No private key needs
to be supplied for this section type as it is unsigned and the underlying QSPI data can be changed by the user application at
will; it is the responsibility of the user to add security to their application to ensure that the data is valid.
The following is an example:
UBUtil --a0-version 1 --a0-target 2 --a0-startaddress 0x40000 --a0-filetype 11 --a0-filename
App_Config.bin --output example_configuration_no_verification.hex
The output looks similar to the following:
Laird Connectivity Universal Bootloader Firmware Update Generation Utility
v1.0
Built Apr 24 2020
Header:
Update header version: 1
Sections present: 1
Checksum: 0xc0b56ecc
Section 0:
Section Start: 0x4000
Section End: 0x1e627
Section Size: 0x1a627
Target: 2 (QSPI)
Target Start: 0x40000
Target End: 0x5a627
Target Size: 0x1a627
Compressed: No
Version: 1
Checksum Type: Bypass
Image Checksum: 0x00000000
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 11 (QSPI user section (no verification))
Header Checksum: 0x06582ae5
Filename: App_Config.bin
Extra data (hex):
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000
Signature (hex):
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000
Header:
Update header version: 1
Sections present: 2
Checksum: 0x56f6cb3c
Section 0:
Section Start: 0x4000
Section End: 0x8000
Section Size: 0x4000
Target: 2 (QSPI)
Target Start: 0x40000
Target End: 0x44000
Target Size: 0x4000
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0x4bfe7b43
Target Checksum: 0x4bfe7b43
Signature Type: 1 (User key)
Application Type: 20 (QSPI user section (with verification))
Header Checksum: 0xce8347f3
Filename: App_Config.hex
Extra data (hex):
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000
Signature (hex):
33cecae3a95099d3bef6257fb8bf53593e3b326112a99c91d8b9c5ddb4ab02bd6b49b00bdda168299b1d9af339
cc995035c87f1b79eadb6cf488722e720c4af4
Section 1:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Public Key Sections allow the application public key to be programmed to the module by the bootloader without using the
UART interface of the module. This is useful for mass production as it speeds up the process of programming modules.
There are two methods of adding public keys to update images:
▪ Automatically extracting the public key from the pem file and including it in the output image – either prepended to the
start of the update sections or appended to the end of the update sections. Note that this does not work if UBUtil is
working strictly with signed header image files without access to the private key file.
▪ Manually inputting the public key into a UBUtil command line argument. This generates a section without UBUtil needing
access to the keys in the pem file
To prepend the public key from the pem file using UBUtil, use this argument:
--prepend-pub-key
To append the public key from the pem file using UBUtil, use this argument:
--append-pub-key
To specify a public key manually (which can be extracted from the pem file using UBUtil as described in the Outputting a
Private or Public Key section), use these arguments (where X is the section number and where the extra data field contains
the hexadecimal public key):
--aX-version 1 --aX-filetype 12 --aX-extradata ? --aX-target 3
The following is an example:
UBUtil --application-key-file Blinky.pem --a0-version 1 --a0-filetype 12 --a0-extradata
0956845803d675ad448d4f9dec970abf06b4f64a6651661f01c9b1fc906f2760ea36eb0c43ee4305b59273cdf79bd
c908aa4eb6d503c78303812040c7d3cbb9a --a0-target 3 --a1-version 2 --a1-keytype 1 --a1-target 0
--a1-startaddress 0x1000 --a1-filetype 1 --a1-filename Blinky.hex --output
public_key_and_application_example.hex --ubu-platform 512A510F --ubu-flash-size 8M --ubu-
sector-size 4K --ubu-base-address 0 --ubu-align-length 4 --ubu-output
public_key_and_application_example.uwf
The output looks similar to the following:
Laird Connectivity Universal Bootloader Firmware Update Generation Utility
v1.0
Built Apr 24 2020
Header:
Update header version: 1
Sections present: 2
Section 0:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0x06d81eb6
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
Header Checksum: 0x8d30c6f3
Filename: [Not Present]
Extra data (hex):
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000
Signature (hex):
0956845803d675ad448d4f9dec970abf06b4f64a6651661f01c9b1fc906f2760ea36eb0c43ee4305b59273cdf7
9bdc908aa4eb6d503c78303812040c7d3cbb9a
Section 1:
Section Start: 0x4000
Section End: 0x3cba0
Section Size: 0x38ba0
Target: 0 (Internal flash)
Target Start: 0x1000
Target End: 0x39ba0
Target Size: 0x38ba0
Compressed: No
Version: 2
Checksum Type: 32-bit
Image Checksum: 0x1e5c79e0
Target Checksum: 0x1e5c79e0
Signature Type: 1 (User key)
Application Type: 1 (Main Application)
Header Checksum: 0x9435dee6
Filename: Blinky.hex
Extra data (hex):
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000
Signature (hex):
8e80c934e6f29ad90b6611352c250946e071c61bc85d58c4b23206f556503d90cf1d9d94581575326f581d05f9
00b1919c67e00c9b3b827d259e8e9606e00abd
Bootloader settings sections allow various configuration options of the bootloader to be set without mandating UART access to
enable them. This is designed for mass production so that a single image can be deployed to modules for faster deployment
A bootloader unlock key is a 64-byte (512-bit) key which is used to prevent access to the read/write/verify UART bootloader
commands until the correct key has been entered. This can help with bolstering security. Details on this can be found in the
Setting/Using a Bootloader Unlock Key section.
A bootloader unlock key can be programmed to a module with a section in a firmware upgrade package. This allows for keys
to be set during production. For security reasons, once the bootloader processes a bootloader unlock key section, it purges
the data from QSPI to prevent unauthorised reading of the key by possible malicious users. Another possible method of
reducing risk is to generate and store a unique key for every device produced. This is a decision for the user to make based
upon their security requirements.
For a bootloader unlock key section, the application type is 19 and the 64-byte key can be provided in hex format using this
argument:
--aX-extradata ?
With a 128-character argument, or can be provided in ASCII using this argument:
--aX-extradatatext ?
With a 64-characters argument, X must be set to a free section. The target type must be set to bootloader storage which is
type 3.
Note: Using the ASCII input option restricts the range of allowable characters to those in the ASCII range.
Note: At the time of writing this guide, UwFlashX only supports ASCII/UTF-8 input for the bootloader unlock key.
Header:
Update header version: 1
Sections present: 1
Checksum: 0xc0b56ecc
Section 0:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Some firmware packages might contain multiple components which are only compatible with certain versions of other
components. Because firmware files are transferred as a whole, if there is an error in one of the sections then that section may
be removed when the bootloader starts. One of the other sections may be upgraded which could cause an incompatibility with
the software loaded on the module.
One example of this is Nordic SDK projects which utilise the Nordic soft-device. If a previous major version of the soft-device is
loaded and the application is built against a newer one, then it causes the module to hard-fault. This feature ensures that these
components are only programmed if they are all present and valid in the upgrade image.
Each upgrade section can have four version requirements which link to other sections. The following (Table 4) is a list of
supported comparison modes.
Either the number (#) or command can be specified on the command line. Symbols cannot be used because they have special
meaning in command prompt and terminals.
Version requirements can be specified with the following command line arguments:
--aX-rY-match =<match> --aX-rY-filetype <type> --aX-rY-version <version> --aX-rY-present
<present>
Header:
Update header version: 1
Sections present: 3
Checksum: 0x04152166
Section 0:
Section Start: 0x4000
Section End: 0x23eed
Section Size: 0x1feed
Target: 0 (Internal flash)
Target Start: 0x1000
Target End: 0x26598
Target Size: 0x25598
Compressed: Yes
Version: 2
Checksum Type: 32-bit
Image Checksum: 0x5d1a3120
Target Checksum: 0xa5230a59
Signature Type: 1 (User key)
Application Type: 2 (Bootloader Update)
Header Checksum: 0xa82f2048
Filename: SD7.hex
Extra data (hex):
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000
Signature (hex):
0dce5694b48da98cc4c9cd0ab590a63c281486992fcf06e9bac9efb8fd2eda9ceb12c91d4daabb802ea2b2bef3
7d525218801b4ab5f9744e62502a44dc333400
Version requirements: 2
Version requirement 0: Application Type 1 (Main Application) must = [e]version 2
Version requirement 1: Application Type 4 (User configuration A) must =[e] version
2
Section 1:
Section Start: 0x24000
Section 2:
Section Start: 0x51000
Section End: 0x6f630
Section Size: 0x1e630
Target: 0 (Internal flash)
Target Start: 0x98000
Target End: 0x96630
Target Size: 0x1e630
Compressed: No
Version: 2
Checksum Type: 32-bit
Image Checksum: 0x6213619c
Target Checksum: 0x6213619c
Signature Type: 1 (User key)
Application Type: 4 (User configuration A)
Header Checksum: 0x96f6a66a
Filename: Cfg.hex
Extra data (hex):
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000
Signature (hex):
6fbc061af76d2b06e652ea360b0a746001c3a34f715ed001cf4f64b74b66bbda7cfc38d57e7c278d852b859cc5
4e1b1735b223f872f794fc157f490a5f65aa08
Version requirements: 2
Version requirement 0: Application Type 1 (Main Application) must = [e]version 2
Version requirement 1: Application Type 2 (Bootloader Update) must = [e] version 2
When the above firmware package is programmed to a module, it only upgrades the sections if all three sections are present
in the upgrade file. If one of the sections is missing, then the upgrade data remains on the module, but the upgrade is not
A bootloader unlock key can be used to restrict access to a device via the UART when in bootloader mode. It can also require
that a code be sent before any data reading/writing can take place; this increases the security of IP and application integrity.
An unlock code consists of 64 bytes (512 bits) of data.
To set a bootloader unlock key, follow these steps:
1. Enter bootloader mode on the pinnacle 100, this can be achieved by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX this takes the form of a slash (\)followed by two numbers.
4. Right-click on the UwTerminalX window and select the automation option.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: x9 and add 64 bytes of data to the end of it. This becomes the bootloader
unlock key.
8. Press the top send button. The module should respond with an a which indicates that it is now unlocked.
9. Press the second send button. The module should respond with an a which means that the key is set.
▪ If it responds with an f, then there was an error whilst setting the unlock key (most likely because a key is already
set or because the module is lacking a license).
▪ If there is no response, then check to ensure you included 32 characters
Reset the module and put it back into bootloader mode before retrying or an invalid unlock key could be programmed to
the module.
10. Reset the module by pressing Z and Enter.
11. Press the top send button. The module should respond with an a indicating that it is now unlocked.
12. In the automation window in the third field, add the following data:
u0000000000000000000000000000000000000000000000000000000000000000
13. In the automation window in the fourth field, add the following data: u and append the key you have in the second field
(minus the x9).
14. Press the third send button. The module should return an f to indicate that the unlock code is incorrect.
15. Press the fourth send button. The module should return an a to indicate that the unlock code is successful.
16. Ensure that the bootloader unlock key is saved so that it can be unlocked in future.
Once a bootloader unlock key has been set, it cannot be changed or disabled unless a full erase is performed as described in
Restoring to Factory Defaults (via UART) or Full-Chip Erase/Recovery (via SWD). Any time that an update image is used in
UwFlashX, the bootloader unlock key must be provided in the utility under the Bootloader Unlock Code tab.
Readback Protection is a hardware feature of the nRF52840 chip which prevents SWD access to the chip. This prevents the
application code of the MCU from being read out which keeps the IP safe and increases security.
Note: Once readback protection is enabled, writing data to the QSPI memory using nrfjprog no longer functions.
CPU Debug Protection is a hardware feature of the nRF52840 chip which prevents the FPB and ETM functionalities on the
chip. This helps keeps algorithms safe and increases security.
To enable CPU debug protection, follow these steps:
1. Enter bootloader mode on the pinnacle 100. Do this by holding P0.31 (pin 16 on the M.2 connector) low and rebooting
the module or powering it up. On the development board, hold down SW1 and press the reset button.
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Right click on the UwTerminalX window and select Automation.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: y5
8. In the third field, add the following data: x5\01
9. Press the top send button. The module should respond with an a indicating that it is unlocked.
10. Press the second send button. The module should respond with y5\00. The 00 indicates that CPU debug protection is
currently disabled.
11. Press the third send button. The module should respond with an a which indicates that the option is set and that the
protection will be enabled at next bootup.
If it responds with an f, then there was an error whilst setting the functionality (most likely because the module is lacking
a license).
The QSPI flash on the Pinnacle 100 has two modes of operation:
▪ Ultra-low power mode – Operations take considerably longer than in high performance mode, but the flash consumes
much less power. This makes this mode ideal for battery-operated devices.
– Maximum of 24uA when in standby mode
– Maximum of 4mA when in read mode
– Maximum of 7mA in programming/erase mode
▪ High performance mode – Operations complete more quickly than in ultra-low power mode, but the flash consumes
much more power. This makes this mode ideal for applications where the speed is important or lower power consumption
is not a concern.
– Maximum of 50uA when in standby mode
– Maximum of 9mA in read mode
– Maximum of 10mA in programming/erase mode.
The operating mode of the QSPI flash can be changed from the bootloader. To view the current operating mode of QSPI,
follow these steps:
1. Enter bootloader mode on the pinnacle 100. Do this by holding P0.31 (pin 16 on the M.2 connector) low and rebooting
the module or powering it up. On the development board, hold down SW1 and press the reset button.
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Right-click on the UwTerminalX window and select the Automation.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: y7
8. Press the top send button. The module should respond with an a which indicates that it is unlocked.
9. Press the second send button. The module should respond with y7\00 or y7\01. If 00, then the QSPI is in ultra-low
power mode. If 01, then the QSPI is in high performance mode.
To change the operating mode of QSPI, follow these steps:
1. Enter bootloader mode on the pinnacle 100. Do this by holding P0.31 (pin 16 on the M.2 connector) low and rebooting
the module or powering it up. On the development board, hold down SW1 and press the reset button.
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
By default, the bootloader on the Pinnacle 100 has operations for reading, writing, and erasing data on the QSPI. The
functionality can be limited by setting a bootloader unlock key (see the Enabling Readback Protection section for details) or by
enabling UART Data Readback protection which prevents the UART read commands from working.
To enable UART Data Readback protection, follow these steps:
1. Enter bootloader mode on the pinnacle 100. Do this by holding P0.31 (pin 16 on the M.2 connector) low and rebooting
the module or powering it up. On the development board, hold down SW1 and press the reset button.
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Right-click on the UwTerminalX window and select Automation.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: y6
8. In the third field, add the following data: x6\01
9. In the fourth field, add the following data: r\00\01\00\00\04
From the bootloader, data stored on the QSPI chip can be verified. This ensures that data written from an update file is
correctly transferred to the module without errors. Whilst this feature is useful for data verification, it presents a potential attack
point which can be used to create a duplicate of the data stored in the module. Because of this, there are options to disable
this functionality (if it is not required) or limit the minimum size of data verification.
Note: The verification command is subject to the Setting/Using a Bootloader Unlock Key functionality. If set, it requires that
the bootloader unlock code is issued before it can be used.
Because you can specify the size of data to be verified, a malicious attacker could try to verify every byte on the module by
guessing the checksum. Once the attacker knows the checksum of the byte, it would also know the contents of that single byte
and could then proceed onto the next byte. This is a very slow process but is a possible attack vector; limiting the UART data
verification can make it almost impossible for a malicious attacker to do this.
The checksum used by the bootloader is 32-bits. The minimum size of data on the QSPI which can be verified can be set to a
multiple of the flash write size (4 bytes) up to a value of 16,384 (16 KB). Because the checksum represents a very finite value
in comparison to what the minimum UART data verification size can be, it becomes increasingly difficulty to work out what the
underlying data actually is.
For example, if a size of 32 bytes is chosen, there are 256-bits which can have 1.15e+77 possible combinations. The 32-bit
checksum can only represent around 4.3 billion combinations and so there many permutations of the underlying data that can
give the same checksum value. This is unlikely to happen with the use-case of verifying that data is written correctly but is very
likely to arise when guessing what the underlying data consists of.
To check the current UART data verification minimum size, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
As shown in the Erase Sections section, there are application types with IDs 9 and 10 which are erase sections. These
sections contain no data but erase sectors of flash on the nRF52840 either once or every time the bootloader starts. By
default, there is no restriction placed on these sections although it can be applied. There are four types of erase section mode
(Table 6).
You can add options together whereby all options being set entirely block erase sections. If the erase section mode is already
configured on a module, the security level can be increased by adding in additional bitmask values but cannot be decreased.
To check the current erase section mode:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Right click on the UwTerminalX window and select Automation.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: yI
8. Press the top send button. The module should respond with an a indicating that it is unlocked.
9. Press the second send button. The module should respond with yI\0 followed by a hex value which indicates the
current bitmask of boot verification options listed above.
Protection can be applied to the main application and soft-device sections so that other upgrade sections cannot interact with
the data on the module from these sections. For example, if an application is present from 0x1000 – 0x10000 and there is an
erase section partition which erases a sector at 0x9000 then, by default, this sector is erased. This allows for applications that
include specific sectors with configuration data to be cleared, if necessary. There are two types of section protection (Table 7).
Table 7: Section protection types
Bitmask Name Description
0 None A (default)
1 Main application Prevent other sections from modifying data in the main application section
2 Soft-device Prevent other sections from modifying data in the soft-device section
To check the current main application/soft-device section protection level, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
Options can be added together with all options being enabled providing the most secure environment. If boot verification is
already configured on a module, the security level can be increased by adding in more bitmask values but cannot be
decreased.
To check the current boot verification level, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Right click on the UwTerminalX window and select Automation.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: yF
8. Press the top send button. The module should respond with an a indicating that it is unlocked.
9. Press the second send button. The module should respond with yF\ followed by a hex value which indicates the current
bitmask of boot verification options listed above.
To change the current boot verification level, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
The Pinnacle 100 bootloader has a full-erase command which can be issued from the UART. This erases all data on the
module and restores it to factory defaults (except for the readback protection and CPU debug security bits). For details on this
feature, refer to the Restoring to Factory Defaults (via UART) section.
To improve security, this functionality can be disabled (which leaves SWD as the only way to erase the module, as detailed in
Full-Chip Erase/Recovery (via SWD)) or protected (which prevents accidental erasure of modules). Security can be tightened
at any time by going to a higher security level but it cannot be decreased.
The following table () displays the security levels of the Full-Erase command.
To check the current security level of the Full-Erase command, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
Note: Regardless of what split of memory is set for use by the bootloader and user application, when performing a full-
erase as detailed in the Restoring to Factory Defaults (via UART) section, the entire contents of the QSPI memory is
erased.
There are two values which can be retrieved from the bootloader which specify the details of how much of the QSPI data can
be used by a user application. If both of these values are set to 0 (default), then no QSPI flash space is reserved for use by the
user application.
There is a restriction when updating the amount of QSPI flash space that can be used by the user application – the size can
always be increased in sectors up to half of the flash size but cannot be reduced once set.
To view the user application QSPI flash size limit and QSPI flash start address, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Right click on the UwTerminalX window and select Automation.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: yB
8. In the third field, add the following data: yC
9. Press the top send button. The module should respond with an a indicating that it is unlocked.
10. Press the second send button. The module should respond with yB followed by two sets of hexadecimal numbers
which indicates the user application QSPI flash size sectors.
Note: This is in little endian so a response of \10\00 means 0x0010 which is 16 sectors.
11. Press the third send button. The module should respond with yC followed by four sets of hexadecimal numbers which
indicates the user application QSPI flash start address.
To set the user application QSPI flash size limit, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
The bootloader on the Pinnacle 100 module supports firmware updates. There may be many versions of the bootloader; if
support is requested for the bootloader, then the version information of the bootloader you are using is required.
To retrieve the bootloader version information, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Press M and Enter.
The module emits version information which can be used to check if the bootloader is the latest version or not included
in any request for support. It will resemble the following:
Model: 124, Variant: 0, Name: PINNACLE100, Bootloader version: 3 (FUP: 6.011, Ext.
struct: 1, Ext. function: 2)
Note: If the full-erase block has been enabled as described in the Blocking Full-Erase Command section, then issuing the
full-erase command does not work and an error is returned. The only way to erase the module in this instance is to
perform an erase using SWD as described in the Full-Chip Erase/Recovery (via SWD) section.
Note: Restoring to factory defaults does not erase or reset the readback protection security option or the CPU debug
protection. The only way to remove this protection is to perform a recovery operation via SWD, which is detailed in
the Full-Chip Erase/Recovery (via SWD) section.
Returning a unit to factory default settings can take up to approximately three minutes but is usually quicker. It depends upon
the age and utilization of the device.
To perform a restore process, follow these steps:
1. Enter bootloader mode on the pinnacle 100. You can achieve this by holding P0.31 (pin 16 on the M.2 connector) low
and rebooting the module or powering it up (on the development board, hold down SW1 and press the reset button).
2. Open a serial utility such as UwTerminalX and select the correct serial port connected to the Pinnacle 100 module with
the following settings:
▪ Hardware flow control enabled
▪ Baud rate set to 115200
▪ 1 stop bit
▪ No parity
The CTS status should be green to indicate that the module is ready to accept commands.
3. Send a new-line character (by pressing enter on the terminal) to confirm that it is in bootloader mode. The response
should be f and a hex character. In UwTerminalX, this takes the form of a slash (\) followed by two numbers.
4. Right click on the UwTerminalX window and select Automation.
5. Check the Un-Escape Strings box.
6. In the top field, add the following data: p\0f\51\2a\51
7. In the second field, add the following data: \7f\7f
8. If the automation window is in the way of the terminal window, move it so that both are visible.
9. Click Send next to the top field to unlock the bootloader. The module should respond with an a. If it does not, then there
is an issue with your setup or configuration, or you are using a different (incompatible) module.
10. Click Send next to the second field to begin the restore process.The module should not emit a response for some time.
Once complete, the module should output a. If it emits an f, then an error occurred during the erase process. The erase
process usually takes two minutes but may take up to five minutes under certain circumstances.
The module is now restored to factory defaults, excluding resetting any security bits. It can now be used or programmed
as desired.
typedef struct
{
uint32_t Checksum;
uint32_t ExternalFunctionAddress;
uint16_t HeaderVersion;
uint16_t ExternalFunctionVersion;
uint16_t HeaderSize;
char BuildDate[12];
uint8_t ChecksumType;
uint8_t Areas;
AreaInfoStruct AreaInfo[3];
uint8_t PADDING[52];
} ExternalSettingsInfoStruct;
typedef struct
{
uint32_t StartAddress;
uint32_t Size;
uint32_t Checksum;
uint16_t Version;
uint8_t Type : 3;
uint8_t Access : 3;
uint8_t SignatureType : 2;
uint8_t Signature[64];
} AreaInfoStruct;
The Bootloader blocks read access after it has booted. Attempting to read the bootloader data from flash by a user application
causes a hard-fault on the module.
Note: For Zephyr users, this is already included in the Pinnacle 100 Zephyr project source code and can be enabled by
selecting the Blr Laird Connectivity HAL module.
uint8_t
GetBootloaderSetting(
uint32_t nIndex,
uint8_t nPartition,
uint8_t nSubKey,
uint8_t *pBuffer,
uint32_t nBufferSize,
uint32_t *pFullSettingSize,
uint16_t *pFlags
);
The Pinnacle 100 Zephyr out of box demo application with source available on github demonstrates how to query information
from the bootloader.
Checksums used in update packages and for verification of sections can be calculated using the following C code.
Note: For Zephyr users, this is already included in the Pinnacle 100 Zephyr project source code and can be enabled by
selecting the Msc Laird Connectivity HAL Module):
/******************************************************************************
** Copyright (C) 2020 Laird Connectivity
**
** Project: Zephyr
**
** Module: MscCRC32.c
**
** Mnemonic: Msc
**
** Notes:
**
** License: This code is for use only in projects based around the Laird
** Connectivity Pinnacle 100 module (including PC or embedded
** device applications). All other use of this code is prohibited.
**
** All rights reserved.
**
** It is provided "as is", without warranty/guarantee of any kind,
** express of implied, including but not limited to the warranties
** of merchantability, fitness for a particular purpose and
** non-infringement.
**
/******************************************************************************/
/* Local Functions or Private Members*/
/******************************************************************************/
/*=============================================================================*/
#define CRC32_POLYNOMIAL 0xEDB88320
/*=============================================================================*/
static uint32_t
MscPubCalc32bitForByte(
uint8_t nByte
)
{
uint8_t nBitCount=8;
uint32_t nCrc32 = nByte;
while(nBitCount--)
{
if(nCrc32 & 1)
{
nCrc32 = (nCrc32 >> 1)^CRC32_POLYNOMIAL;
}
else
{
nCrc32 >>= 1;
}
}
return nCrc32;
}
/*=============================================================================*/
/* Given an array of bytes, a new 32 bit CRC is calculated. */
/*=============================================================================*/
uint32_t
MscPubCalc32bitCrcNonTableMethod(
uint32_t nCrc32,
const uint8_t *pSrcStr,
uint32_t nSrcLen /* in bytes */
)
{
uint32_t nTemp1,nTemp2;
while(nSrcLen--)
{
nTemp1 = (nCrc32 >> 8) & 0x00FFFFFFL;
nTemp2 = MscPubCalc32bitForByte( (uint8_t)((nCrc32 ^ *pSrcStr++) & 0xFF) );
nCrc32 = nTemp1 ^ nTemp2;
}
return nCrc32;
}
/******************************************************************************/
/* END OF FILE*/
/******************************************************************************/
The MscPubCalc32bitCrcNonTableMethod() function contains the following three parameters:
▪ nCrc32 – Input to CRC function. This is used for chained checksum code and should be 0 for the first input to the
function.
▪ pSrcStr – The pointer to the data for which a checksum is to be calculated.
▪ nSrcLen – The length, in bytes, of the input data
The return value is the 32-bit checksum of the input data. If the function must run multiple times for each block of data, then
the checksum value should be initialised to 0 and provided to the function in the nCrc32 parameter.
5-6 QSPI user sectors Enabling QSPI Usage For User Applications QSPI user sections
7 Block UART verification Blocking UART Data Verification Block UART verification
UART verification
8-9 Limiting UART Data Verification UART verification minimum size
minimum size
10 Boot verification Boot Verification Boot verification
Main application/Soft-
Main Application/Soft-Device Section Main application/Soft-device section
11 device section
Protection protection
protection
12 Erase section mode Setting Erase Section Mode Erase section mode
To create a partition in a .ubu file which sets bootloader settings, the extradata parameter is used. This parameter ontains 13
bytes of data, each byte offset corresponds to the feature in Table 15.
Any options which are to be left at their default values should be supplied at 00 to the extradata parameter. Any setting with a
non-00 value is configured on the module, assuming that the configuration option set is valid and does not lower security.
For example, if a module has boot verification set to a value of 0x01 and a partition section is present which sets it to 0x02,
then the additional setting is ignored and the setting remains at 0x01. However, if a partition section is present which sets it to
0x03, then the setting is updated to 0x03.
When using the extradata command, be sure that the configuration value is placed at the correct offset, the values are entered
with the MSB being the first offset. For example: If --aX-extradata 010203 is used, then 01 is offset 0 (readback protection), 02
is offset 1 (CPU debug protection), and 03 is offset 2 (block UART readback). Any missing offset values are set to 0. Values
which span more than 1 byte (8-bits) such as the QSPI user sectors or UART verification minimum size are stored in little-
endian format with the LSB being the first byte. For example: If --aX-extradata 00000000003412 is used, then the QSPI user
sectors value is entered as 3412 and is read as 0x1234 when the bootloader processes it.
Offset 2: --aX-extradata XXXXYY where YY is as shown in the following table (Table 18).
Table 18: Block UART readback values
Value (hex) Description
00 No change
01 Block UART readback
This configures blocking the UART read data command for the module.
Offset 3: --aX-extradata XXXXXXYY where YY is as shown in the following table (Table 19).
Table 19: QSPI mode values
Value (hex) Description
00 No change
01 Ultra-low power mode
02 High performance mode
This configures the default QSPI mode for the module. Please see the Configuring QSPI Power/Mode section for details on
what these modes do.
Offset 4: --aX-extradata XXXXXXXXYY where YY is as shown in the following table (Table 20).
Table 20: Full erase mode values
Value (hex) Description
00 No change
01 Allow if no Bootloader Unlock Key or only allow if Bootloader Unlock Key is set and entered correctly
02 Allow only if Bootloader Unlock Key is set and entered correctly
03 Always Deny
This configures the if the full erase command is allowed from the bootloader.
Offsets 5-6: --aX-extradata XXXXXXXXXXYYYY where YYYY is a little-endian number containing the number of QSPI flash
sectors from the end of the device which are available for use by the user application. The QSPI flash has a 4-KB sector size
and up to 50% of the QSPI flash is available for the user application. A value of 0 ignores the setting and a value of 1-1024
sets the number of sectors to the desired value. For further details, see the Enabling QSPI Usage For User Applications
section.
Offset 7: --aX-extradata XXXXXXXXXXXXXXYY where YY is as shown in the following table (Table 21).
Table 21: Block UART verification values
Value (hex) Description
00 No change
01 Block UART verification
This configures blocking the UART verify data command for the module.
Offsets 8-9: --aX-extradata XXXXXXXXXXXXXXXXYYYY where YYYY is a little-endian number containing the minimum
UART verification size in bytes. A value of 0 ignores the setting and a value of 4-16384 (must be divisible by the flash write
size - 4) sets the minimum UART verification size to the desired value. For further details, see the Limiting UART Data
Verification section.
Note: This is a two-byte (16-bit) little-endian number and is supplied as an argument with the LSB byte first. For example:
0x5678 would be supplied on the command line as 7856.
Offset 10: --aX-extradata XXXXXXXXXXXXXXXXXXXXYY where YY is as shown in the following table (Table 22).
Table 22: Boot verification values
Value (hex) Description
00 No change
01 MBR
02 Bootloader
04 External function
08 Main application
10 Soft-device
20 Compromised boot chain
40 Sections required
80 Prevent boot
This list contains the different bitmask options for all the individual features. Multiple features can be combined into a single
value which enables all of those options. For example: adding MBR, external function, compromised boot chain and prevent
boot = 0x01 + 0x04 + 0x20 + 0x80 = 0xA5.
This command configures the boot verification level for the module.
Offset 11: --aX-extradata XXXXXXXXXXXXXXXXXXXXXXYY where YY is as shown in the following table (Table 23).
This command configures the main application and/or soft-device section for the module.
Offset 12: --aX-extradata XXXXXXXXXXXXXXXXXXXXXXXXYY where YY is as shown in the following table (Table 24).
Table 24: Erase section mode values
Value (hex) Description
00 No change
01 Block lower versions
02 Block equal versions
03 Block lower or equal versions
04 Block user-signed sections
05 Block user-signed sections and lower version Laird Connectivity-signed sections
06 Block user-signed sections and equal version Laird Connectivity-signed sections
07 Block user-signed sections and lower or equal version Laird Connectivity-signed sections
08 Block Laird Connectivity-signed sections
09 Block Laird Connectivity-signed sections and lower version user-signed sections
0a Block Laird Connectivity-signed sections and equal version user-signed sections
0b Block Laird Connectivity-signed sections and lower or equal version user-signed sections
0f Block all erase sections
Italic indicates an option is a mix of other options, non-italic indicates an option is a single option.
This configures the erase section mode of the module.
Bootloader configuration options must be in their own self-contained partition in an upgrade image. They cannot be added to
another partition’s data (e.g. an application update). A version must be specified, the filetype must be specified as 13, the
target must be specified as 3 and the keytype must be specified as 1, the options are then placed in the extradata field, like so:
These sections can be placed before or after upgrade data. The options are updated prior to any section updates being
processed.
Once a .ubu or .hex file with bootloader settings is programmed to the module, it should be reset and not interrupted until
either the user application boots or UART bootloader boots (if no user application is present). Before using a file in production,
the settings on the module should be queried from the bootloader to ensure that they are all valid and were accepted. It is best
to do this on a fresh module or on one which is restored to factory defaults (if readback protection and CPU debug protection
were never previously used on the module) or by doing a full chip erase and reprogramming the bootloader. Guides for both
actions are available in the Restoring to Factory Defaults (via UART) and Full-Chip Erase/Recovery (via SWD) sections
respectively.
Enabled readback protection and CPU debug protection, with an application named Blinky.hex where the application is placed
after the bootloader settings section, UBUtil command:
UBUtil --application-key-file Blinky.pem --a0-version 1 --a0-filetype 13 --a0-extradata 0101
--a0-target 3 --a0-keytype 1 --a1-version 1 --a1-compressed --a1-target 0 --a1-startaddress
0x1000 --a1-filetype 1 --a1-filename Blinky.hex --a1-keytype 1 --append-pub-key --output
Example_1.hex --ubu-platform 512A510F --ubu-flash-size 8M --ubu-sector-size 4K --ubu-base-
address 0 --ubu-align-length 4 --ubu-output Example_1.uwf
The output from UBUtil is similar to the following:
Laird Connectivity Universal Bootloader Firmware Update Generation Utility
v1.0
Built Apr 24 2020
Header:
Update header version: 1
Sections present: 3
Checksum: 0x04152166
Section 0:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: Bypass
Image Checksum: 0x00000000
Target Checksum: 0x00000000
Signature Type: 1 (User key)
Application Type: 13 (Bootloader settings)
Header Checksum: 0x6e9766ca
Filename: [Not Present]
Extra data (hex):
0101000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
c843202ec48534ff4f30b5497ffc863a5f81888549b9663ad6e646fdcb1a280a04eb0c7c71f1c89ed3b71610b54
d097a8e8aae114276979ee942185386c8fdfb
Section 1:
Section Start: 0x4000
Section End: 0x306df
Section Size: 0x2c6df
Target: 0 (Internal flash)
Target Start: 0x1000
Target End: 0x39ba0
Target Size: 0x38ba0
Compressed: Yes
Version: 1
Checksum Type: 32-bit
Section 2:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
Header Checksum: 0xb471376d
Filename: Blinky.pem
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
d24deb7ab6c3922d1fd561d0917304c00ece98a4b8bad9b0bd09ed4647edeb0eb5f938693a03ed52ac3f716b0b5
00cfc386bf8a77f4f49ff3b8b4eb4a4ca0470
Sets boot verification to full and minimum UART verification size to 32 bytes with an application named Blinky.hex where the
application is placed before the bootloader settings section, UBUtil command:
UBUtil --application-key-file Blinky.pem --a0-version 1 --a0-compressed --a0-target 0 --a0-
startaddress 0x1000 --a0-filetype 1 --a0-filename Blinky.hex --a0-keytype 1 --a1-version 1 --
a1-filetype 13 --a1-extradata 00000000000000002000FF --a1-target 3 --a1-keytype 1 --append-
pub-key --output Example_2.hex --ubu-platform 512A510F --ubu-flash-size 8M --ubu-sector-size
4K --ubu-base-address 0 --ubu-align-length 4 --ubu-output Example_2.uwf
The output from UBUtil is similar to the following:
Laird Connectivity Universal Bootloader Firmware Update Generation Utility
v1.0
Built Apr 24 2020
Header:
Update header version: 1
Sections present: 3
Checksum: 0x04152166
Section 0:
Section Start: 0x4000
Section End: 0x306df
Section Size: 0x2c6df
Target: 0 (Internal flash)
Target Start: 0x1000
Target End: 0x39ba0
Target Size: 0x38ba0
Compressed: Yes
Version: 1
Checksum Type: 32-bit
Image Checksum: 0x7bc86c9e
Target Checksum: 0x1e5c79e0
Signature Type: 1 (User key)
Application Type: 1 (Main Application)
Header Checksum: 0x3140d90f
Filename: Blinky.hex
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
32ffdc3c7bf454906253ee24b60f71015ce1be4ab23e583b76d105145317de4a6439da1141d057b355582d7ffa7
41bcd12369c5bda0cd5722781784c2278a3c6
Section 1:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: Bypass
Image Checksum: 0x00000000
Target Checksum: 0x00000000
Signature Type: 1 (User key)
Application Type: 13 (Bootloader settings)
Header Checksum: 0xc56fc292
Filename: [Not Present]
Extra data (hex):
00000000000000002000ff000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
2d7091c8e55cdaf925ab1a2d71cbbe5644b30f2df2f391539c1e8fed4ecc4b97d33a562d2722c291414d2e53049
f14d4b908912785e543742eec9a8f3088f424
Section 2:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Sets QSPI mode to high performance and enables 8 QSPI flash sectors to be used by the user application, UBUtil command:
UBUtil --application-key-file Blinky.pem --a0-version 1 --a0-filetype 13 --a0-extradata
00000002000800 --a0-target 3 --a0-keytype 1 --append-pub-key --output Example_3.hex --ubu-
platform 512A510F --ubu-flash-size 8M --ubu-sector-size 4K --ubu-base-address 0 --ubu-align-
length 4 --ubu-output Example_3.uwf
The output from UBUtil looks similar to the following:
Laird Connectivity Universal Bootloader Firmware Update Generation Utility
v1.0
Built Apr 24 2020
Header:
Update header version: 1
Sections present: 2
Checksum: 0x56f6cb3c
Section 0:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: Bypass
Image Checksum: 0x00000000
Target Checksum: 0x00000000
Signature Type: 1 (User key)
Application Type: 13 (Bootloader settings)
Header Checksum: 0x22749910
Section 1:
Section Start: 0x0
Section End: 0x0
Section Size: 0x0
Target: 3 (Settings)
Target Start: 0x0
Target End: 0x0
Target Size: 0x0
Compressed: No
Version: 1
Checksum Type: 32-bit
Image Checksum: 0xf2a52abf
Target Checksum: 0x00000000
Signature Type: 254 (Bypass)
Application Type: 12 (User public key)
Header Checksum: 0xb471376d
Filename: Blinky.pem
Extra data (hex):
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000
Signature (hex):
d24deb7ab6c3922d1fd561d0917304c00ece98a4b8bad9b0bd09ed4647edeb0eb5f938693a03ed52ac3f716b0b5
00cfc386bf8a77f4f49ff3b8b4eb4a4ca0470
The Pinnacle 100 features a bootloader status LED output on P1.07 (connected to LED4 on the Pinnacle 100 development
board). This line is used by the bootloader to indicate the status of the bootloader which is displayed in the following table
(active high) (Table 25).
Table 25: Bootloader status LED
Pattern Meaning
Fading in/out (PWM) In UART bootloader, awaiting handshake
3 blinks In UART bootloader, awaiting data
5 blinks Initialising
7 blinks Updating
9 blinks Modem updating
11 blinks Full erase in progress
Always on Fatal bootloader error, module in low power mode
The modem on the Pinnacle 100 can be upgraded using differential patch files which can be included in hex/ubu firmware
update packages, these packages will be distributed on the Pinnacle 100 website and work in the same way bootloader
update files work, see the Using Signed Image Header Files section for details on how to include these files in your update
packages.
There is also a debug UART connector on the Pinnacle 100 development board connected to the modem which allows for the
firmware to be loaded directly to the modem without using differential patch files and can be loaded much faster. Note that
modem firmware updates using the debug UART on Windows 10 (or newer).
To update the modem firmware using UART, a 1.8v USB cable (FTDI or compatible) must be connected to the ‘HL7800 FTDI
1’ port on the Pinnacle 100 development board which has the following pinout:
Pin Function
1 Ground
3 1.8v (no-connect)
4 Transmit (TX)
5 Receive (RX)
15. The modem firmware upgrade process will begin and will take 10-25 minutes to complete if no errors are encountered
16. Once complete, remove the serial cable from the ‘HL7800 FTDI 1’ port
The bootloader on the Pinnacle 100 and the PC utilities used for generating firmware or flashing firmware to Pinnacle 100
modules utilises code from other software authors whose licenses are as follows:
Uses b64.c from https://github.com/littlstar/b64.c (MIT License) Copyright (c) 2014 Little Star
Media, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Uses sha256.c from tinycrypt (c) 2017, Intel Corporation. All Rights Reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials provided
with the distribution.
- Neither the name of Intel Corporation nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior written
permission.
Uses uECC from https://github.com/kmackay/micro-ecc/ Copyright (c) 2014, Kenneth MacKay. All
rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials provided
with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
Redistribution and use of object code, header files, and documentation, without modification,
are permitted provided that the following conditions are met:
1) Redistributions must reproduce the above copyright notice and the following disclaimer in
the documentation and/or other materials provided with the distribution.
2) Unless to the extent explicitly permitted by law, no reverse engineering, decompilation,
or disassembly of is permitted.
3) Redistribution and use is permitted solely for the purpose of developing or executing
applications that are targeted for use on an ARM-based product.
Copyright (C) 2001-2006 Bart Massey, Jamey Sharp, and Josh Triplett.
All Rights Reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the 'Software'), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the names of the authors or their institutions shall not
be used in advertising or otherwise to promote the sale, use or other dealings in this Software
without prior written authorization from the authors.
Copyright (C) 1998, 1999, 2000 Thai Open Source Software Center Ltd and Clark Cooper
Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006 Expat maintainers.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the 'Software'), to deal in the Software without
1. The origin of this software must not be misrepresented; you must not claim that you wrote
the original software. If you use this software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as
being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly Mark Adler
[email protected] [email protected]
This program, 'bzip2', the associated library 'libbzip2', and all documentation, are copyright
(C) 1996-2010 Julian R Seward. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. The origin of this software must not be misrepresented; you must not claim that you wrote
the original software. If you use this software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
HarfBuzz is licensed under the so-called 'Old MIT' license. Details follow.
Copyright (C) 2010,2011,2012 Google, Inc.
Copyright (C) 2012 Mozilla Foundation
Copyright (C) 2011 Codethink Limited
Copyright (C) 2008,2010 Nokia Corporation and/or its subsidiary(-ies)
Copyright (C) 2009 Keith Stribley
Copyright (C) 2009 Martin Hosken and SIL International
Copyright (C) 2007 Chris Wilson
Copyright (C) 2006 Behdad Esfahbod
Copyright (C) 2005 David Turner
Copyright (C) 2004,2007,2008,2009,2010 Red Hat, Inc.
Copyright (C) 1998-2004 David Turner and Werner Lemberg
For full copyright notices consult the individual files in the package.
Permission is hereby granted, without written agreement and without license or royalty fees,
to use, copy, modify, and distribute this software and its documentation for any purpose,
provided that the above copyright notice and the following two paragraphs appear in all copies
of this software.
IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL,
INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
DOCUMENTATION, EVEN IF THE COPYRIGHT HOLDER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE COPYRIGHT HOLDER SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN 'AS IS' BASIS, AND THE COPYRIGHT HOLDER HAS NO OBLIGATION TO PROVIDE
MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
The FreeType 2 font engine is copyrighted work and cannot be used legally without a software
license. In order to make this project usable to a vast majority of developers, we distribute
it under two mutually exclusive open-source licenses.
This means that *you* must choose *one* of the two licenses described below, then obey all its
terms and conditions when using FreeType 2 in any of your projects or products.
- The FreeType License, found in the file `FTL.TXT', which is similar to the original BSD
license *with* an advertising clause that forces you to explicitly cite the FreeType project
in your product's documentation. All details are in the license file. This license is suited
to products which don't use the GNU General Public License.
D-Bus is licensed to you under your choice of the Academic Free License version 2.1, or the
GNU General Public License version 2 (or, at your option any later version).
ICU License - ICU 1.8.1 and later Copyright (c) 1995-2015 International Business Machines
Corporation and others. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the 'Software'), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, provided that the above copyright notice(s) and this permission notice
appear in all copies of the Software and that both the above copyright notice(s) and this
permission notice appear in supporting documentation.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS
INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL
DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH
THE USE OR PERFORMANCE OF THIS SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not be used in
advertising or otherwise to promote the sale, use or other dealings in this Software without
prior written authorization of the copyright holder.
Uses Qt 5, Copyright (C) 2020 The Qt Company, licensed under the GPLv3 (not including later
versions).
See https://www.gnu.org/licenses/gpl-3.0.txt for full license terms.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials provided
with the distribution.
5. Products derived from this software may not be called 'OpenSSL' nor may 'OpenSSL' appear in
their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment: 'This
product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit
(http://www.openssl.org/)'
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR").append("
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
====================================================================
This product includes cryptographic software written by Eric Young ([email protected]). This
product includes software written by Tim Hudson ([email protected]).
This library is free for commercial and non-commercial use as long as the following conditions
are adhered to. The following conditions apply to all code found in this distribution, be it
the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included
with this distribution is covered by the same copyright terms except that the holder is Tim
Hudson ([email protected]).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be
removed.
If this package is used in a product, Eric Young should be given attribution as the author of
the parts of the library used.
This can be in the form of a textual message at program startup or
in documentation (online or textual) provided with the package.
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions
and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other materials provided
with the distribution.
3. All advertising materials mentioning features or use of this software must display the
following acknowledgement: 'This product includes cryptographic software written by Eric Young
([email protected])' The word 'cryptographic' can be left out if the routines from the library
being used are not cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from the apps directory
(application code) you must include an acknowledgement: 'This product includes software written
by Tim Hudson ([email protected])'
The licence and distribution terms for any publicly available version or derivative of this
code cannot be changed. i.e. this code cannot simply be copied and put under another distribution
licence
[including the GNU Public Licence.]
The C library "libftdi" is distributed under the GNU Library General Public License version 2.
The C library "libusb" is distributed under the GNU Library Lesser General Public License
version 2.1.
This software is provided by Future Technology Devices International Limited ``as is'' and any
express or implied warranties, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose are disclaimed. In no event shall future
technology devices international limited be liable for any direct, indirect, incidental,
special, exemplary, or consequential damages (including, but not limited to, procurement of
substitute goods or services; loss of use, data, or profits; or business interruption) however
caused and on any theory of liability, whether in contract, strict liability, or tort (including
negligence or otherwise) arising in any way out of the use of this software, even if advised
of the possibility of such damage.
FTDI drivers may be used only in conjunction with products based on FTDI parts.
FTDI drivers may be distributed in any form as long as license information is not modified.