Peripheral State Persistence for Transiently Powered Systems...Peripheral State Persistence for Transiently Powered Systems Gautier Berthou, Tristan Delizy, Kevin Marquet, Tanguy Risset,

Peripheral State Persistencefor

Transiently Powered Systems

Gautier Berthou, Tristan Delizy, Kevin Marquet,Tanguy Risset, Guillaume Salagnac

Citi Lab, INSA Lyon, France

IoENT Workshop, june 7th 2017

Context: Transiently Powered Systems

Internet of Tiny Things• Internet of Things I networked embedded systems• no battery I must harvest power from the environment

smart cards RFID tags wearable sensors

I wearable computing, home automation, environmentmonitoring, parking assistance, supply chain control...

T. Delizy 2/21

Transient power = frequent power failures

Energysource

HarvesterEnergybuffer

Micro-controller

Radio

PowerManager Sensors

Energy

Time

Vboot

Vdeath

Off time Lifecycles

T. Delizy 3/21

SW baseline: bare-metal application programming

Program=app+libs+drivers

ISR deviceA_interrupt(){ ... }ISR deviceB_interrupt(){ ... }

void main(void){hardware_init();__enable_interrupts();hardware_access_1();compute_step_1();hardware_access_2();compute_step_2();...

}

Application must run to completionwithin one “lifecycle”

Software architecture• no OS support• main() + interrupt routines +

hardware accesses

T. Delizy 4/21

Problem statement

Industrial Approach:• Application software must run to completion in one lifecycle• SW and HW are codesigned : one platform per application

How to run arbitrary code despite frequent, unexpected reboots?

Academic approach:• Spread execution across multiple lifecycles

T. Delizy 5/21

State of the art: program checkpointing

Power in

EnergyHarvester+ buffer CPU

RAM

NVM

Power failures detectionProgram Checkpointing:• Anticipate power failures• Save program state to a

non-volatile memory• Restore state on next boot

I Idea: add “OS” code to hidecheckpointing to the application

Energy

Time

Vboot

Vdeath

Off time Lifecycles

Vsave

T. Delizy 6/21

Checkpointing for Transiently Powered Systems

CPURAM

NORFlash

CPURAM

FeRAM

[Ransford et al ’13]

[Ait Aoudia et al ’14] (previous work)

CPU

CPURAM

[Jayakumar et al ’14]

[Bhatti & Mottola ’16]

FeRAM

[Lucia & Ransford ’15]

NANDFlash

FC

[Balsamo et al ’15, ’16 ]

T. Delizy 7/21

Outline

Introduction: Context and State of the Art

Peripheral State PersistencePeripheral State: Volatility ProblemPeripheral Access: Atomicity Problem

Experimental Results

Conclusion and Perspectives

T. Delizy 8/21

This paper: Making peripherals persistent, too

Power in

EnergyHarvester+ buffer CPU

RAM

NVM

COM

RF Sensors

Power failures detection

Sensor

Non trivial initialization• timing, polling, ordering constraints

Non trivial access• not mapped in memory

Most peripherals don’tsupport "resuming"

Program checkpointing is not enough

T. Delizy 9/21

The Peripheral State Volatility Problem

Application code

void main(void){sensor_init();rf_init(myconfig);

for(;;){v = sensor_read();rf_send(v);...

}}

App Drv HW

rf send

Restoring memory content will not restore device stateT. Delizy 10/21

Our approach: distinct roles for OS and drivers

Each driver:

• Adds a restore() functioninit() + transitions to saved state

• Put its variables into a device contextDescription of a “restore()-able” state

Operating System:

• Persists device context• Calls every restore() functions• Persists application state

OS Drv HWApp

restoredevice

contexts

∀ drv

restoreapp state

boot

restore

T. Delizy 11/21

The Peripheral Access Atomicity Problem

Application code

void main(void){sensor_init();rf_init(myconfig);

for(;;){v = sensor_read();rf_send(v);...

}}

Drv HWApp

rf send

In most cases, resuming execution in the middle of a hardwareaccess does not make sense

T. Delizy 12/21

Our approach: make driver calls atomic

encapsulate driver functions into OSwrappers.

On wrapper entry:• save arguments + function called• switch to volatile stack

On wrapper exit:• save device contexts• clear arguments• switch back to main stack

OSApp

wrapperentry

Drv + HW

wrapperexit

Interrupted driver calls are retried and not just resumed.

T. Delizy 13/21

Our approach: make driver calls atomic

encapsulate driver functions into OSwrappers.

On wrapper entry:• save arguments + function called• switch to volatile stack

On wrapper exit:• save device contexts• clear arguments• switch back to main stack

OSApp

saveargs + id

Drv + HW

save appstate

Power lossdetected

Interrupted driver calls are retried and not just resumed.

T. Delizy 13/21

Outline

Introduction: Context and State of the Art

Peripheral State PersistencePeripheral State: Volatility ProblemPeripheral Access: Atomicity Problem

Experimental Results

Conclusion and Perspectives

T. Delizy 14/21

Sytare Evaluation Setup

Energysource

HarvesterEnergybuffer

Micro-controller

Radio

PowerManager Sensors

• µcontroller: 16-bit CPU 24MHz, 1kB SRAM, 15kB FeRAM• RF transiever: 2.4 GHz transciever, 64B packets

T. Delizy 15/21

Sense and send example application

Original Application

void main(void){sensor_init();rf_init(myconfig);

for(;;){v = sensor_read();compute();rf_send(v);...

}}

Adapted Application

void main(void){syt_sensor_init();syt_rf_init(myconfig);

for(;;){v = syt_sensor_read();compute();syt_rf_send(v);...

}}

T. Delizy 16/21

Evaluation methodology

Vchkpt

Vdeath

t

V Lifecycle

Off time

State restoration

Checkpoint

Experimental setup• Lifecycle: ON for a duration T, then OFF (and then repeat)• Measure efficiency for various values of T

Performance metrics• Duration of shortest usable lifecycle• Execution temporal efficiency w.r.t. bare-metal baseline

T. Delizy 17/21

Results for Sense and Send scenario

0.7

0.8

0.9

1

Twired. . . Tmin

Effi

cien

cy

0 100 200 300 400 5000

Twired. . . Tmin

Lifecycle duration (milliseconds)

Figure: WSN

T. Delizy 18/21

Results: Driver calls overhead

led toggle

ADC read

radio sleep

radio wake up

radio send

overheadx 14.25

x 1.27

x 2.37

x 1.08

x 1.01

3.4µs 1.6µs 17.8µs

2.4µs 75.2µs 17.6µs

2.4µs

2.4µs

2.4µs

23µs 29.2µs

428µs 31.4µs

3.4ms 20.6µs

wrapper entry wrapper exitdriver function

T. Delizy 19/21

Outline

Introduction: Context and State of the Art

Peripheral State PersistencePeripheral State: Volatility ProblemPeripheral Access: Atomicity Problem

Experimental Results

Conclusion and Perspectives

T. Delizy 20/21

Conclusion and Perspectives

Peripheral State Persistence for Transiently Powered Systems• Volatility: device contexts + restore() methods• Atomicity: retry VS resume

Project sources available at: https://gitlab.inria.fr/citi-lab/sytare

Perspectives: Look at programming abstractions for transient power• Expose interrupts to application code• Add delay-tolerance to driver calls• Energy based decision making• Design networking stacks and protocols• Reduce overhead on driver calls

T. Delizy 21/21

System boot sequence

Port Clock ADC SPI Radio

Hardware boot0.75 ms

App staterestoration 45µs

Device contextrestoration 27µs

Peripheral staterestoration 1.17ms

Next checkpointinitialization 30µs

power-up application execution

T. Delizy 21/21

TPS example architecture : ST23ZL48 microcontroller

Description ST23ZL48

2/4 Doc ID 15910 Rev 1

1 Description

The ST23ZL48 product is a serial access microcontroller specially designed for secure smartcard applications.

It is based on an enhanced STMicroelectronics 8/16-bit CPU core offering 16 Mbytes of linear addressing space. It is manufactured using an advanced highly reliable ST CMOS EEPROM technology.

Moreover, an ISO 7816-3 EMV-compliant asynchronous receiver transmitter (IART) communication peripheral is available.

Figure 1. ST23ZL48 block diagram

Ai12565

Internal Bus

2 I/Os

IART

GND

8/16-bitCPUCore

3 x8-bit

timers

CRCModule

CLK

ClockGene-rator

Module

Vcc

True RandomNumberGene-rator

RAM ST ROM(Boot software)

SecurityMonitor-ing andControl

RESET

EEPROM EDESAccelerator

UserROM

ST ROM Firewall

NESCRYPT

NESCRYPT RAM

MPU

http://www.st.com/en/secure-mcus/st23zl48.html

T. Delizy 21/21

• 16-bits CPU(27MHz)

• 8kB RAM• 300kB ROM• 48kB EEPROM