DOCSLIB.ORG

Formal Fault Injection Vulnerability Detection in Binaries: a Software

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formal Fault Injection Vulnerability Detection in Binaries: a Software Formal fault injection vulnerability detection in binaries : a software process and hardware validation Nisrine Jafri To cite this version: Nisrine Jafri. Formal fault injection vulnerability detection in binaries : a software process and hard- ware validation. Cryptography and Security [cs.CR]. Université Rennes 1, 2019. English. NNT : 2019REN1S014. tel-02385208 HAL Id: tel-02385208 https://tel.archives-ouvertes.fr/tel-02385208 Submitted on 28 Nov 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. T HÈSE DE DOCTORAT DE L’UNIVERSITE DE RENNES 1 COMUE UNIVERSITE BRETAGNE LOIRE Ecole Doctorale N°601 Mathèmatique et Sciences et Technologies de l’Information et de la Communication Spécialité : Informatique Par « Nisrine JAFRI » « Formal Fault Injection Vulnerability Detection in Binaries » «A Software Process and Hardware Validation» Thèse présentée et soutenue à RENNES , le 25 mars 2019 Unité de recherche : Inria, TAMIS team Thèse N°: Rapporteurs avant soutenance : Marie-Laure POTET, Professeur des Universités, ENSIMAG Jean-Yves MARION, Professeur des Universités, Université de Lorraine Composition du jury : Président : Pierre-Alain FOUQUE, Professeur des Universités, Université Rennes 1 Examinateurs : Leijla BATINA, Professeur des Université s, Université Radboud de Nimegue Shivam BHASIN, Chercheur, Université technologique de Singapour Sylvain GUILLEY, Professeur des Universités, Télécom ParisTech Annelie HEUSER, Chercheur, CNRS Dir. de thèse : Jean-Louis LANET, Chercheur, Inria Co-dir. de thèse : Axel LEGAY , Professeur des Universités, Université catholique de Louvain Invité(s) iii “The summit of happiness is reached when a person is ready to be what he is.” Desiderius Erasmus إلى�من�بالحب�غمروني�وبجميل�السجايا�أدبوني �إلى�أ�ّمي�و�أبي� v UNIVERSITY RENNES 1 Abstract Inria Doctoral School MATHSTIC Doctor of Philosophy Formal Fault Injection Vulnerability Detection in Binaries - A Software Process and Hardware Validation by Nisrine JAFRI Fault injection is a well known method to test the robustness and security vulner- abilities of systems. Detecting fault injection vulnerabilities has been approached with a variety of different but limited methods. Software-based and hardware-based approaches have both been used to detect fault injection vulnerabilities. Software- based approaches can provide broad and rapid coverage, but may not correlate with genuine hardware vulnerabilities. Hardware-based approaches are indisputable in their results, but rely upon expensive expert knowledge, manual testing, and can not confirm what fault model represent the created effect. First, this thesis focuses on the software-based approach and proposes a general pro- cess that uses model checking to detect fault injection vulnerabilities in binaries. The efficacy and scalability of this process is demonstrated by detecting vulnerabilities in different cryptographic real-world implementations. Then, this thesis bridges software-based and hardware-based fault injection vulnera- bility detection by contrasting results of the two approaches. This demonstrates that: not all software-based vulnerabilities can be reproduced in hardware; prior conjec- tures on the fault model for electromagnetic pulse attacks may not be accurate; and that there is a relationship between software-based and hardware-based approaches. Further, combining both software-based and hardware-based approaches can yield a vastly more accurate and efficient approach to detect genuine fault injection vul- nerabilities. Keywords: Fault Injection, Vulnerability Detection, Model Checking, Formal Meth- ods vii Acknowledgements I would start by expressing my gratitude to my thesis directors Jean-Louis Lanet and Axel Legay. Thank you for giving me the opportunity to experience the PhD journey. Thanks for your directions through the path, your advices and comments. My sincere thanks to Marie-Laure Potet and Jean-Yves Marion for accepting to re- view my work. Marie-Laure Potet, thank you for your advices and goodwill. Jean- Yves Marion, thank you for your availability and pertinent remarque. Thanks for the jury members, Leijla Batina, Shivam Bhasin, Pierre-Alain Fouque, Sylvain Guilley for accepting to be part of my jury. Special thanks to my supervisor Thomas Given-Wilson. My research would have been impossible without your aid, support, and encouragement. Thanks for all the shared techniques and tips that I will carry on with me, and share as well. I owe a very important debt to Annelie Heuser, thanks for helping me finalise this manuscript, but also for all your support and encouragement, it was a real pleasure working with you. Thanks to Clementine Maurice my monitor, your advices, suggestion and encour- agement were a great help to me. I would also like to thank Ronan Lashermes and Sebanjila Kevin Bukasa from the LHS lab for their help in conducting the hardware experiments. Heartfelt thanks go to all the tamis team members. A special thank to Olivier Zen- dra the team leader for his support and help in order to defend my thesis. A unique thanks to Cecile Bouton. Thank you for your goodwill and support, you have been a second mother to me. thanks to the members who become true friends to me. Alex and Kevin we will remain the Trio of Porto. Tania, thanks for everything but especially for the free hugs. Cassius, thanks for your positive energy, and all the shared information about the music bands. Delphine, it was a pleasure to have you as an officemate. Thanks to all the team members with whom I shared a great mo- ment: Stefano, Ioana, Lamine, Céline, Yoann, Christophe, Laurent, Leo, Ludo, Jean, Hélène, Florian, Fabrizio ... I am profoundly grateful to all my friends for their emotional support through the way, thanks Meriem, Fati, Mouad, Routa, Rahaf, Farah. A special thanks to Pierre- Yves who become more than a friend. Thanks for your support, through the last miles of this journey you had the right words to boost my motivation. Thanks to all my Spanish, Sewing, Swimming, and Salsa teachers, spending time in your courses helped me having a balanced life. Thanks to my second family in Rennes, Gabrielle and Claire. You’ve been a true family to me, you embraced me with your love and care, and made me feel at home. And lastly, all the thank goes to my beloved family for their unlimited love and support. Thanks to my parents and brothers Youssef and Youness. My grandparents and to all members of JAFRI and Chouka families, for providing me with unfailing support and continuous encouragement throughout my years of study and through the process of researching and writing this thesis. This accomplishment would not have been possible without them. Thank you. Nisrine JAFRI ix Contents Abstract v Acknowledgements vii Résumé en français 1 Introduction and Background 5 1 Introduction 5 1.1 Context and Motivation ........................... 5 1.2 Motivating Example: Verify PIN Example ................. 7 1.3 Contributions ................................. 8 1.4 Publications .................................. 10 1.5 Organisation of the Thesis .......................... 12 2 Background 15 2.1 Fault Injection ................................. 15 2.1.1 Software-Based Fault Injection Approaches . 18 2.1.2 Hardware-Based Fault Injection Approaches . 20 2.1.3 Fault Model .............................. 22 2.2 Formal Verification .............................. 22 2.2.1 Model Checking ........................... 23 2.2.2 Properties ............................... 25 2.3 Working on Binaries ............................. 25 2.3.1 Binary Model Checking ....................... 26 2.3.2 Binary Translation .......................... 28 I An Automated Formal Process For Detecting Fault injection Vulner- abilities in Binaries 31 3 Overview of Part I 33 3.1 Introduction .................................. 33 3.2 State of the Art ................................. 34 3.3 Case Studies: Cryptographic Algorithms . 36 4 Process, Implementation and Methodology 41 4.1 Fault Injection Vulnerability Detection FIVD Process . 41 4.2 FIVD Process Implementation ........................ 44 4.3 FIVD Process Methodology ......................... 46 5 Experimental Results 49 5.1 Motivating example .............................. 49 5.2 Cryptographic Algorithm .......................... 54 x 6 Details on the Experimental Results and Implementation for the PRESENT Algorithm 59 7 Discusion and Limitations 67 7.1 Discusion .................................... 67 7.2 Limitations ................................... 69 II Bridging Software-Based and Hardware-Based Fault injection At- tacks 71 8 Overview of Part II 73 8.1 Introduction .................................. 73 8.2 State of the Art ................................. 75 8.3 Case Studies: Control flow Hijacking and Backdoor Attack . 76 9 Process, Implementation and Methodology 81 9.1 Software and Hardware based Process ................... 81 9.2 Software and Hardware based Implementation . 83 9.3 Software and Hardware based Methodology . 85 10 Experimental Results 89 10.1 Control Flow Hijacking ...........................
Load more

Recommended publications
  • Using Fault Injection to Increase Software Test Coverage 
    Using Fault Injection to Increase Software Test Coverage James M. Bieman Daniel Dreilinger Lijun Lin Computer Science Department Colorado State University Fort Collins, Colorado 80523 [email protected] To appear in Proc. International Symposium on Software Reliability (ISSRE'96) Abstract must be recompiled and then tested. This process can be too labor and time intensive for practical use in the general test- During testing, it is nearly impossible to run all statments ing of commercial software. or branches of a program. It is especially dif®cult to test Our hypothesis is that fault injection can be effective the code used to respond to exceptional conditions. This when it is directed towards solving speci®c testing prob- untested code, often the error recovery code, will tend to be lems. In particular, we use fault injection to force the exe- an error prone part of a system. We show that test cover- cution of dif®cult to reach program paths. To avoid the need age can be increased through an ªassertion violationº tech- for recompilation, we mutate program state rather than pro- nique for injecting software faults during execution. Using gram text. our prototype tool, Visual C-Patrol (VCP), we were able to To be practical, any fault injection mechanism must be substantially increase test branch coverage in four software inexpensive and be able to model a wide variety of fault systems studied. types. Much of the fault injection should be automated. Al- though a practical approach requires a limited fault model, Keywords: software testing, software test coverage, fault we want to simulate as many faults as possible.
    [Show full text]
  • Familias De Microcontroladores
    INTRODUCCION Un microcontrolador es un circuito integrado tiene en su interior todas las características de un computador, es decir, programa y circuitos periféricos para CPU, RAM, una memoria de entrada y salida. Muy regularmente los microcontroladores poseen además convertidores análogo - digital, temporizadores, contadores y un sistema para permitir la comunicación en serie y en paralelo. Se pueden crear muchas aplicaciones con los microcontroladores. Estas aplicaciones de los microcontroladores son ilimitadas, entre ellas podemos mencionar: sistemas de alarmas, iluminación, paneles publicitarios, etc. Controles automáticos para la Industria en general. Entre ellos control de motores DC/AC y motores de paso a paso, control de máquinas, control de temperatura, tiempo; adquisición de datos mediante sensores, etc. HISTORIA El primer microprocesador fue el Intel 4004 de 4 bits, lanzado en 1971, seguido por el Intel 8008 y otros más capaces. Sin embargo, ambos procesadores requieren circuitos adicionales para implementar un sistema de trabajo, elevando el costo del sistema total. Los ingenieros de Texas Instruments Gary Boone y Michael Cochran lograron crear el primer microcontrolador, TMS 1000, en 1971; fue comercializado en 1974. Combina memoria ROM, memoria RAM, microprocesador y reloj en un chip y estaba destinada a los sistemas embebidos.2 Debido en parte a la existencia del TMS 1000,3 Intel desarrolló un sistema de ordenador en un chip optimizado para aplicaciones de control, el Intel 8048, que comenzó a comercializarse en 1977.3 Combina memoria RAM y ROM en el mismo chip y puede encontrarse en más de mil millones de teclados de compatible IBM PC, y otras numerosas aplicaciones. El en ese momento presidente de Intel, Luke J.
    [Show full text]
  • Renesas MCU M16C Family (R32C/M32C/M16C/R8C)
    2008.01 Renesas MCU M16C Family (R32C/M32C/M16C/R8C) www.renesas.com World’s No. 1* Flash MCUs !! index Roadmap Total shipments of Rewriting possible during operation, and CPU Architecture World’s No. 1 1,000,000,000 units!! World’s No. 1 program/erase cycles increased to 100,000! E2dataFlash substantially improves the functionality and performance of data Flash MCUs Thanks to strong demand, total flash MCU Flash MCUs flash, allowing data to be rewritten independently while the MCU is operating. Concepts Proof No. 1 shipments reached the 1 billion mark in March 2007. Proof No. 4 Guaranteed program/erase cycles have been increased to 100,000, and data Renesas flash MCUs are used in a wide range of save times are two orders of magnitude faster than external E2PROM. consumer, industrial and automotive applications. (E2dataFlash: E2PROM emulation data flash memory) Product Lineup Development Tools No. 1 lineup of flash MCUs with 40µsec./byte high-speed flash World’s No. 1 over 300 products in 30 series!! World’s No. 1 programming!! Development Flash MCUs Flash MCUs Tools from Divided into high-end, middle, and low-end classes, Flash MCU technology supports high-speed Renesas Partners Proof No. 2 the flash MCU lineup is built on the most advanced Proof No. 5 programming at a rate of 512KB every 20 seconds technology. Flexible support is provided for (total time required for reprogramming, including Middleware/ increasingly large and complex software. erasing and programming). Demo Sets Functions/ Application Fields Memory Capacity High-speed flash memory supporting Comprehensive support and World’s No.
    [Show full text]
  • Improving Software Fault Injection
    Improving Software Fault Injection Ph.D. Thesis Erik van der Kouwe Vrije Universiteit Amsterdam, 2016 This work was funded in part by European Research Council under ERC Advanced Grant 227874. Copyright © 2016 by Erik van der Kouwe. ISBN XXX-XX-XXXX-XXX-X Printed by XXX. VRIJE UNIVERSITEIT IMPROVING SOFTWARE FAULT INJECTION ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof. dr. Vinod Subramaniam, in het openbaar te verdedigen ten overstaan van de promotiecommissie van de Faculteit der Exacte Wetenschappen op X XXX 2016 om X.XX uur in de aula van de universiteit, De Boelelaan 1105 door ERIK VAN DER KOUWE geboren te Leidschendam, Nederland promotor: prof.dr. A.S. Tanenbaum “TODO add quote.” TODO add quote source. Contents Contents vii List of Figures xi List of Tables xiii Publications xv 1 Introduction 1 2 Finding fault with fault injection An Empirical Exploration of Distortion in Fault Injection Experiments 7 2.1 Introduction . 7 2.2 Related work . 12 2.3 Fidelity . 14 2.4 Approach . 16 2.5 Programs and workloads . 17 2.6 Results . 19 2.6.1 Coverage . 19 2.6.2 Execution count . 26 2.6.3 Relationship between execution count and coverage . 30 2.6.4 Relationship between faults and execution . 31 2.7 Threats to validity . 33 2.8 Recommendations . 35 2.9 Conclusion . 36 vii viii 3 On the Soundness of Silence Investigating Silent Failures Using Fault Injection Experiments 39 3.1 Introduction . 39 3.2 Approach . 41 3.2.1 Fault injection .
    [Show full text]
  • Embedded Operating Systems
    7 Embedded Operating Systems Claudio Scordino1, Errico Guidieri1, Bruno Morelli1, Andrea Marongiu2,3, Giuseppe Tagliavini3 and Paolo Gai1 1Evidence SRL, Italy 2Swiss Federal Institute of Technology in Zurich (ETHZ), Switzerland 3University of Bologna, Italy In this chapter, we will provide a description of existing open-source operating systems (OSs) which have been analyzed with the objective of providing a porting for the reference architecture described in Chapter 2. Among the various possibilities, the ERIKA Enterprise RTOS (Real-Time Operating System) and Linux with preemption patches have been selected. A description of the porting effort on the reference architecture has also been provided. 7.1 Introduction In the past, OSs for high-performance computing (HPC) were based on custom-tailored solutions to fully exploit all performance opportunities of supercomputers. Nowadays, instead, HPC systems are being moved away from in-house OSs to more generic OS solutions like Linux. Such a trend can be observed in the TOP500 list [1] that includes the 500 most powerful supercomputers in the world, in which Linux dominates the competition. In fact, in around 20 years, Linux has been capable of conquering all the TOP500 list from scratch (for the first time in November 2017). Each manufacturer, however, still implements specific changes to the Linux OS to better exploit specific computer hardware features. This is especially true in the case of computing nodes in which lightweight kernels are used to speed up the computation. 173 174 Embedded Operating Systems Figure 7.1 Number of Linux-based supercomputers in the TOP500 list. Linux is a full-featured OS, originally designed to be used in server or desktop environments.
    [Show full text]
  • Evaluating Software Systems Via Runtime Fault-Injection and Reliability, Availability and Serviceability (RAS) Metrics and Models
    The 7U Evaluation Method: Evaluating Software Systems via Runtime Fault-Injection and Reliability, Availability and Serviceability (RAS) Metrics and Models Rean Griffith Submitted in partial fulfillment of the Requirements for the degree of Doctor of Philosophy in the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2008 c 2008 Rean Griffith All Rights Reserved Abstract The 7U Evaluation Method: Evaluating Software Systems via Runtime Fault-Injection and Reliability, Availability and Serviceability (RAS) Metrics and Models Rean Griffith Renewed interest in developing computing systems that meet additional non-functional requirements such as reliability, high availability and ease-of-management/self-management (serviceability) has fueled research into developing systems that exhibit enhanced reliability, availability and serviceability (RAS) capabilities. This research focus on enhancing the RAS capabilities of computing systems impacts not only the legacy/existing systems we have today, but also has implications for the design and development of next generation (self- managing/self-*) systems, which are expected to meet these non-functional requirements with minimal human intervention. To reason about the RAS capabilities of the systems of today or the self-* systems of tomorrow, there are three evaluation-related challenges to address. First, developing (or identifying) practical fault-injection tools that can be used to study the failure behavior of computing systems and exercise any (remediation) mechanisms the system has available for mitigating or resolving problems. Second, identifying techniques that can be used to quantify RAS deficiencies in computing systems and reason about the efficacy of individual or combined RAS-enhancing mechanisms (at design-time or after system deployment). Third, developing an evaluation methodology that can be used to objectively compare systems based on the (expected or actual) benefits of RAS-enhancing mechanisms.
    [Show full text]
  • Parameter Files for Flash Memory Programmer PG-FP5 Released
    Tool News RENESAS TOOL NEWS on March 29, 2012: 120329/tn7 Parameter Files for Flash Memory Programmer PG-FP5 Released We have revised and newly published parameter files for the flash memory programmer PG- FP5. These files save information about the MCUs they support in the text format, and the PG-FP5 uses this information to program the flash memories of those MCUs. For an overview of the PG-FP5, go to: https://www.renesas.com/pg_fp5 The above URL is one of our global sites. 1. Released Parameter Files and Their Versions 1.1 Newly Published Parameter Files (1) For RL78 family - PR5-R5F10R V1.00 (for RL78/L12 group) (2) For R8C family - PR5-R8C5X V1.00 (for R8C/5x series) 1.2 Revised Parameter Files (1) For RL78 family - PR5-R5F104 V1.03 (for RL78/G14 group) (2) For 78K family - PR5-78F1845 V1.02 (for 78K0R/Fx3) NOTE: Only the release note included in PR5-78F1845 has been updated. The parameter file itself is same as one in V1.01. - PR5-78F8058 V1.02 (for UPD78F8058) (3) For R8C family - PR5-R8C3X V1.01 (for R8C/3x series) - PR5-R8CLX V1.01 (for R8C/Lx series) (4) For V850 family - PR5-70F3786 V1.01 (for V850ES/Jx3-E) - PR5-70F3738 V1.03 (for V850ES/Jx3-L) - PR5-70F4012 V1.03 (for V850E2/Fx4) 2. Device Support Updated In the UPD70F3735, UPD70F3736, UPD70F3737, and UPD70F3738 MCUs, which belong to the V850ES/Jx3-L, an improvement has already been made so that their flash memories can be programmed when used in a main-clock frequency range (an fx range) of 5 to 10 MHz.
    [Show full text]
  • Datasheet CAN Driver Source Code
    Source Code CAN Driver Source Code - CANpie FD CAN driver for embedded applications The driver CANpie FD (Controller Area Network Program- ming Interface Environment) provides a standarized API for software engineering of CAN-based applications. The driver forms the basis for higher-layer protocols (CANopen / DeviceNet / J1939) and is available for a wide range of microcontroller platforms. Scalability and modu- lar design of the CANpie drivers facilitate implementation into individual target systems. Features • Modular design, scalable, easy to implement • Optimized for low resources (ROM / RAM) User Functions • Wide range of supported CAN controllers • Support of standard and extended frames (11-bit / 29-bit identifier) Core Functions Receive Transmit • Data flow by polling or interrupt driven FIFO FIFO • Supports virtual mailboxes Mailbox Access Filter Receive Transmit IRQ CAN hardware MicroControl GmbH & Co. KG · Junkersring 23 · 53844 Troisdorf · Germany · Fon +49 (0) 2241 256 59 - 0 · Fax +49 (0) 2241 256 59 - 11 · [email protected] I/O Module Steuerungen Protokollstacks Dienstleistungen www.microcontrol.net Technical Data CAN driver source code - CANpie FD Identifier • Standard Frame (11-bit) • Extended Frame (29-bit) Formats • Data Frame • Remote Frame • Error Frame (Receive) Monitoring of fault conditions • ACK (depending on controller) • Bit Error • Format Error • CRC Error • Stuff Error Dataflow • Interrupt • Polling Special Features • Mailbox access • Software Filter Order Number Description / CAN Controller 50.10.079
    [Show full text]
  • Experimental Assessment of Cloud Software Dependability Using Fault Injection
    Experimental Assessment of Cloud Software Dependability Using Fault Injection Lena Herscheid(), Daniel Richter, and Andreas Polze Hasso Plattner Institute, Potsdom, Germany {lena.herscheid,daniel.richter,andreas.polze}@hpi.de Abstract. In modern cloud software systems, the complexity arising from fea- ture interaction, geographical distribution, security and configurability require- ments increases the likelihood of faults. Additional influencing factors are the impact of different execution environments as well as human operation or con- figuration errors. Assuming that any non-trivial cloud software system contains faults, robustness testing is needed to ensure that such faults are discovered as early as possible, and that the overall service is resilient and fault tolerant. To this end, fault injection is a means for disrupting the software in ways that un- cover bugs and test the fault tolerance mechanisms. In this paper, we discuss how to experimentally assess software dependability in two steps. First, a model of the software is constructed from different runtime observations and configu- ration information. Second, this model is used to orchestrate fault injection ex- periments with the running software system in order to quantify dependability attributes such as service availability. We propose the architecture of a fault in- jection service within the OpenStack project. Keywords: Fault injection · Dependability · Distributed systems · Cloud sys- tems · Availability 1 Introduction Fault tolerance is an essential dependability requirement especially in distributed and cloud software systems, where components can fail in arbitrary ways, but a high availability or reliability of the service is nevertheless required. To evaluate the dependability of complex software systems, a sufficiently realistic dependability model of the system needs to be built.
    [Show full text]
  • User Manual for Emload , Version 3.14
    emLoad Software Version 3.14p Manual revision 0 A product of SEGGER Microcontroller GmbH 2/128 User manual for emLoad , version 3.14 Disclaimer Specifications written in this manual are believed to be accurate, but are not guaranteed to be entirely free of error. Specifications in this manual may be changed for functional or performance improvements without notice. Please make sure your manual is the latest edition. While the information herein is as- sumed to be accurate, SEGGER Microcontroller GmbH (the manufacturer) as- sumes no responsibility for any errors or omissions and makes and you receive no warranties. The manufacturer specifically disclaims any implied warranty of fitness for a particular purpose. Copyright notice The latest version of this manual is available as PDF file in the download area of our website at www.segger.com. You are welcome to copy and distribute the file as well as the printed version. You may not extract portions of this manual or modify the PDF file in any way without the prior written permission of the manufacturer. The software described in this document is furnished under a li- cense and may only be used or copied in accordance with the terms of such a license. 2020 SEGGER Microcontroller GmbH, Monheim am Rhein / Germany Trademarks Names mentioned in this manual may be trademarks of their respective com- panies. Brand and product names are trademarks or registered trademarks of their re- spective holders. 2020 SEGGER Microcontroller GmbH User manual for emLoad , version 3.14 3/128 Contact / registration Please register the software via email. This way we can make sure you will re- ceive updates or notifications of updates as soon as they become available.
    [Show full text]
  • Renesas General-Purpose Microcontrollers/Microprocessors Lineup Catalog
    Renesas General-Purpose Microcontrollers/Microprocessors Lineup Catalog Notes: Renesas General-Purpose Microcontrollers/Microprocessors 1. Descriptions of circuits, software and other related information in this document are provided only to illustrate the operation of semiconductor products and application examples. You are fully responsible for the incorporation of these circuits, software, and information in the design of your equipment. Renesas Electronics assumes no responsibility for any losses incurred by you or third parties arising from the use of these circuits, software, or information. 2. Renesas Electronics has used reasonable care in preparing the information included in this document, but Renesas Electronics does not warrant that such information is error free. Renesas Electronics assumes no liability whatsoever for any damages incurred by you resulting from errors in or omissions from the information included herein. 3. Renesas Electronics does not assume any liability for infringement of patents, copyrights, or other intellectual property rights of third parties by or arising from the use of Renesas Electronics products or technical information described in this document. No license, express, implied or otherwise, is granted hereby under any patents, copyrights or other intellectual property rights of Renesas Electronics or Lineup Catalog others. 4. You should not alter, modify, copy, or otherwise misappropriate any Renesas Electronics product, whether in whole or in part. Renesas Electronics assumes no responsibility for any losses incurred by you or third parties arising from such alteration, modification, copy or otherwise misappropriation of Renesas Electronics product. 5. Renesas Electronics products are classified according to the following two quality grades: "Standard" and "High Quality". The recommended applications for each Renesas Electronics product depends on the product's quality grade, as indicated below.
    [Show full text]
  • RL78/G14 RESH-OS-MC-20001 Rev.1.00 Power Tool 120 Deg
    APPLICATION NOTE RL78/G14 RESH-OS-MC-20001 Rev.1.00 Power Tool 120 deg. Reference Development Nov 03, 2011 Introduction This document will provide an overview of power tool 120 degree reference development. This solution is based on Renesas Electronics' next-generation MCU (RL78 family), which combines advanced features from both the 78K and R8C families. Same as mainstream power tool products in market, BLDC control is used in this solution. Target Device RL78/G14 Group Contents 1. Overview ........................................................................................................................................... 2 2. System Diagram................................................................................................................................ 3 3. Configuration of R5F104BE .............................................................................................................. 4 4. Control theory.................................................................................................................................... 9 5. Hardware structure.......................................................................................................................... 13 6. Hardware and test data................................................................................................................... 19 7. Software flowchart........................................................................................................................... 22 APPENDIX .............................................................................................................................................
    [Show full text]