A Novel Synthetic Smoothened Antagonist Transiently Inhibits ...
Peripheral State Persistence for Transiently Powered Systems...Peripheral State Persistence for...
Transcript of Peripheral State Persistence for Transiently Powered Systems...Peripheral State Persistence for...
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