SWRA667 January   2020 CC1312PSIP , CC1312R , CC1314R10 , CC1352P , CC1352P7 , CC1352R , CC2642R , CC2642R-Q1 , CC2652P , CC2652R , CC2652R7 , CC2652RB , CC2652RSIP

 

  1.   Cryptographic Performance and Energy Efficiency on SimpleLink™ CC13x2/CC26x2 Wireless MCUs
    1.     Trademarks
    2. 1 Abbreviations and Acronyms
    3. 2 Introduction
    4. 3 Benefits of Cryptographic Acceleration in Embedded Security Solutions
    5. 4 TI Drivers for SimpleLink MCUs
      1. 4.1 Power Management Overview
      2. 4.2 Return Behavior
        1. 4.2.1 Runtime Overhead
      3. 4.3 Efficient Power Management
    6. 5 CC13x2/CC26x2 Crypto Peripherals
      1. 5.1 AES and Hash Crypto Accelerator
      2. 5.2 Public Key Accelerator
        1. 5.2.1 ECDH Power Management Driver Example
      3. 5.3 TRNG
    7. 6 Benchmarks
      1. 6.1 AES and Hash Crypto Accelerator Based Drivers
        1. 6.1.1 AES CBC
        2. 6.1.2 AES CCM
        3. 6.1.3 AES GCM
        4. 6.1.4 AES CTR DRBG
        5. 6.1.5 SHA-224
        6. 6.1.6 SHA-256
        7. 6.1.7 SHA-384
        8. 6.1.8 SHA-512
      2. 6.2 PKA Engine Based Drivers
        1. 6.2.1 ECDH
        2. 6.2.2 ECDSA
        3. 6.2.3 ECJPAKE
      3. 6.3 TRNG Based Drivers
        1. 6.3.1 TRNG
    8. 7 Conclusion
    9. 8 References
    10.     Appendix: Plots of Blocking vs Polling Performance

4.1 Power Management Overview

Power management on the SimpleLink CC13x2/CC26x2 devices is intended to be transparent to the application. The device peripheral drivers notify the power driver of the resources they require when they need them without the application directly interacting with the power driver. However, it can be useful to understand what type of events trigger transitions between active, idle, and standby power modes Reference [14] as well as at what time peripherals are powered on.

While the CPU is executing code, the device is in active mode [14]. It consumes 2.9 mA at 3.3 V if no peripherals are powered [2]. When there is no hardware interrupt (HWI) or software interrupt (SWI) running and the operating system has no tasks ready to run, the power driver automatically transitions the device power mode from active mode into either idle or standby. If a peripheral is performing an operation in the background, the driver requests that the power driver does not transition into standby. The power driver instead transitions the device into an idle power state [14] and turns off the CPU power domain. In idle state, the device consumes 590 µA plus any additional current required by the peripheral running in the background [2]. The device returns to active mode when the peripheral’s interrupt wakes the CPU to execute the interrupt service routine (ISR).

In general, all of the peripherals that a driver depends on are powered by the driver when opening a driver instance. Some drivers, such as the SPI or UART, map a physical peripheral to each driver instance and assume that when a driver instance is opened, it has exclusive access to that hardware. Other drivers, such as the crypto drivers, share physical peripherals between multiple open instances and between different types of drivers. Mutual exclusion is handled internally in the driver implementations.

Opening a driver instance takes a small amount of time. The default recommendation is to open a driver instance, use it to perform an operation, and then close it again. This usage pattern minimizes the amount of time the peripheral remains powered. It may make more sense to keep the driver instance open if the application uses it multiple times between standby periods. The same is true if the application has stringent latency requirements for transitioning between power modes (for example, transitioning from idle or standby to active mode).