Running CCC Digital Key scenarios using the Shell Interface
The following CCC Digital Key R3 examples are provisioned by default with a shell command line interface accessible via a Terminal application such as Tera Term:
Digital Key Car Anchor
Digital Key Device
After connecting through the Terminal application and pressing the RST switch on the board, a welcome message appears. Entering the command “help” displays the list of available commands and their descriptions. See Figure 1.
List of commands
Owner Pairing Scenario
Owner Pairing establishes a bond between the Digital Key Car Anchor and the Digital Key Device as per the CCC Digital Key R3 specification. The Car Anchor starts advertising using Legacy mode on the 1M PHY. The Device scans and connects. After establishing the connection, the Device performs service discovery. This step enables it to discover the DK Service and learn the PSM value it would use in order to open an L2CAP channel to the Car Anchor. This channel is used to exchange data and security information as part of the Bluetooth Low Energy Out-of-Band (OOB) pairing process. All security information exchanged consists of dummy messages. The applications do not currently implement any of the UWB and Secure Element functionality described by CCC Digital Key R3.
The first step is to run the “factoryreset” command on both boards in order to ensure no previous bonding data is present in non-volatile memory. See Figure 1.
Factory reset on Car Anchor
The next step is to run the “sd” command (Start Discovery) on the Device and the “sd op” command on the Car Anchor (Owner Pairing advertising differs from Passive Entry, using a single Legacy advertising set on the 1M PHY). The Car Anchor starts advertising while the Device scans. Since both boards have been factory reset, they follow the Owner Pairing flow. The output of the commands is shown in Figure 2.
Owner Pairing on Car Anchor
Figure 3 shows the owner pairing on the Device.
Owner Pairing on Device
Parent topic:Running CCC Digital Key scenarios using the Shell Interface
Passive Entry Scenario
The Passive Entry scenario runs after Owner Pairing between a Car Anchor and a Device completes successfully.
To run the Passive Entry demo, first, reset the recently paired boards using either the RST switch or the “reset” command in the shell. Do NOT perform a factory reset, as this removes the bonding information from non-volatile memory.
After reset, run the “sd pe” command on the Car Anchor and “sd” command on the Device as shown in Figure 1 and Figure 2. For the Passive Entry scenario, the Car Anchor advertises using two sets, one Legacy on the 1M PHY and one Extended on the Coded PHY. If bonding data is present, it follows the Passive Entry flow and stops after the successful creation of the L2CAP channel. At this point the application is functional. The output of the command is shown in Figure 1 and Figure 2. Similar to the Owner Pairing scenario, the applications implement only the Bluetooth Low Energy functionality.
Note: The CCC specification requires using coding scheme S=2 for Coded PHY advertising, equivalent to a data rate of 500 Kbits per sec. To experiment with other coding schemes, change the value of the mLongRangeAdvCodingScheme_c macro in the app_preinclude.h file for the digital_key_car_anchor project.
Passive Entry on Car Anchor
Passive Entry on Device
Parent topic:Running CCC Digital Key scenarios using the Shell Interface
Synchronizing bonding data between Car Anchors
Note: On the KW45B41Z-EVK and KW47-EVK platforms, this feature is only valid when Advanced Secure Mode is disabled (gAppSecureMode_d is set to 0 in the app_preinclude.h file). To synchronize bonding data when Advanced Secure Mode is enabled, refer to Running the A2B scenario.
Multiple Car Anchors can reside on a car, acting as a single Bluetooth Low Energy device as far as the Device is concerned. When the Device pairs and bonds with a Car Anchor, that bonding data must be shared with all other anchors. To showcase this functionality, the Car Anchor shell demo offers the “setbd” command.
During owner pairing, the bonding data is displayed in the shell as seen in the Owner Pairing section. By passing this data to the “setbd” command on another Car Anchor, that anchor is able to connect with the original Device and perform the Passive Entry flow.
Note: Currently only the Bluetooth Low Energy bonding data is transferred between anchors. No CCC Digital Key R3-specific keys are exchanged.
Saved bonding data can also be viewed using the “listbd” command and a specific bond can be removed using the “removebd” command. See Figure 1 for details.
A bond can only be removed if a connection to that specific device is not currently active. The commands presented in this subsection are also supported on the Device for test purposes.
Adding bonding data to a Car Anchor, listing bonds and removing a bond
Note:
To simulate anchors residing on the same car, Random Static Address required by the Digital Key protocol and the Identity Resolving Key are set at compile time for the
digital_key_car_anchorproject. To simulate anchors residing on different cars, change the values of theAPP_BD_ADDRandAPP_SMP_IRKmacros in the project’sapp_preinclude.h.
Parent topic:Running CCC Digital Key scenarios using the Shell Interface
Connection with a non-CCC Key Fob Scenario
The Car Anchor also supports connecting as a Bluetooth Low Energy central device (scanner) to a non-CCC key fob (advertiser). To enable scanning on the digital_key_car_anchor project set the gAppScanNonCCC_d macro to 1 in the project’s app_preinclude.h before building.
After flashing the board and running “factoryreset”, run the “sd op” or “sd pe” command exactly as in the Owner Pairing or Passive Entry scenarios. The Car Anchor will simultaneously advertise for a CCC Device and scan for a non-CCC key fob.
Connection with the non-CCC key fob and the subsequent application functionality is currently out of this application note’s scope.
Parent topic:Running CCC Digital Key scenarios using the Shell Interface