RL78 Code & Dataflash

Introduction Purpose Objective Content Learning Time This course provides an introduction to the RL78 flash features and architecture. These include the security features, code and data flash organization as well as self- and external programming and the related libraries. Objective Learn about the RL78 flash capabilities. Understand self and external programming methods Understand different libraries and their usage. Content 32 pages (including this page) x questions Learning Time 40 minutes The purpose of this course is to provide an introduction to the RL78's flash features and archectecture including security features, code and data flash organization as well as self and external programming and the related libraries.  

RL78 Flash Hardware

Technology overview MF3 - Technology Single voltage self-programming Supply voltage: 1.6V ~ 5.5V Prog. Voltage: 1.8V ~ 5.5V 0.13µm process density TA, prog: -40°C ~ +125°C TA, read: -40°C ~ +150°C Max. 32MHz Operation speed Block size 1K blocks Write unit 4 byte (for the Code Flash) 1 byte (for the Data Flash) Renesas' Flash technology is referred to as MF3 and is based on a 0.13 micrometer process density. It’s a single voltage self-programming technology which supports a supply voltage of 1.6 to 5.5 volts, with the programming voltage limited to 1.8 to 5.5 volts. The ambient temperature for programming is -40 to 125 degrees C, whereas the ambient temperature for reading FLASH goes up to 150 degrees. Maximum operation speed of the FLASH technology is 32 MHz, which is the same as the maximum speed of the micro. Therefore no wait cycles are needed and instructions can be fetched directly from FLASH in a single cycle. The complete FLASH in devices is segmented into blocks of 1K, which is also the smallest erase unit. In addition, the smallest write unit is 4 bytes for the code flash; which is related to hidden ECC which is used on the FLASH, where each 4 byte or 32bit word is protected with an additional 6bit ECC. And for the data flash there is a 1 byte write minimum unit, with each byte of the data flash secured with an additional 4 bit ECC.  

Hardware architecture Code flash 1K blocks 4 byte write unit two boot clusters Access via External programmer Flash Selfprogramming library (FSL) Data flash Independent second flash macro for data storage 1 byte write unit Access via: Simple access (FDL) library EEPROM emulation (EEL) library 0xF1FFF RL78 Data flash Note1 0xF1000 Code flash 0xyyyyy Firm- ware Now to the hardware architecture of the RL78 products; there are two different FLASH memory types inside, the first one is the code flash which is typically used to store the user's application.   The entire code flash is segmented into 1k blocks, with the smallest write unit in code flash being 4byte - as we said before - because of the hidden ECC. A special feature of the code flash is that it has two different boot clusters, the use of which will be covered later. Access to code flash can be done using an external programmer for mass production, end-of-line production or even for factory programming. Alternatively you can use the self-programming flash functionality in your application, using the supplied “Flash Self-programming Library” or FSL.  The second FLASH is the Data Flash; it's a completely independent flash memory block which is able to operate in the background to Code Flash operation. It's also segmented into 1K blocks, however the write unit is smaller - to support EEPROM emulation for this area. It's not possible to execute code from the Data Flash, since it's only for data storage. Access to Data Flash can also be done with an external programmer or by a simple library called FDL or a more complex library called EEL, which is the “EEPROM Emulation Library”. All these libraries FSL, FDL and EEL are available free of charge from Renesas Electronics. In addition to the Code Flash and Data Flash areas, internal firmware is resident in the device to program both types of FLASH, either from an external programmer or through the libraries. This firmware handles all the communication with the external programmer. 0x00000 Programming Interface Note1: available as an option

Code flash offer two boot blocks each 4k Boot Swap Code flash offer two boot blocks each 4k Swap by self programming command Allow secure boot loader update Old boot loader must not be erased before new completely written Allow simple boot loader design Temporary swap activate application until next reset 0xF1FFF Data flash Note1 0xF1000 0xyyyyy 0x02000 Boot cluster1 code flash Now we'll look at the Boot Swap feature of the RL products' Code Flash. Boot swap is possible because the Code Flash of the RL78 products is equipped with two different boot clusters - as we mention before - boot cluster zero and boot cluster one, with each of these boot clusters having a size of 4K.   The boot cluster allows secure boot-loader updating. If for example you want to update the complete boot area including the reset vector and all the interrupt vectors, you can write this new boot cluster into area one. When you know this has completed without any problems, then the boot clusters can be swapped. This ensures you always have a secure device with a valid reset vector available. The second feature supported by this boot cluster design, with two different boot clusters, is to allow simple boot loader design. For example your application can always start up with the boot loader in boot cluster zero and the application can have its own boot cluster, which is in this case would be boot cluster one. If the boot loader located in boot cluster zero confirms that the application is valid (via a checksum or CRC check) it can do a temporary boot swap to make boot cluster one active and then the whole application will run with boot cluster one. After reset the device starts again from boot cluster zero with the standard boot loader inside. 0x01000 Boot cluster 0 0x00000

high Security level low Security Features high Block erase protection flag Single blocks cannot be erased anymore Write protection flag Disables the external write command All flags set No on-board programming possible anymore Only Self-programming possible Flags can be set By external programmer (set security) selfprogramming Protection Flags are stored in the extra area Not part of the normal CPU address space Security level low Now we'll cover the security features used to protect the FLASH against unauthorized readout. For security reasons the FLASH firmware has no read instruction, so even an external programmer is not able to read out the device contents. However another way to read out the contents could be by putting spyware into the code.   To overcome this, two protection flags are implemented, the first of which is the Write Protection Flag. This flag disables the internal write command, so even unused memory inside the device cannot be overwritten by spy software. The second flag is the Block Erase Protection flag. With this flag set it is impossible to erase single blocks of the FLASH. That means you cannot erase two or three blocks to insert spy software. If both of these flags are set no onboard programming possible at all, and only self-programming is possible in this case. In general self-programming is not affected by these protection flags as they are only valid for access using an external programmer. Self-programming must be secured by the developer, by for example using special passwords. The security flags can be set using an external programmer's Set Security function or by self- programming. Note that self-programming can only set the flags; reset has to be done by erasing using an external programmer. The protection flags are not part of the standard code area, so there is no risk that these flags could be destroyed by the application software. The protection flags are stored in an “Extra area” which is not part of the normal address range and can only be accessed by the internal flash programming firmware.

Security Features (cont.) Boot cluster protection flag Boot cluster 0 cannot be erased or written anymore Flash shield window function support Self-programming mode only The RL78 FLASH also implements a boot cluster protection flag. If this flag is set, boot cluster zero can no longer be erased or re-written; and this flag is not only valid for an external programmer, but also for self-programming, thus making it impossible to destroy the boot cluster in the software - even by accident.   Another security feature is the FLASH Shield Window function. Using this it is possible to open or close parts of the code flash area against re-writing. During normal operation the entire code flash area can be protected by the Flash Shield Window. So even if self-programming is attempted - to erase some of the blocks - it will return a protection error because the Flash Shield Window is closed. You can open a special window range for self-programming when you only want to update the application or parts of the application, and re-write this area of the code flash.

Error Correction Code (ECC) 32 1 During the Flash Write the data are encrypted in the ECC Encryption Logic and the resulting bits are stored in the ECC part of the flash Flash Write ECC Encryption Logic ECC bits Data bits 32 1 6 1 Flash Read ECC Decryption Logic During Flash Read these bits are used by the ECC Decryption Logic to correct single bit failures on the fly Now for an explanation of the ECC or Error Correction Code. A 6 bit ECC is automatically calculated in the background during a flash write and stored in the FLASH; i.e. in the actual FLASH - instead of a 32 bit word - 32 bits plus 6 extra bits are stored. Each time the FLASH is read, the ECC description logic compares the ECC bits with the data bits and can repair a one bit failure in the 32 bit word. The ECC works in the background so you don't see any of the error checking operation. This feature was implemented to further reduce the already excellent overall device failure rate, and improve life-time and reliability. Such ECC feature is often strongly requested to secure the whole FLASH contents.   Note that no bit failures are ever accepted during programming; so that when the device is programmed you can be sure that the ECC is not activated and all the values are written correctly; additionally all tests at the end of mass production are also performed without ECC. 32 1 Flash cells with maximum 1 bit failure over lifetime Original data

RL78 On board programming Now we come to on-board programming for RL78 devices. On-board programming means programming the Code or Data Flash contents using an external programmer.

Selfmade programmers can be approved by a flashprogrammer audit Programming methodes Serial Programming E1 on chip debug emulator /programmer PG-FP5 mass production programmer third party tool Ertec, Data IO, … Flash Programming app note Selfmade programmers can be approved by a flashprogrammer audit Lets have a look at the different programming methods. Serial programming performs on-board programming using external tools. Renesas' E1 on-chip-debug emulator/programmer can be used to program RL78 products. This small box supports the RL products' programming interface; however it requires a PC connection to do the programming.   A second option is the PG-FP5, which can also be used for mass production, due to its internal memory and serial remote control interface. For example it can be added directly to a production test fixture, to program the RL78 devices at the end of the line. Of course it's also possible to use 3rd party tools from companies who support our devices like Ertec, Data IO and BP systems. And finally a FLASH programming Application Note is available for these devices, which allows you, or other programmer manufacturers to implement the RL protocol into their programming equipment. Alternatively you can also use this application note if you want to directly build programming functionality into your in-circuit test machine. Custom programmers can be certified by a FLASH programmer audit, which gives programmer- manufacturers confidence that their programmed algorithm conforms to the RL78 device algorithm.

Full support of programming on Flash Programmer Full support of programming on dedicated programming adapter or directly in the user system E1 USB Flash-Programming Adapter PG-FP5-EE PG-FP5-EE PG-FP5-EE USB On this slide are the different device programming options. Only the E1 and the PG-FP 5 Renesas tools are shown here, but other programmers can be used instead. It's also possible to program the device in a dedicated programming adapter. These boards are pre-made and can be purchased directly from Renesas Electronics. It's a small board with a zero insertion force (ZIF) clamshell socket into which you place the device, close the cover then program with the E1 or the PG- FP5.   However in practice many customers find an easier solution is to program the device directly in-system, with it already mounted inside the finished assembly and a programming connection made available to the external programmer. Target Application Hardware Stand alone

On-board Programming Interface Programming with dedicated programmer TOOL0 Communication Interface Internal “high speed” on-chip oscillator is used Secure protocol used Checksum command included Now to the programming interface itself. With a dedicated programmer the Tool0 interface, based on a single-wire UART, is used. The internal high speed on-chip oscillator is used for the clock signal, which means only 4 pins need to be connected from the programmer to the RL78 device; VDD, VSS, the reset line and the Tool0 interface. It’s important that a secure protocol is used for transmission of data from the FLASH programmer to the device, so it is guaranteed using a check sum.

Serial Programming Supported Commands Status command Reset command Baud Rate Set command Erase command Programming Command Verify command Block Blank Check command Silicon Signature command Version Get command Checksum command Set Security command For security reasons there is no read command available Here, we see a summary of all the commands for external programmers supported by the internal firmware. As we already mentioned, for security reasons there is no read command to read-out the device with an external programmer. The only way to identify the internal code is to perform a verify command. Thus the device itself and the serial programming interface support the following commands: Status command, Reset command, Baud rate set command, Erase command, Programming command, Verify command, Block blank check command, Silicon signature command, Version get command, Checksum command and Set Security command. In the case of the Verify command, all the data in the programmer is re-sent to the device which checks internally that the contents of the FLASH matches. All the data transmission between the programmer and the device will consume some time, another check sum command is again included. The difference with the check sum command is that the check sum value is calculated automatically inside the device and transmitted back to the programmer which checks whether the check sum is correct against its original data.

RL78 Flash Self-Programming Code Flash On the next few slides we’ll explain about self-programming the code flash area.

Self-programming in General Ability to reprogram the code flash contents without a dedicated programming tool. The internal firmware of the RL78 products allows to rewrite the flash memory. Renesas supports self-programming by providing appropriate libraries free of charge available These Self-programming libraries offer an easy-to-use interface to the internal firmware functionality. User Application Self-Programming Library Firmware Flash Memory First of all let's clarify what self-programming means. Self-programming is the ability to re-program the code flash without requiring a dedicated programmer. The internal firmware of the RL78 can be used to re-write its own flash memory using Renesas' Self-Programming Libraries. These libraries are available free of charge and offer an easy interface with which - for example - you can use the Erase instruction by merely passing the number of the block you want to erase as a parameter.   This function automatically returns a value indicating if the erase was OK, or if there was an error. In general, your user application performs flash operations by calling functions in the self-programming library.  However the library must be located in the user application area, and the library functions call internal firmware routines which are not located in the application area. It is this internal firmware which finally re-writes the FLASH content.

Self-programming in General User defined programming interface Interface type (I.e. CAN, LIN, CSI, UART, other) Block swapping is supported for secure self-programming Even if the boot loader has to be updated, it is ensured, that always a valid boot loader (two boot blocks) is available during self-programming Virgin programming with dedicated programmer is mandatory Contains at least self programming functionality User Application Self-Programming Library Firmware Flash Memory When using the self-programming option it's up to you define the programming communication interface, for example: CAN, LIN, CSI, UART or any other interface which could be used to transfer new data into the device.   Additionally, the block swapping feature is supported for secure self-programming, so that if the boot loader has to be updated, you can ensure that a valid boot loader is always available. Note that in order to implement the self-programming functionality and external interface, the initial programming must be done using a dedicated programmer and this initial code has to contain the self–programming functionality and interfacing, after which the device is able to reprogram its entire internal flash memory by itself.

Self-programming operation modes Internal status check mode FSL (Flash Self-programming Library) is located in the User ROM (flash) Call the FSL function directly from the ROM get feed back after execution No interrupt handling Advantages Easy to handle Internal self-programming operates in two modes; the first is Internal Status Check mode, where the FLASH self-programming library is located in user ROM, i.e. the code flash area, and the application calls self-programming library functions directly from ROM.   There the library function configures the programming parameters and jumps to the firmware routine, which returns with a status code after performing the operation (and thence back into the user application) so we can determine if the operation was OK or if an error occurred. While this solution is straight forward, no interrupt handling is possible during self- programming in the code flash area. So if the block is being erased in the background no code execution is possible during this time. Note that this is only valid for the code flash area; the data flash is completely independent and is always working in the background. The main advantage of this mode is that it is very easy to handle.

Self-programming operation modes 2)User status check mode Copy the FSL functionality into the RAM Execute the FSL from RAM Advantages No lengthened interrupt response Full control of software The second self-programming option is to use User Status Check mode. In this case the FSL self-programming functionality has to be copied into the RAM area of the device, and the code executed from RAM.   In this mode of operation the function jumps directly from the RAM into the internal firmware, starts the command and then goes directly back to RAM; with the internal programming or erasing of the Flash done in the background. However this requires a status check to be done in the RAM code to see when the firmware has finished with the command. This mode has the big advantage that interrupts can be handled without any effect on the interrupt response time, so the user application always has full control of the software.

Self-programming interrupt handling Selfprogramming execution from RAM Fast interrupt handling Common RAM interrupt used full control on user side Here we see how interrupt behavior changes when self-programming execution is done directly from RAM. In normal operation there are many interrupt service routines; for example handling interrupt vectors from the timers or the serial interface, and these occur at different times.   When self-programming is executed from RAM these interrupts are moved to a common interrupt vector that references the RAM area, so this common interrupt service routine in RAM is always executed independently of the interrupt source. This means that the user application retains full control and very fast interrupt response times, even during self-programming operation. However the overhead is that we now have to distinguish between the different interrupt sources in the common RAM interrupt service routine, which can be easily done by examining the IF flags.

Self-Programming - Ways Of Use The device is never rendered useless – because the boot block is not affected! Here is a summary of self-programming uses. Often self-programming is used merely to save parameters inside the application at end-of-line programming or factory programming where there is a free blank block inside the application.   Calibration parameters or serial numbers may need to be stored in the device following production. To do this the self-programming functionality can be used to write these parameters in a blank area of the device. This is the easiest method sometimes called “EEPROM emulation”.

Self-Programming - Ways Of Use The device is never rendered useless – because the boot block is not affected! When the entire application is updated, it’s a little more complex. Here is an example with a fixed boot block, where the boot block and application code is already programmed in the device via end-of-line programming or factory programming.   Now, if the code has to be updated in the field, all the old application code can be erased, but the boot block is still valid. This always allows us to have a secure reset vector. The new application is written into the normal code flash area and now we have the old boot block together with the new application. Note that the boot block code is also a part of the user application, so you have to develop it yourself, since it's not included with the device.

Self-Programming - Ways Of Use The device is never rendered useless – even if a failure occurs during writing the new boot block! An even more complex mechanism is to use self-programming together with the boot swap functionality, where the application, as well as the boot block is updated. To do this, the application code first has to be erased - in which case the old boot block is still valid.   Then a new boot block is written to boot cluster 1. Once this is done and we have a new secure boot block, we can change the boot blocks using the swap instruction. After this the new boot block is valid and the old boot block has been switched to boot cluster 1. Now the old boot block can be erased and the new application programmed into the code flash area. Using this method the flash is always secure and it's impossible to have an invalid reset vector after reset, due to power failure etc.

RL78 Flash Self-Programming Data Flash Now to self-programming the data flash area, which is a bit different compared to the code flash, since we have full background operation in the data flash area.

Data Flash Specification 1.000.000 W/E cycles @ 5 year data retention (typ.) 100.000 W/E cycles @ 5 year data retention Minimum data (write) size 1 byte (Data Flash) Flash (erase) block size 1KB Access with library (FDL) only Full temperature range during programming First off, let's examine the data flash specification. Currently up to 100,000 write/erase cycles with data retention of 5 years are guaranteed. And as a target we can guarantee 1,000,000 w/e cycles with data retention of 5 years. It's important to note that these write/erase cycles are different to a real EEPROM, since you can write data into a flash block several times until it has to be erased.   So although we say write/erase cycles it is actually the erase cycles that are important. For example a data set of 4 bytes could be written 256 times in a 1k block until the first time you need to erase the block. Thus the real write cycles are much higher than the given 100,000. The minimum write size in data flash is 1 byte and the flash erase block size is 1Kb. The access to data flash can only be done through the FDL data flash library - a very simple and small library that provides an easy interface to the data flash. Also note that the full temperature range is supported during data flash programming.

Background operation on devices with separate Data Flash Managing R/W accesses to the EEPROM data Optional Interface to user application Includes Data structures Calling convention Error handling … OS + Drivers + Application(s) Code Flash EEPROM Emulation Layer (EEL) CPU core Data Flash Access Layer (FDL) Basic Flash accesses E.g. Erase, Write Interface to EEPROM emulation layer Bootloader EEPROM Data On this slide is a block diagram of the internal functionality of the CPU, where the core can access the code flash and the data flash in parallel. The code flash contains the application, the operating system, drivers and so on, and also the EEPROM Emulation libraries – which are not always required - unlike the data flash access layer FDL library. This is all part of the code flash area. The application calls a function in the FDL, which starts the sequencer to re-write data in the data flash area, while the core can still go on working from the code flash area. So here we have full dual operation with completely background operation of the EEPROM data inside the data flash. Data Flash Independent Flash macros for dual operation on Code execution and Data Flash operations

Data flash operation timing Operation Flow Data flash operation timing The application code runs simultaneously when the EEPROM data is accessed. Data Flash behavior is like an external EEPROM application CPU Here is the timing flow of the data flash access. The CPU is executing the application from the code flash area. Now, writing data to the EEPROM or data flash area is done by calling a function from the FDL. The FDL starts the sequencer in the background and starts the write, or read, or erase access on the data flash while the CPU continues executing the application.   The sequencer handling the data flash content will give a signal back to the application - via polling or an interrupt - to indicate that the data flash access is completed and it's ready for the next one. This ensures that there are no lengthy interrupt times, always the standard interrupt response time, so the data flash behavior is the same as an external EEPROM. Request finished eeprom access eeprom access Request to read /write data

Possible scenario of data flash access Via FDL Simple access to data flash Via EEL and FDL Supports a EEPROM emulation in the data flash Application FDL Data flash Parameter saving Here we see a possible scenario for accessing the data flash. The easiest way is just to use the FDL. On the left side is the application colored grey. By using the FDL the application can write data directly into the data flash. However the EEPROM Emulation libraries are sometimes helpful to manage the data inside the data flash.   An EEPROM Library is available directly from Renesas Electronics but you could also develop your own EEPROM library. However in both cases you have to use the FDL. The EEPROM library completely manages the data - for example if a block is full - it's necessary to copy all the data to the next block in the data flash and so on. All this house-keeping is handled in the background by the EEPROM Library. Using these two libraries it is also possible to split the data flash in two different areas. For example you can use one block of data flash to store fixed parameters written directly from the application using the FDL. And the second part of the data flash can be used with EEPROM Emulation. All these different scenarios are supported by Renesas' EEPROM Emulation and the FDL libraries. EEPROM lib EEPROM emulation

RL78 Flash Self-Programming Libraries Now a few words about the different libraries and how they interact.

The basic configuration of the flash libraries for RL78 RL78 use a flash library when rewriting the code or data flash memory. Example : The flow of writing and reading User Application （User Program） Write or Read The RL78 device does not have a function of EEPROM Emulations Write Write or Read EEL (EEPROM Emulation Library) Software (Program Area) Write or Read FSL (Flash Self programming Library) FDL (Flash Data Library) Write Write Read Here are the basic configuration of all the flash libraries for the RL78 products. In general it's important to always use a library to write to the flash using self- programming.   At the top is the user application and on the left-hand side is the flow when writing into code flash memory. If you want to re-program the code flash memory the FSL flash self-programming library must be used. This can be done using the simple library interface. The library starts the sequencer - which is part of the firmware or hardware – and this sequencer finally writes the data into the code flash memory. The second way is to use data flash memory in which case you have to use the FDL or flash data library. The FDL also uses the sequencer for writing data to data flash memory, completely independently from the application code execution. So a read can be done directly from the data flash using just a pointer with no sequencer operation required. Additionally you can use the EEL, EEPROM Emulation Library. The EEL manages all the data so you don't have to worry where inside the data flash the instances of the data are stored and is also completely secure against any resets from outside or by power failures. Sequencer and Firmware Write Write Device (Firmware) Code Flash Memory Data Flash Memory

RL78 EEPROM -Emulation And finally a few words on the EEPROM Emulation library and the capabilities of this piece of software.

Renesas provide the corresponding access libraries free of charge EEPROM Emulation EEPROM emulation is the ability to use a part of the flash as a kind of EEPROM memory. Main difference to a real EEPROM is the ability to erase only a complete block This requires a special algorithm to handle the data sets inside the EEPROM area. Renesas provide the corresponding access libraries free of charge Real EEPROM EEPROM Emulation Data A Data B Data C EEPROM Emulation Updating Data B Erase old Data B Write new Data B’ Updating Data B Write new Data B’ Old Data B still available as history Data A Data B Data B’ What do we mean by EEPROM Emulation? EEPROM Emulation is just the ability to use the power of the RL’s data flash as an equivalent EEPROM memory. However there is an important difference compared to a real EEPROM - which can be overwritten address by address - whereas flash can only be erased in blocks. Thus a special algorithm is required to handle the data sets inside the EEPROM emulation area. The picture below shows this; when you want to update the data set B in a real EEPROM, you just have to erase the old data and then write the new data, which in a typical EEPROM is done in a single operation just by overwriting the data. However there is still a risk that the data may not be written correctly if the power fails during the re-writing. The EEPROM Emulation in flash works a bit differently; we can’t overwrite a single data byte because it’s only possible to do a block erase. Instead we have to add the data to the new data set - B’ in this case - to the end of the flash or to the next free position in the flash. This requires a special algorithm in the background, but has a big advantage that the history is always retained, which means that even if writing the new B data fails, we still have the history of B available. Renesas provide all the corresponding access libraries free of charge. Data C Data B’

Key functionalities of the Renesas EEPROM emulation library are: EEL Features Key functionalities of the Renesas EEPROM emulation library are: READ and WRITE at any time provided by: Automatic suspend/resume of ERASE command Automatic preparation of write-space in the idle phase Large amout of data can be managed (configurable > 1 block) bBock redundancy managed automatically RESET resistant algorithms Data consistency checks And finally the key functionalities of the Renesas EEPROM libraries; the main feature is that the library is always able to read and write data to the data flash. This means that you don’t have to worry about any special wait time when attempting a write or read. Even if an erase command is in progress in the background - preparing new space inside the library area - it will be suspended and the write command executed immediately. Automatic preparation of the write space is also done in the background during any idle time. The library can manage a large amount of data with multiple active data blocks. Block redundancy is managed automatically, so even if a block is damaged it will be marked so and the library will continue using the remaining blocks without any problems. The reset resistant algorithm is also very important; the data is secured in different ways so that even if a reset occurs during writing data to the data flash, the data is always secure and after reset the old data will be read if the new data was not completely written. Finally the data is ensured using data consistency checks, where each data set handled by the library has its own checksum and for every data read operation the checksum is compared with the data. To sum up, it’s a very easy to use library with all required functions included, so you can have a simple interface and all data types such as simple bytes, words, arrays and structures can be stored in the emulated EEPROM using the library.

Summary In this course, we covered: Self and external programming methods RL78 Flash features and architecture Security features Code and DataFlash organization Understand different libraries and their usage Thank You for viewing For more information on RL78 products, please view the RL78 Family Overview course or visit www.renesas.com In summary, in this course, we covered the RL78‘s flash features and archectecture including security features, code and data flash organization as well as self and external programming and the related librabries. We’d like to thank you for viewing this course. For more information on RL78 products, please view the RL78 Family overview course or visit the Renesas website at www.renesas.com

Thank You