The purpose of this course is to provide an introduction to the RL78's flash features and archectecture including security features, code and data

Transcription

1 1

2 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. 2

3 3

4 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. 4

5 4

6 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. 5

7 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. 5

8 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 6

9 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. 6

10 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 selfprogramming. 7

11 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. 7

12 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. 8

13 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. 9

14 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. 10

15 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 3 rd 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 11

16 programming functionality into your in-circuit test machine. Custom programmers can be certified by a FLASH programmer audit, which gives programmermanufacturers confidence that their programmed algorithm conforms to the RL78 device algorithm. 11

17 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. 12

18 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. 13

19 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. 14

20 On the next few slides we ll explain about self-programming the code flash area. 15

21 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. 16

22 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. 17

23 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 selfprogramming 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. 18

24 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. 19

25 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. 20

26 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. 21

27 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. 22

28 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. 23

29 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. 24

30 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. 25

31 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. 26

32 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. 27

33 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. 28

34 All these different scenarios are supported by Renesas' EEPROM Emulation and the FDL libraries. 28

35 Now a few words about the different libraries and how they interact. 29

36 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 selfprogramming. 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. 30

37 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. 30

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

39 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. 32

40 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 33

41 EEPROM using the library. 33

42 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 34

43 35