AAR — Accelerated address resolver

AAR shares the same AES module as the ECB and CCM peripherals. ECB will always have the lowest priority. If there is a sharing conflict during encryption, ECB operation will be aborted and an ERRORECB event will be generated by ECB.

Additionally, AAR shares registers and other resources with the peripherals that have the same ID as AAR. See Peripherals with shared ID for more information.

As per Bluetooth specification, a private resolvable address is composed of six bytes.

To resolve an address, IN.PTR must point to a job list describing both the Hash and Prand parts of the private resolvable address (DEVICEADDR) field from the Bluetooth packet, as well as a number of Identity Resolving Keys (IRK). This is illustrated in the examples below. How many IRKs are used is determined by the number of IRKs in the job list. See EasyDMA for an introduction to EasyDMA job lists.

The resolver is started by triggering the START task. A RESOLVED event is generated if AAR manages to resolve the address using one of the Identity Resolving Keys (IRK). AAR will generate a NOTRESOLVED event if it is not able to resolve the address using the specified list of IRKs. If there are no IRKs in the joblist, the NOTRESOLVED event is generated.

AAR only compares the received address to those programmed in the module without checking the address type.

AAR will stop when it has managed to resolve the maximum number allowed, specified in the MAXRESOLVED register. Each time AAR resolves an IRK, the index of the corresponding IRK is written to memory through the output job list in OUT.PTR. For each IRK found, OUT.AMOUNT is updated accordingly.

The output job list must define a memory region large enough to hold list of resolved IRK indices. This is calculated from the MAXRESOLVED register, where each IRK index occupies two bytes in memory. In the example below, the n indicates the number of bytes (size) in the resolved IRK index array. The value of n must be exactly 2 times the value of MAXRESOLVED.

At the end of the operation, AAR will generate the END event.

Triggering the STOP task will stop AAR. If AAR is stopped before the operation has completed, the END, RESOLVED, and NOTRESOLVED events are not generated. However, if STOP is triggered close to the end of the operation the events can be generated.

This peripheral implements EasyDMA with scatter-gather functionality for reading from memory without CPU involvement.

Example

The figure below shows an example of a job list with three job entries. Each of the entries point to a memory address, and the length field describes how many bytes of data is stored at that address. There are three blocks of memory in use

• Hash, an array of length 3
• Prand, an array of length 3
• Irk, an array of at least length 16

The data pointed to from the job list is what is fed into the module and processed according to the peripheral's operation. The entries of the job list comprises pointers to the individual arrays, as well as their sizes. Job entries with length greater than one are processed in little endian order.

AAR may be started as soon as the 6 bytes required by AAR have been received by RADIO and stored in RAM. The Hash and Prand part of the job list must point to the part of the packet containing the device address.