Peripheral State Persistence and Interrupt Management For Transiently Powered Systems

Transcription

1 Peripheral State Persistence and Interrupt Management For Transiently Powered Systems Gautier Berthou, Tristan Delizy, Kevin Marquet, Tanguy Risset, Guillaume Salagnac Citi Lab, INSA Lyon, France NVMW, San Diego, March 12 th 2018

2 G. Berthou 2/23 Context: Transiently Powered Systems Internet of Tiny Things Internet of Things networked embedded systems No battery harvest power smart cards RFID tags wearable sensors

3 Context: Program checkpointing Power failure detection Energy Harvester + buffer CPU Power in Supply voltage Vboot RAM NVM Program Checkpointing: Anticipate power failures Save program state to a non-volatile memory Restore state on next boot Idea: add OS code to hide checkpointing to the application Vtrigger Vdeath Off time Lifecycles Time G. Berthou 3/23

4 G. Berthou 4/23 Typical checkpoint structure Application state - Copy of variables - Copy of application stack - Copy of CPU registers Contains all relevant data to enable application persistence Stored in non-volatile memory

5 Checkpointing for Transiently Powered Systems Mementos [Ransford et al 13] DINO [Lucia & Ransford 15] HarvOS [Bhatti & Mottola 16] Quickrecall [Jayakumar et al 14] CPU RAM CPU NVRAM Flash NV CPU NVRAM CPU RAM NVRAM [Liu et al 15] [Balsamo et al 15, 16] G. Berthou [Ait Aoudia et al 14] 5/23

6 G. Berthou 6/23 Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives

7 The Peripheral State Volatility Problem App Drv HW Application code rf send void main(void){ sensor_init(); rf_init(myconfig); } for(;;){ v = sensor_read(); rf_send(v);... } Restoring memory content will not restore device state G. Berthou 7/23

8 G. Berthou 8/23 Our approach: distinct roles for OS and drivers Each driver provides: restore() function device context App OS Drv HW restore Operating System: checkpoints device contexts calls every restore() function checkpoints application state

9 G. Berthou 9/23 The Peripheral Access Atomicity Problem Application code void main(void){ sensor_init(); rf_init(myconfig); App rf send Drv HW } for(;;){ v = sensor_read(); rf_send(v);... } In most cases, resuming execution in the middle of a hardware access does not make sense

10 G. Berthou 10/23 Our approach: make driver calls atomic Encapsulate driver functions into OS wrappers. Each driver provides a save() function that copies device context into checkpoint image. On wrapper entry: save arguments + function called switch to volatile stack On wrapper exit: save device contexts clear arguments switch back to application stack App wrapper entry wrapper exit OS original driver function Drv + HW drv save() Interrupted driver calls are retried and not just resumed.

11 G. Berthou 11/23 Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives

12 G. Berthou 12/23 Interrupt-related problems Problems not specific to transiently-powered systems: Concurrency Race conditions Solution: critical sections with interrupts enabled. Specific to transiently-powered systems: Interrupt data volatility

13 G. Berthou 13/23 Interrupt data volatility Interrupt occurrence is volatile data. Peripheral data, e.g., radio packet content, are also volatile data. App Interrupt A Int. A handler Peripheral data is ready

14 G. Berthou 14/23 Our approach: extend solution to peripheral state volatility problem OS-managed top halves and user-managed bottom halves App OS Drv + HW Each driver provides an on_interrupt() routine. Each top half calls the on_interrupt() routine of relevant drivers. bottom half on interrupt extracts data drv save() save scheduler

15 G. Berthou 15/23 Checkpoint structure Application state - Copy of variables - Copy of application stack - Copy of CPU registers OS state - Running driver call if any - Address and arguments - Interrupt occurrence Drivers state - Driver A device context - Driver B device context -... OS and drivers states allow peripheral persistence

16 G. Berthou 16/23 Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives

17 G. Berthou 17/23 Sytare Evaluation Setup Application void main(void){ syt_sensor_init(); syt_rf_init(myconfig); MSP430FR5739: 16-bit CPU 24MHz, 1kB SRAM, 15kB FeRAM RF-chip: CC2500 } for(;;){ v = syt_sensor_read(); compute(); syt_rf_send(v);... }

18 G. Berthou 18/23 Evaluation methodology Experimental setup Varying parameter: lifecycle duration Ground-truth Same application without OS layer Stable supply without outage Supply voltage Vboot Vtrigger Vdeath Off time Lifecycles Time

19 G. Berthou 19/23 Evaluation methodology Performance metrics Duration of shortest usable lifecycle Temporal execution efficiency Efficiency(x) = T GT T (x) T GT x Lifecycle duration Application runtime under ground-truth conditions T (x) Application runtime with OS layer when the platform is ON

20 G. Berthou 20/23 Efficiency results Efficiency T GT T min = 3 ms ,000 Lifecycle duration (milliseconds)

21 G. Berthou 21/23 Results: Driver call temporal overhead Driver calls are encapsulated into wrappers Driver call Overhead (%) Led toggle 1263 ADC read 27 Radio sleep 137 Radio wake-up 8 Radio send 1

22 G. Berthou 22/23 Outline Introduction: Context and State of the Art Peripheral State Persistence Peripheral State: Volatility Problem Peripheral Access: Atomicity Problem Interrupt handling Experimental Results Conclusion and perspectives

23 G. Berthou 23/23 Conclusion and perspectives Peripheral State Persistence for Transiently Powered Systems Volatility: device contexts Atomicity: retry rather than resume Interrupts: save data as soon as possible Project sources: Perspectives Reduce overhead of driver calls Adapt peripheral checkpointing to existing OS (RIOT, Contiki) WCEC evaluation of peripheral accesses Energy-based decision making

24 G. Berthou 0/-1 Checkpoint structure - Completed Application state - Copy of variables - Copy of application stack - Copy of CPU registers OS state - Running driver call if any - Address and arguments - Interrupt occurrence Drivers state - Driver A device context - Driver B device context -... Information about interrupt occurrence are kept in the OS section of the checkpoint image. Data carried by interrupts are kept in the relevant device drivers. Ex: radio packet content is owned by the radio chipset driver. Current Last

25 G. Berthou 0/-1 Complex driver call Sequence diagram SRAM state NVRAM Checkpoint Next Image state App OS drv A drv B App Drivers user main() App 0 A 0 B 0 Modified drivers NVRAM Checkpoint Last Image state App Drivers Kernel App Drivers Kernel A 0 B 0 App 0 A 0 B 0 syt drva fn(x) drva fn(x) App 1 App 1 A 0 B 0 A 0 B 0 A 0 B 0 A 0 B 0 drva fn x App 0 A 0 B 0 App 0 A 0 B 0 drvb fn(y) App 1 A 1 B 0 A 0 B 0 drva fn x App 0 A 0 B 0 mark dirty() App 1 mark dirty() App 1 drvb save() A 1 B 1 A 2 B 1 { B } { B, A } A 0 B 0 drva fn x A 0 B 0 drva fn x App 0 A 0 B 0 App 0 A 0 B 0 drva save() App 1 App 2 A 2 B 1 A 2 B 1 A 2 B 1 A 2 B 1 App 0 A 0 B 0 App 0 A 0 B 0 Unmodified state Modified state

26 G. Berthou 0/-1 Top halves and bottom halves Interrupt handling is split into OS-managed top halves and user-managed bottom halves. Power loss is handled by top halves, making it possible to hide power loss from user. Design choices: two axes 1 Bottom half nestedness? No 2 Allowance of hardware operations being called from bottom halves? Yes

27 G. Berthou -1/-1 Data race conditions Application code static int x; bottom_half() { ++x; } main() { x = 0;... if(x == 4) {... } }

28 G. Berthou -1/-1 Data race conditions Problem Bottom halves may share data with user application: global variables. Solution User-defined critical sections that disable bottom halves but keep interrupts enabled. Bottom halves are delayed until the end of the critical section. Interrupts are enabled, which makes the sytem reactive upon power loss detection.

29 G. Berthou -1/-1 Peripheral access race conditions App OS Drv SPI syt spi config(a) spi config(a) Interrupt A Top half spi config(b) SPI has config A?

30 G. Berthou -1/-1 Peripheral access race conditions Problem Interrupts might occur during a hardware access initiated by user. Top half might use the same peripheral and put it in an inconsistent state with respect to the application. Solution Provide lock mechanism, accessible from the user, who indicates to the OS which peripherals are locked. When an interrupt occurs, if the top half tries to use a locked peripheral, both the top and bottom halves are discarded.

31 G. Berthou -1/-1 Peripheral access atomicity Problem Interrupts might occur during a hardware access initiated by user. Solution Rerun driver call call from the beginning when returning from interrupt. Makes the driver call management policy consistent with power loss detection occurring during driver call execution. Pessimistic approach that leads to time and energy overhead.

32 Operating System architecture - Completed App Drv op. App Ret Interrupt Empty queue and app running Restore Init Not first boot First boot Boot Interrupted during Drvcall Bot. half Drvcall Bottom half Interrupt Empty queue and syscall running Interrupt or bot. half completion Bot. half queued or top half completion Drv op. Ret Interrupt Bot. half Bot. half Drvcall Drvcall Top half completion Power loss detection Kernel Driver Kernel Interrupt top half Checkpoint Actual power loss + Hardware reboot User application G. Berthou -1/-1

33 G. Berthou -1/-1 System boot sequence Device context restoration 27µs App state restoration 45µs Peripheral state restoration 1.17ms Next checkpoint initialization 30µs power-up application execution Hardware boot 0.75 ms Port Clock ADC SPI Radio

34 G. Berthou -1/-1 ommunication peripheral is available. TPSST23ZL48 example block diagram architecture : ST23ZL48 microcontroller igure 1. RAM EEPROM User ROM ST ROM (Boot software) EDES Accelerator NESCRYPT ST ROM Firewall NESCRYPT RAM CRC Module Clock Generator Module CLK 3 x 8-bit timers Internal Bus Security Monitoring and Control RESET True Random Number Generator Vcc GND MPU 8/16-bit CPU Core IART 2 I/Os 16-bits CPU (27MHz) 8kB RAM 300kB ROM 48kB EEPROM Ai