Wurth Elektronik ANR005 Proteus-II Instruction Manual

ANR005 PROTEUS-II
ADVANCED DEVELOPER GUIDE
VERSION 1.1
JUNE 18, 2019

The content of this document is property of Würth Elektronik eiSos and con-
tains confidential information. It is not intended to be distributed to any third
party without the written consent of Würth Elektronik eiSos.

Revision history
Manual
version
FW
version
HW
version Notes Date
1.0 1.0.0 2.1
• Initial version
• New corporate design and structure
• Updated chapter for custom firmware
development
November
2018
1.1 1.0.0 2.1
• Updated file name to new AppNote name
structure. Updated important notes, legal
notice & license terms chapters. June 2019
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 1

Abbreviations and abstract
Abbreviation Name Description
BTMAC Bluetooth conform MAC address of the module used
on the RF-interface.
CS Checksum Byte wise XOR combination of the preceding fields.
BLE Bluetooth Low
Energy According to Bluetooth specification.
BT Bluetooth According to Bluetooth specification.
DTM Direct test mode Mode to test Bluetooth specific RF settings.
GAP Generic Access
Profile
The GAP provides a basic level of functionality that all
Bluetooth devices must implement.
I/O Input/output Pinout description.
LPM Low power mode Mode for efficient power consumption.
MAC MAC address of the module.
MTU Maximum
transmission unit Maximum packet size of the Bluetooth connection.
Payload The intended message in a frame / package.
RF Radio frequency Describes wireless transmission.
RSSI Receive Signal
Strength Indicator
The RSSI indicates the strength of the RF signal. Its
value is always printed in two’s complement notation.
Soft device Operating system used by the nRF52 chip.
UART
Universal
Asynchronous
Receiver
Transmitter
Allows the serial communication with the module.
[HEX] 0xhh Hexadecimal
All numbers beginning with 0x are hexadecimal
numbers. All other numbers are decimal, unless
stated otherwise.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 2

Contents
1 Introduction 5
2 Prerequisites 5
3 Bluetooth profiles 5
4 AMBER SPP-like profile 6
4.1 Generic Access Protocol (GAP) . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Generic Attribute Profile (GATT) . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1 Data length extension . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2 Companyidentifier ........................... 7
4.2.3 UUID................................... 7
4.2.4 PrimaryService............................. 8
4.2.4.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 BLEpacketcontent................................ 8
4.3.1 RF-Packetformat ............................ 8
4.3.2 Advertising packet content . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.3 Scan response packet content . . . . . . . . . . . . . . . . . . . . . 9
5 App development 10
5.1 Connection setup message charts . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 No security and authentication . . . . . . . . . . . . . . . . . . . . . 10
5.1.2 Justworkspairing............................ 10
5.1.3 Static pass key pairing . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Bonding development hints . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3 Nordic BLE UART example app as base . . . . . . . . . . . . . . . . . . . . 13
6 Custom firmware development 15
6.1 Custom firmware services of Würth Elektronik eiSos . . . . . . . . . . . . . 16
6.2 Important information for custom firmware development . . . . . . . . . . . 16
6.2.1 How to adapt Nordic Semiconductor SDK examples to run on the
Proteus-IIhardware?.......................... 19
6.2.2 Firmware development hints . . . . . . . . . . . . . . . . . . . . . . 21
7 Important notes 23
7.1 General customer responsibility . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2 Customer responsibility related to specific, in particular safety-relevant ap-
plications ..................................... 23
7.3 Best care and attention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.4 Customer support for product specifications . . . . . . . . . . . . . . . . . . 23
7.5 Productimprovements.............................. 24
7.6 Productlifecycle ................................. 24
7.7 Propertyrights .................................. 24
7.8 General terms and conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8 Legal notice 25
8.1 Exclusionofliability................................ 25
8.2 Suitability in customer applications . . . . . . . . . . . . . . . . . . . . . . . 25
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 3

8.3 Trademarks .................................... 25
8.4 Usagerestriction ................................. 25
9 License terms 27
9.1 Limitedlicense .................................. 27
9.2 Usageandobligations .............................. 27
9.3 Ownership..................................... 28
9.4 Firmwareupdate(s)................................ 28
9.5 Disclaimerofwarranty .............................. 28
9.6 Limitationofliability................................ 29
9.7 Applicable law and jurisdiction . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.8 Severabilityclause ................................ 29
9.9 Miscellaneous................................... 29
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 4

1 Introduction
This document provides all the information necessary to integrate the Proteus-II BLE module
into user application. The standard features available with the default firmware are described
in detail. Further, key parameters of the BLE specifications necessary to ensure interoper-
ability with Bluetooth compliant third party devices are listed and described in detail.
Besides of this, valuable hints to start an app development as well as to start a custom
firmware development on base of the Proteus-II hardware are given in the subsequent chap-
ters.
2 Prerequisites
A basic understanding of the Bluetooth Low Energy standard as well as application devel-
opment background on the desired platform is necessary to fully understand this document.
The manual of Proteus-II contains basic information of the standard firmware and the soft-
ware interfaces provided by the application. Please read this manual carefully and complete-
ly before using its information.
Würth Elektronik eiSos does not provide general support towards the Bluetooth standard or
smart device app development (independent of the platform).
3 Bluetooth profiles
Bluetooth specification uses so called "Profiles" to specify the general behavior of a Blue-
tooth enabled device to communicate with other Bluetooth devices. Profiles are built on the
Bluetooth standard to clearly define what kind of data is transmitted. The device’s application
determines which profiles it must support, from hands-free capabilities to heart rate sensors
to alerts and more.
A device may support more than one profile. For two devices to be compatible, they must
support the same BLE profile.
The Proteus-II module ships with the so called AMBER SPP-like (Serial Port Profile) profile
created based on the Generic Attribute profile (GATT). This profile aims at providing a BLE
based wireless replacement to a serial cable connection.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 5

4 AMBER SPP-like profile
This section contains the key data of the AMBER SPP-like profile. Each device in the net-
work must support this profile to communicate with an Proteus-II device with the default
SPP-like firmware. Customer applications may support and/or provide other profiles, ser-
vices or interfaces.
4.1 Generic Access Protocol (GAP)
The main purpose of this protocol is to describe the parameters of lower layers of the Blue-
tooth stack including discovery, scanning and security capabilities. The Proteus-II GAP spec-
ifications are listed below:
• Appearance as specified in the user setting RF_Appearance .
• Device name as specified in the user setting RF_DeviceName .
• Device address (6 Byte MAC) of type "public", see user setting FS_BTMAC (0x0018DAxxxxxx)
• Timings:
–See user settings RF_ScanTiming and RF_ScanFlags for scan and advertising re-
lated timing parameters like
*Advertising interval
*Scan window
*Scan interval
*Connection setup timeout
–See user setting RF_ConnectionTiming for connection related timing parameters
like
*Minimum connection interval
*Maximum connection interval
*Connection supervision timeout
–See user setting RF_TXPower for TX power value.
–See user setting RF_SecFlags for security settings.
–Slave latency: 0
–Peripheral requests for connection parameters update if central has differing con-
nection parameters
*Connection parameters update (initial): 5s
*Connection parameters update (periodic): 10s
*Connection parameters update counter before connection shut down: 3
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 6

4.2 Generic Attribute Profile (GATT)
The directions RX and TX in this document are described from the perspective
of a central role, see description below.
4.2.1 Data length extension
The Proteus-II supports up to 243 Byte of payload data. To use this feature the data length
extension has to be requested by the central device. In this case, the GATT MTU size must
be 243 Byte payload + 1 Byte AMBER header + 3 Byte NUS header, which is 247 Byte in
total.
The PDU size should be 243 Byte payload + 1 Byte AMBER header + 3 Byte NUS header +
4 Byte BLE header, which is 251 Byte in total.
Check also the message charts in chapter 5 to see the MTU request in the connection setup
process.
4.2.2 Company identifier
The Bluetooth listed company identifier of Würth Elektronik eiSos (formerly Amber wireless
GmbH) is 0x031A (794dec).
4.2.3 UUID
The Proteus-II uses a 128Bit UUID of type "Vendor specific". The base UUID is adapted by
the 16Bit UUIDs of the primary service and the corresponding characteristics.
These UUIDs are only allowed to be used when one of the two corresponding devices is a
Proteus-II BLE module or contains a Proteus-II BLE module of Würth Elektronik eiSos which
have installed AMBER SPP-like firmware.
Service 16Bit UUID Full UUID
Proteus-II base 6E400000-C352-11E5-953D-0002A5D5C51B
Proteus-II primary service 0x0001 6E400001-C352-11E5-953D-0002A5D5C51B
TX_CHARACTERISTIC 0x0002 6E400002-C352-11E5-953D-0002A5D5C51B
RX_CHARACTERISTIC 0x0003 6E400003-C352-11E5-953D-0002A5D5C51B
By means of the user setting RF_SPPBaseUUID the base UUID can be adapted
to generate a custom profile.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 7

4.2.4 Primary Service
4.2.4.1 Characteristics
• The first characteristic of the Proteus-II primary service is TX_CHARACTERISTIC :
–The data is sent from central/client to peripheral/server using a write command.
–Server:
*Has to allow a write command as well as a write without response command.
–Client:
*Use write command to send data to the server.
• The second characteristic of the Proteus-II primary service is RX_CHARACTERISTIC :
–The data is sent from peripheral/server to central/client using a notification.
–Server:
*Has to allow/enable notifications. Notify client/central when sending data.
*When the notification enable bit is written in the
CCCD (Client Characteristic
Configuration Descriptor) by the central, the peripheral prints a CMD_CHANNELOPEN_RSP
on the UART to signalize that the peripheral can send data to the central now.
The central can only write this bit, when the configured security level of the
peripheral has been met.
–Client:
*Has to enable notifications.
The permissions to access the characteristics is determined by the security mode of the
module.
Proteus-II
security mode CCCD read CCCD write, RX attribute read/write, TX attribute read/write
No security no protection, open
link no protection, open link
Just works no protection, open
link
require encryption, but no MITM protection
(Mode 1, Level 2)
Static pass key no protection, open
link
require encryption and MITM protection
(Mode 1, Level 3)
4.3 BLE packet content
4.3.1 RF-Packet format
To identify the type of data transmitted via BLE, we introduced a 1 Byte packet header.
Thus, the standard BLE payload has to match the following format to be understood by the
Proteus-II:
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 8

BLE Payload
AMBER Header Payload
1 Byte ΦST Bytes
Table 1: RF-packet format
The maximum payload size ΦST is 243 Bytes.
The AMBER Header has to be one of the following types:
0x01: RF_HEADER_TYPE_DATA : The following bytes contain the user payload data.
Other: Other headers are reserved for future use and packets with this header are currently
discarded.
4.3.2 Advertising packet content
The standard Proteus-II advertising packet contains the following data:
• Advertising data flags
• The UUID (128 Bit Proteus-II primary service UUID) of the AMBER SPP-like profile
• TXPower level (1 Byte in two’s complement notation, only in command mode)
• Proteus-II device name as Shortened Local Name (up to 5 Bytes in command mode,
up to 8 Bytes in peripheral only mode)
4.3.3 Scan response packet content
The scan response packet is requested during scan if active scanning is enabled. The
standard Proteus-II scan response packet contains the following data:
• Manufacturer data (up to 20 Bytes) in RF-packet format (see Table 1 ) using the com-
pany identifier. This manufacturer data is used to realize the Beacon feature.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 9

5 App development
The definition of the AMBER SPP-like profile (see section 4 ) in combination with the mes-
sage charts of chapter 5 are sufficient to develop custom apps for mobile devices. To imple-
ment this profile from scratch fundamental knowledge of app development as well as of the
BLE standard is required.
5.1 Connection setup message charts
The following message charts show which steps are run during the connection setup pro-
cess between two Proteus-II modules. To implement the central role in an app to connect to
the Proteus-II peripheral the steps of the central device shown below have to be reproduced.
More detailed information can be found in the message chart chapter of Nordic Semicon-
ductor’s documentation of the Softdevice S132 V6.0.0.
5.1.1 No security and authentication
If the Proteus-II peripheral does not use any security settings, we just have to connect to
it. After connecting a MTU request is necessary to allow a higher payload size. After the
discovery of the characteristics, the notification of the RX characteristic has to be enabled.
Figure 1: No security enabled
5.1.2 Just works pairing
If the Proteus-II peripheral needs the just works pairing security level, we just have to place a
just works pairing request (no in/out capabilities, no mitm) after the connection step was run.
Here a MTU request is necessary again to allow a higher payload size. After the discovery
of the characteristics, the notification of the RX characteristic has to be enabled.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 10

Figure 2: Just works pairing enabled
5.1.3 Static pass key pairing
If the Proteus-II peripheral needs the static pass key pairing security level, we just have
to place a pairing request (keyboard only, mitm) after the connection step was run. The
Proteus-II sends a pass key request, such that the static pass key of the Proteus-II peripheral
has to be entered on the central side (app).
Afterwards a MTU request is necessary again to allow a higher payload size. After the
discovery of the characteristics, the notification of the RX characteristic has to be enabled.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 11

Figure 3: Static pass key pairing enabled
.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 12

5.2 Bonding development hints
The firmware of the Proteus-II provides the bonding feature that allows to re-pair without
repeating the authentication step (e.g. entering the static passkey). Thus, in the initial
connection all bonding data is stored in the devices’ flash to be used during the setup of
subsequent connections.
The function CMD_DELETEBONDS_REQ of the Proteus-II allows to remove not needed bond-
ing data from the module’s flash. Thus in case of missing bonding data on one of the two
connection partners, a re-bonding has to be initiated by the central device! Otherwise, the
security level is not met to send the "notification enable" and thus the channel for data trans-
mission cannot be opened.
Please note that iOS devices do not run the re-bonding step by default, if bond-
ing data is missing on one of the two connection partners.
In certain cases, the bonding data on the iOS device has to be cleared first,
such that iOS starts the re-bonding step.
5.3 Nordic BLE UART example app as base
Nordic Semiconductor provides source code to develop Android, iOS and Windows applica-
tions. To implement the AMBER SPP-like profile for your own app, these source codes can
be taken as a base for your own app development.
Please note that this app does not implement any authentication and security
features. Thus, the Proteus-II to connect to must have no security enabled
when using this provided example.
Furthermore, the request for data length extension is not part of the provided
source code.
The following few changes have to be applied to the Nordic UART-APP-example to imple-
ment the SPP-like profile:
• Replace the implemented UUIDs by the SPP-like profile UUID.
Android example:
priv ate f i n a l s t a t i c UUID UART_SERVICE_UUID = UUID . fr om S tr i ng ( " 6E400001
−C352−11E5−953D−0002A5D5C51B" ) ;
priv ate f i n a l s t a t i c UUID UART_RX_CHARACTERISTIC_UUID = UUID . f ro mSt ri ng
( "6E400002−C352−11E5−953D−0002A5D5C51B" ) ;
priv ate f i n a l s t a t i c UUID UART_TX_CHARACTERISTIC_UUID = UUID . f ro mSt ri ng
( "6E400003−C352−11E5−953D−0002A5D5C51B" ) ;
Code 1: Update UUID
• When sending data, add the packet header in front of the payload.
Android example:
public void send ( final S tr i ng t e x t ) {
/ / Are we connected?
i f ( mRXCharacteristic == n u l l )
return ;
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 13

i f ( ! T e x t U t i l s . isEmpty ( t e x t ) && mOutgoingBuffer == n u l l ) {
f i n a l char AMBER_RF_HEADER_TYPE_DATA = 0x01 ;
f i n a l byte [ ] b u f f e r = mOutgoingBuffer = (AMBER_RF_HEADER_TYPE_DATA +
t e x t ) . getBytes ( ) ;
mBufferOffset = 0 ;
. . .
}
Code 2: Add packet header on sender side
public void onDataSent( final S t r i n g data ) {
i f (AMBER_RF_HEADER_TYPE_DATA == data . c harAt ( 0 ) ) {
Logger . a ( getLogSession ( ) , " V alid data sent : \ " " + data . s ubs tri n g ( 1 ) + "
\ " " ) ;
}
else {
Logger .w( getLogSession ( ) , " I n v a l i d data sent : \ " " + data + " \ " " ) ;
}
. . .
}
Code 3: Check packet header in sender callback
• When receiving data, first interpret the header to detect the data type before any other
action (data output or command execution) is performed.
Android Example:
public void onDataReceived( final S t r i n g data ) {
i f (AMBER_RF_HEADER_TYPE_DATA == data . c harAt ( 0 ) ) {
Logger . a( getLogSession ( ) , " V a lid data received : \ " " + data . s u bst rin g ( 1)
+ " \ " " ) ;
}
else {
Logger .w( getLogSession ( ) , " I n v a l i d data received : \ " " + data + " \ " " ) ;
}
. . .
}
Code 4: Remove packet header on receiver side
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 14

6 Custom firmware development
Using the Proteus-II hardware a custom firmware can be developed to better fit the cus-
tomer’s needs. Based on the Nordic Semiconductor SDK and demo examples various BLE-
profiles and custom applications can be realized and flashed on the Proteus-II module. The
versatile and well documented Nordic stack ensures quick and easy realization of various
standard BLE-profiles. Chapter 6.2 contains the information needed to run Nordic standard
examples on the Proteus-II hardware.
On the other hand, Würth Elektronik eiSos provides firmware development services for cus-
tomers that are not interested in writing their own firmware stack. Here, Würth Elektronik
eiSos can quickly adapt the Proteus-II standard firmware to the customer’s need or com-
pletely develop a new firmware from scratch (see chapter 6.1 ).
Figure 4: Options for running the Proteus-II with standard or custom firmware
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 15

6.1 Custom firmware services of Würth Elektronik eiSos
The Proteus-II firmware as described in the Proteus-II manual includes the Softdevice, a
dual-bank bootloader and the application hosting the SPP-like protocol for RF communica-
tion. After flashing this firmware onto the chip, there are up to 128kB free memory for custom
applications that can be included into the firmware on request.
If more memory is needed, the dual-bank bootloader can be replaced by a single-bank
bootloader or even completely removed. In this case, more than 300kB of memory can be
reserved for custom application code. As an alternative external Flash/EEPROM IC(s) can
be connected to the module (e.g. using SPI or I2C interface) on the customer PCB.
Source codes for the Proteus-II SPP-like firmware are property of Würth Elek-
tronik eiSos and will not be provided to customers. Nonetheless, Würth Elek-
tronik eiSos may consider different license models or exceptions for individual
customers.
Besides of this, Würth Elektronik eiSos also provides custom firmware developments from
scratch. Please contact your local field sales engineer (FSE) or [e-mail]
to discuss further details.
6.2 Important information for custom firmware development
To start a custom firmware development on top of the Proteus-II hardware, the following
information must be considered:
• Chip
The Proteus-II contains the Nordic Semiconductor nRF52832-CHAA SoC. The CPU is
a 64MHz ARM Cortex-M4F.
• Pinout
The Proteus-II provides the following pins of the Nordic SoC with its pads. Only the RF ,
GND,VDD,Reset,SWDCLK and SWDIO pins are fixed. All other pins can be used
for custom firmware development. For special functions like near field communication
(NFC), external low frequency quartz crystal XL or analog input (AIN) the respective
pins have to be used.
No. Pad Name No. Pad Name
1 RF 9 P0.09/NFC1
2, 17 GND 10 P0.00/XL1
3 SWDCLK 11 P0.01/XL2
4 SWDIO 12 P0.02/AIN0
5 P0.21/Reset 13 P0.03/AIN1
6 P0.05/AIN3 14 P0.04/AIN2
7 VDD 15 P0.28/AIN4
8 P0.10/NFC2 16 P0.29/AIN5
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 16

Figure 5: Pinout
• Hardware for development & debugging
Using Segger J-Link flasher and the SWD interface is required for firmware develop-
ment and debugging. Checkout the Proteus-II-EV board. It provides the easiest way
to develop software based on Proteus-II module or apps for the SPP-like profile.
• Software development environment
Nordic Semiconductor provides software packages for several compilers (KEIL, IAR,
GCC, Segger Embedded).
For example, the Keil SDK includes the required BLE stack ("Softdevice"), many demo
examples for BLE profiles and services to conveniently develop a custom firmware on
basis of the Nordic SoC. Further library’s for hardware peripheral (such as ADC, I2C,
SPI, UART etc.) are also include in the SDK and examples. More information and de-
tails about the chip and the operating system is bundled on the Nordic Semiconductor
Infocenter:
http://infocenter.nordicsemi.com/
Please check the tab "nRF52 Series" to access the newest information about the nR-
F52 radio chip and the software environment.
If available, use the examples for the Nordic evaluation platform (like PCA10040 or P-
CA10056) as a starting point. See also chapter 6.2.1 for more information how to run
Nordic standard examples on top of the Proteus-II.
• Clock sources
The Proteus-II module contains a dedicated RF clock (HFCLK). The Proteus-II does
not contain a dedicated low frequency clock (LFCLK). Thus custom firmware must
use the internal RC-oscillator as long as no external clock crystal is connected to the
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 17

respective pins (XL1,XL2) on the customer PCB.
Example for enabling the internal RC oscillator for Softdevice S132 V3.1.0 and SDK
12.3.0:
n r f _ c l o c k _ l f _ c f g _ t c l oc k _ l f _c f g = {
. source = NRF_CLOCK_LF_SRC_RC, \
. r c _ c t i v = 16 ,
. rc_temp_ctiv = 2,
} ;
SOFTDEVICE_HANDLER_INIT(& c l o c k _ l f _ c f g , NULL) ;
Code may differ when using different Softdevice and/or SDK version.
• Voltage regulator
As internal voltage regulator, we recommend to use the DCDC instead of the LDO.
The DCDC has to be switched on explicitly in application code. Example for Softdevice
S132 V3.1.0 and SDK 12.3.0:
sd_power_dcdc_mode_set (NRF_POWER_DCDC_ENABLE) ;
Code may differ when using different Softdevice and/or SDK version.
Changing from LDO to DCDC reduces the current consumption of the module to meet
lowest power specifications.
• Certification
Custom firmware may require additional certification. Please contact your BT certified
testing laboratory regarding this questions.
• BT-Listing
Any (end-)device containing Bluetooth IP must be listed by the BT SIG which requires
membership and qualification. Please contact the BT SIG or your preferred BT cer-
tification laboratory for question. Further information are available in the Proteus-II
manual.
• Serial number
The unique serial number (used for tracing and the generation of the Proteus-II BT-
MAC) is placed in the user information configuration register (UICR->Customer[0]) and
will be removed by flashing a customer firmware onto the SoC.
ANR005 Proteus-II version 1.1 © June 2019
www.we-online.com/wireless-connectivity 18