One-Time Passwords from Your Watch

Passwords establish the identity of a user, and they are an essential component of modern information technology. In this article, I describe one-time passwords: passwords that you use once and then never again. Because they’re used only once, you don’t have to remember them. I describe how to implement one-time passwords with a Texas Instruments (TI) eZ430-Chronos wireless development tool in a watch and how to use them to log in to existing web services such as Google Gmail (see Photo 1).

Photo 1—The Texas Instruments eZ430 Chronos watch displays a unique code that enables logging into Google Gmail. The code is derived from the current time and a secret value embedded in the watch.

To help me get around on the Internet, I use a list of about 80 passwords (at the latest count). Almost any online service I use requires a password: reading e-mail, banking, shopping, checking reservations, and so on. Many of these Internet-based services have Draconian password rules. For example, some sites require a password of at least eight characters with at least two capitals or numbers and two punctuation characters. The sheer number of passwords, and their complexity, makes it impossible to remember all of them.

What are the alternatives? There are three different ways of verifying the identity of a remote user. The most prevailing one, the password, tests something that a user knows. A second method tests something that the user has, such as a secure token. Finally, we can make use of biometrics, testing a unique user property, such as a fingerprint or an eye iris pattern.

Each of these three methods comes with advantages and disadvantages. The first method (passwords) is inexpensive, but it relies on the user’s memory. The second method (secure token) replaces the password with a small amount of embedded hardware. To help the user to log on, the token provides a unique code. Since it’s possible for a secure token to get lost, it must be possible to revoke the token. The third method (biometrics) requires the user to enroll a biometric, such as a fingerprint. Upon login, the user’s fingerprint is measured again and tested against the enrolled fingerprint. The enrollment has potential privacy issues. And, unlike a secure token, it’s not possible to revoke something that is biometric.

The one-time password design in this article belongs to the second category. A compelling motivation for this choice is that a standard, open proposal for one-time passwords is available. The Initiative for Open Authentication (OATH) is an industry consortium that works on a universal authentication mechanism for Internet users. They have developed several proposals for user authentication methods, and they have submitted these to the Internet Engineering Task Force (IETF). I’ll be relying on these proposals to demonstrate one-time passwords using a eZ430-Chronos watch. The eZ430-Chronos watch, which I’ll be using as a secure token, is a wearable embedded development platform with a 16-bit Texas Instruments MSP430 microcontroller.


Figure 1 demonstrates how one-time passwords work. Let’s assume a user—let’s call him Frank—is about to log on to a server. Frank will generate a one-time password using two pieces of information: a secret value unique to Frank and a counter value that increments after each authentication. The secret, as well as the counter, is stored in a secure token. To transform the counter and the secret into a one-time password, a cryptographic hash algorithm is used. Meanwhile, the server will generate the one-time password it is expecting to see from Frank. The server has a user table that keeps track of Frank’s secret and his counter value. When both the server and Frank obtain the same output, the server will authenticate Frank. Because Frank will use each password only once, it’s not a problem if an attacker intercepts the communication between Frank and the server.

Figure 1—A one-time password is formed by passing the value of a personal secret and a counter through a cryptographic hash (1). The server obtains Frank’s secret and counter value from a user table and generates the same one-time password (2). The two passwords must match to authenticate Frank (3). After each authentication, Frank’s counter is incremented, ensuring a different password the next time (4).

After each logon attempt, Frank will update his copy of the counter in the secure token. The server, however, will only update Frank’s counter in the user table when the logon was successful. This will intercept false logon attempts. Of course, it is possible that Frank’s counter value in the secure token gets out of sync with Frank’s counter value in the server. To adjust for that possibility, the server will use a synchronization algorithm. The server will attempt a window of counter values before rejecting Frank’s logon. The window chosen should be small (i.e., five). It should only cover for the occasional failed logon performed by Frank. As an alternate mechanism to counter synchronization, Frank could also send the value of his counter directly to the server. This is safe because of the properties of a cryptographic hash: the secret value cannot be computed from the one-time password, even if one knows the counter value.

You see that, similar to the classic password, the one-time password scheme still relies on a shared secret between Frank and the server. However, the shared secret is not communicated directly from the user to the server, it is only tested indirectly through the use of a cryptographic hash. The security of a one-time password therefore stands or falls with the security of the cryptographic hash, so it’s worthwhile to look further into this operation.


A cryptographic hash is a one-way function that calculates a fixed-length output, called the digest, from an arbitrary-length input, called the message. The one-way property means that, given the message, it’s easy to calculate the digest. But, given the digest, one cannot find back the message.

The one-way property of a good cryptographic hash implies that no information is leaked from the message into the digest. For example, a small change in the input message may cause a large and seemingly random change in the digest. For the one-time password system, this property is important. It ensures that each one-time password will look very different from one authentication to the next.

The one-time password algorithm makes use of the SHA-1 cryptographic hash algorithm. This algorithm produces a digest of 160 bits. By today’s Internet standards, SHA-1 is considered old. It was developed by Ronald L. Rivest and published as a standard in 1995.

Is SHA-1 still adequate to create one-time passwords? Let’s consider the problem that an attacker must solve to break the one-time password system. Assume an attacker knows the SHA-1 digest of Frank’s last logon attempt. The attacker could now try to find a message that matches the observed digest. Indeed, knowing the message implies knowing a value of Frank’s secret and the counter. Such an attack is called a pre-image attack.

Fortunately, for SHA-1, there are no known (published) pre-image attacks that are more efficient than brute force trying all possible messages. It’s easy to see that this requires an astronomical number of messages values. For a 160-bit digest, the attacker can expect to test on the order of 2160 messages. Therefore it’s reasonable to conclude that SHA-1 is adequate for the one-time password algorithm. Note, however, that this does not imply that SHA-1 is adequate for any application. In another attack model, cryptographers worry about collisions, the possibility of an attacker finding a pair of messages that generate the same digest. For such attacks on SHA-1, significant progress has been made in recent years.

The one-time password scheme in Figure 1 combines two inputs into a single digest: a secret key and a counter value. To combine a static, secret key with a variable message, cryptographers use a keyed hash. The digest of a keyed hash is called a message authentication code (MAC). It can be used to verify the identity of the message sender.

Figure 2 shows how SHA-1 is used in a hash-based message authentication code (HMAC) construction. SHA-1 is applied twice. The first SHA-1 input is a combination of the secret key and the input message. The resulting digest is combined again with the secret key, and SHA-1 is then used to compute the final MAC. Each time, the secret key is mapped into a block of 512 bits. The first time, it is XORed with a constant array of 64 copies of the value 0x36. The second time, it is XORed with a constant array of 64 copies of the value 0x5C.

Figure 2—The SHA-1 algorithm on the left is a one-way function that transforms an arbitrary-length message into a 160-bit fixed digest. The Hash-based message authentication code (HMAC) on the right uses SHA-1 to combine a secret value with an arbitrary-length message to produce a 160-bit message authentication code (MAC).


With the HMAC construction, the one-time password algorithm can now be implemented. In fact, the HMAC can almost be used as is. The problem with using the MAC itself as the one-time password is that it contains too many bits. The secure token used by Frank does not directly communicate with the server. Rather, it shows a one-time password Frank needs to type in. A 160-bit number requires 48 decimal digits, which is far too long for a human.

OATH has proposed the Hash-based one-time password (HOTP) algorithm. HOTP uses a key (K) and a counter (C). The output of HOTP is a six-digit, one-time password called the HOTP value. It is obtained as follows. First, compute a 160-bit HMAC value using K and C. Store this result in an array of 20 bytes, hmac, such that hmac[0] contains the 8 leftmost bits of the 160-bit HMAC string and hmac[19] contains the 8 rightmost bits. The HOTP value is then computed with a snippet of C code (see Listing 1).

Listing 1—C code used to compute the HTOP value

There is now an algorithm that will compute a six-digit code starting from a K value and a C value. HOTP is described in IETF RFC 4226. A typical HOTP implementation would use a 32-bit C and an 80-bit K.

An interesting variant of HOTP, which I will be using in my implementation, is the time-based one-time password (TOTP) algorithm. The TOTP value is computed in the same way as the HOTP value. However, the C is replaced with a timestamp value. Rather than synchronizing a C between the secure token and the server, TOTP simply relies on the time, which is the same for the server and the token. Of course, this requires the secure token to have access to a stable and synchronized time source, but for a watch, this is a requirement that is easily met.

The timestamp value chosen for TOTP is the current Unix time, divided by a factor d. The current Unix time is the number of seconds that have elapsed since midnight January 1, 1970, Coordinated Universal Time. The factor d compensates for small synchronization differences between the server and the token. For example, a value of 30 will enable a 30-s window for each one-time password. The 30-s window also gives a user sufficient time to type in the one-time password before it expires.


I implemented the TOTP algorithm on the eZ430-Chronos watch. This watch contains a CC430F6137 microcontroller, which has 32 KB of flash memory for programs and 4,096 bytes of RAM for data. The watch comes with a set of software applications to demonstrate its capabilities. Software for the watch can be written in C using TI’s Code Composer Studio (CCStudio) or in IAR Systems’s IAR Embedded Workbench.

The software for the eZ430-Chronos watch is structured as an event-driven system that ties activities performed by software to events such as alarms and button presses. In addition, the overall operation of the watch is driven through several modes, corresponding to a particular function executed on the watch. These modes are driven through a menu system.

Photo 2 shows the watch with its 96-segment liquid crystal display (LCD) and four buttons to control its operation. The left buttons select the mode. The watch has two independent menu systems, one to control the top line of the display and one to control the bottom line. Hence, the overall mode of the watch is determined by a combination of a menu-1 entry and a menu-2 entry.

Photo 2—With the watch in TOTP mode, one-time passwords are shown on the second line of the display. In this photo, I am using the one-time password 854410. The watch display cycles through the strings “totP,” “854,” and “410.”

Listing 2 illustrates the code relevant to the TOTP implementation. When the watch is in TOTP mode, the sx button is tied to the function set_totp(). This function initializes the TOTP timestamp value.

Listing 2—Code relevant to the TOTP implementation

The function retrieves the current time from the watch and converts it into elapsed seconds using the standard library function mktime. Two adjustments are made to the output of mktime, on line 11 and line 12. The first factor, 2208988800, takes into account that the mktime in the TI library returns the number of seconds since January 1, 1900, while the TOTP standard sets zero time at January 1, 1970. The second factor, 18000, takes into account that my watch is set to Eastern Standard Time (EST), while the TOTP standard assumes the UTC time zone—five hours ahead of EST. Finally, on line 14, the number of seconds is divided by 30 to obtain the standard TOTP timestamp. The TOTP timestamp is further updated every 30 s, through the function tick_totp().

The one-time password is calculated by compute_totp on line 33. Rather than writing a SHA1-HMAC from scratch, I ported the open-source implementation from Google Authenticator to the TI MSP 430. Lines 39 through 50 show how a six-digit TOTP code is calculated from the 160-bit digest output of the SHA1-HMAC.

The display menu function is display_totp on line 52. The function is called when the watch first enters TOTP mode and every second after that. First, the watch will recompute the one-time password code at the start of each 30-s interval. Next, the TOTP code is displayed. The six digits of the TOTP code are more than can be shown on the bottom line of the watch. Therefore, the watch will cycle between showing “totP,” the first three digits of the one-time password, and the next three digits of the one-time password. The transitions each take 1 s, which is sufficient for a user to read all digits.

There is one element missing to display TOTP codes: I did not explain how the unique secret value is loaded into the watch. I use Google Authenticator to generate this secret value and to maintain a copy of it on Google’s servers so that I can use it to log on with TOTP.


Google Authenticator is an implementation of TOTP developed by Google. It provides an implementation for Android, Blackberry, and IOS so you can use a smartphone as a secure token. In addition, it also enables you to extend your login procedure with a one-time password. You cannot replace your standard password with a one-time password, but you can enable both at the same time. Such a solution is called a two-factor authentication procedure. You need to provide a password and a one-time password to complete the login.

As part of setting up the two-factor authentication with Google (through Account Settings – Using Two-Step Verification), you will receive a secret key. The secret key is presented as a 16-character string made up of a 32-character alphabet. The alphabet consists of the letters A through Z and the digits 2, 3, 4, 5, 6, and 7. This clever choice avoids numbers that can confused with letters (8 and B, for example). The 16-character string thus represents an 80-bit key.

I program this string in the TOTP design for the eZ430-Chronos watch to initialize the secret. In the current implementation, the key is loaded in the function reset_totp().

base32_decode((const u8 *)
      ”4RGXVQI7YVY4LBPC”, stotp.key, 16);

Of course, entering the key as a constant string in the firmware is an obvious vulnerability. An attacker who has access to a copy of the firmware also has the secret key used by the TOTP implementation! It’s possible to protect or obfuscate the key from the watch firmware, but these techniques are beyond the scope of this article. Once the key is programmed into the watch and the time is correctly set, you can display TOTP codes that help you complete the logon process of Google. Photo 1 shows a demonstration of logging onto Google’s two-step verification with a one-time password.


There are other possibilities for one-time passwords. If you are using Linux as your host PC, you can install the OATH Toolkit, which implements the HOTP and TOTP mechanisms for logon. This toolkit enables you to install authentication modules on your PC that can replace the normal login passwords. This enables you to effectively replace the password you need to remember with a password generated from your watch.

Incidentally, several recent articles—which I have included in the resources section of this article—point to the limits of conventional passwords. New technologies, including one-time passwords and biometrics, provide an interesting alternative. With standards such as those from OATH around the corner, the future may become more secure and user-friendly at the same time.

[Editor’s note: This article originally appeared in Circuit Cellar 262, May 2012.]

Patrick Schaumont writes the Embedded Security column for Circuit Cellar magazine. He is an Associate Professor in the Bradley Department of Electrical and Computer Engineering at Virginia Tech. Patrick works with his students on research projects in embedded security, covering hardware, firmware, and software.


To download the code, go to


Google Authenticator,

Initiative for Open Authentication (OATH),

Internet Engineering Task Force (IETF),

D. M’Raihi, et al, “TOTP: Time-Based One-Time Password Algorithm,” IETF RFC 6238, 2011.

—, “HOTP: An HMAC-Based One-Time Password Algorithm,” IETF RFC 4226, 2005.

OATH Toolkit,

K. Schaffer, “Are Password Requirements Too Difficult?,” IEEE Computer Magazine, 2011.

S. Sengupta, “Logging in With a Touch or a Phrase (Anything but a Password),” New York Times, 2011.


IAR Embedded Workbench – IAR Systems

eZ430-Chronos Wireless development system and Code Composer Studio (CCStudio) IDE – Texas Instruments, Inc.


RL78 Green Energy Design Challenge Deadline Approaches

Attention engineers, programmers, and electronics enthusiasts! The entry deadline of August 31 for the Renesas RL78 Green Energy Challenge is fast approaching. Here are some tips to keep you on schedule.


The challenge is to design an innovative, energy-efficient application that features the Renesas RL78 MCU, RL78/G13 Renesas Demonstration Kit (RDK), and IAR Toolchain. For information, visit the Eligible Parts page on the design challenge site.

Renesas RDK RL78 board


Once you’re done designing your RL78-based project, you need to gather and order your entry materials: project abstract, complete documentation, and code.

Make sure you register for the challenge to obtain a registration number. Label all of your files and documents with your registration number. Don’t put your name on the files and documents.

Consider organizing all of your entry in a ZIP (or RAR) file. Compressing all of your files into one ZIP will keep your entry organized and easier to submit.


Before you submit your entry, go through the following checklist one last time to ensure you have everything:

• Abstract (a short project description)
• Complete documentation (a detailed project description)
• Block diagram(s)
• Schematic(s)
• Project photograph(s)
• Source code
• Files are properly labeled (your name doesn’t appear in the entry files)

More details are posted on the challenge’s FAQ webpage.


Ready to submit your entry? The preferred submission method is to upload your project files via the RL78 Design Challenge Dropbox.

Or send project files to:

RL78 Green Energy Challenge, Circuit Cellar, 4 Park Street, Vernon, CT 06066, USA

Good luck!

The Renesas RL78 for Low-Power Applications

Renesas Technology announced in late March he start of a design challenge for engineers around the world: develop an innovative, low-power application using the RL78 MCU and IAR Systems toolchain. To get started, you need to familiarize yourself with the RL78. Clemens Valens, Editor-in-Chief of Elektor online, introduces the RL78 in a comprehensive “The RL78 Microcontroller: An MCU Family for Low-Power Applications” (Circuit Cellar 261, 2012).

I’ve worked with Valens in various occasions, and had the pleasure of meeting him in 2011. He’s truly “an engineer’s engineer”: extremely embedded tech savvy, well-read, and inquisitive. Furthermore, I edited Circuit Cellar articles Valens wrote about diverse design projects, such as a virtual instrument interface and a scrolling LED message board. Thus, it’s clear to me that Valens understands the importance of designing high-quality, energy-efficient, systems—and doing so within budget. I trust you’ll find his introduction to the RL78 insightful and immediately applicable.

The RL78 Microcontroller: An MCU Family for Low-Power Applications

By Clemens Valens (Circuit Cellar 261, 2012)

The low-power 8/16-bit microcontroller (MCU) market is a bit of a warzone with several MCU manufacturers proposing “the industry’s lowest power solution.” In a YouTube video, Texas Instruments boasts a best active figure of 160 μA/MIPS for their MSP430 family. In application note AN1267, Microchip Technology claims 110 μA at “1 MHz Run” for their PIC16LF72X. And Renesas Electronics announced 70 μA at “1-MHz normal operation” on their RL78 product website.[1, 2, 3] The absence of justification on how exactly these figures were obtained makes comparing them rather useless. But then again, you don’t really have to because, as most low-power developers know from experience, if you don’t get the hardware and software design right, you will never attain the promised 20-year battery lifetime no matter how low the MCU’s active, sleep, or standby current may be. In this article, I will take a closer look at Renesas’s quickly expanding RL78 family to see what they offer that may help you create a low-power design.

Photo 1 - The Renesas RL78


The RL78 family of 16-bit MCUs currently has two branches, “generic” and “application specific,” but a third “display” branch is forthcoming. The generic branch contains the subfamilies G12, G13, and G1A, all based on the 78K core, and the G14, which is based on the R8C core. In the application-specific branch there is the 1A and F12. I am not sure about their core origins as these products are still very new and, at the time of writing, documentation is missing. It doesn’t really matter; from now on it is the new RL78 core for all. Since they share the same core, I will concentrate on the G13 for which I have a nice evaluation board (see Photo 1 and “The Renesas Demonstration Kit for RL78” sidebar).

Sidebar: Renesas Demonstration Kit


This family comes in a large number of variants (I counted 182), with devices having from 20 up to 128 pins (see Figure 1). Note that the parts themselves are labelled R5F10xx. The differences between all these variants are, besides the package type, the amounts of flash memory (program and data) and RAM. Program flash memory starts at 16 KB and currently ends at 512 KB, data flash sizes can be 0, 4, or 8 KB and RAM is 2 KB for the small devices and up to 32 KB for the big ones.

Figure 1 - Diagram of 128-pin RL78/G13 devices

The CPU is 16-bit, but the internal memory architecture is 8 bit. Its 32 general-purpose registers are organized in four banks of eight and can be used as 8- or 16-bit registers. The memory-mapped special function registers (SFRs) that control the on-chip peripherals can be addressed per bit, per byte, or as 16-bit registers, depending on the register. A second set of SFRs, the extended or second SFRs, are available too, but they need longer instructions to be accessed.

For those who need to squeeze the maximum out of MCU performance, it may be interesting to know that the CPU offers a short addressing mode enabling you to access a page of 256 bytes with a minimum amount of code.

The maximum clock frequency of the processor is 32 MHz, but the hardware user’s manual, which is almost 1,100 pages, interestingly also boasts about the ultra-low-speed capabilities of the processor as it can run from a 32.768-kHz clock.

The RL78 core features 15 I/O ports, most of which are 8-bit wide. Port 13 is 2-bit wide and ports 10 and 15 are 7-bit wide. The port pins that are actually available depend on the device. Inputs and outputs are highly configurable. Inputs can be analog, CMOS, or TTL. Outputs can be CMOS or N-channel open drain. Pull-up resistors are available too. The exact configuration possibilities depend on the port pin, so consult the datasheet. Because of the many configuration options, it is possible to use the MCU in multi-voltage systems without level-shifting circuitry except for the occasional external pull-up resistor. The chip can be powered from 1.6 V to 5.5 V, the core itself runs from 1.8 V provided by an internal voltage regulator.


Several options are available for the MCU clock. When clock precision is not too important, the MCU can be run from its internal clock, up to 32 MHz, otherwise it is possible to connect an external crystal, resonator, or oscillator. An internal low-speed clock (15 kHz) is also available, but not for the CPU, only for the watchdog timer (WDT), the real-time clock (RTC), and the interval timer.

The timers of the RL78 are flexible and offer many functions. Depending on the pin size of the device, you can have up to 16 16-bit timers, grouped in two arrays of eight. Each timer (called a “channel”) can function as an interval timer, square-wave generator, event counter, frequency divider, pulse-interval timer, pulse-duration timer, and delay counter. For even more possibilities, timers can be combined to create monostable multivibrators or to do pulse-width modulation (PWM). This way, up to seven PWM signals can be generated from one master timer. If you need more timers but resolution is less important, you can split some 16-bit timers in two 8-bit timers (this is not possible with all timers). Timer 7 of array 0 is extra special as it features local interconnect network (LIN) network support (see below).

Aside from date and time keeping with alarms, the RTC also provides constant period interrupts at 2 Hz and 1 Hz and also every minute, hour, day, or month. A 1-Hz output is available on devices with 40 or more pins. For extra precision, the RTC offers a correction register for fine tuning the 32,768-kHz clock. Unsurprisingly, the RTC continues operation when the MCU is stopped.

Now that I mentioned Stop mode, a special interval timer peripheral enables wakeup from this mode at periodic intervals. This timer is also used for the analog-to-digital converter’s (ADC’s) Snooze mode. More on that later. With a clock frequency of 32,768 Hz, the lowest interval rate is 8 Hz (0.125 ms).

Yet another time-related peripheral on the RL78 is the buzzer controller (not available on 20-pin devices). This is a clock output destined at IR comms carrier generation, to clock other chips in a system or to produce sound from a buzzer. A gate bit enables modulation of this output in such a way that pulses always have the same width.

Finally, a WDT completes the timing peripherals. It has a special Window mode that limits the time frame during which you can reset the watchdog to a fraction of the watchdog interval (50%, 75%, or 100%). Resetting the watchdog counter outside the window results in a reset. The window is open in the second part of the interval. An interrupt can be generated when the WDT reaches 75% of its time-out value, (i.e., when the watchdog reset window is known to be open in all cases). Figure 2 illustrates the mechanism.

Figure 2 - Trying to reset the watchdog counter when the window is closed results in an internal reset signal


The ADC is of the 10-bit successive approximation type and can have up to 26 inputs. Several triggering options are provided, hardware and software, where hardware triggering means triggering by a timer module (timer channel 1 end of count or capture, interval timer, or RTC). The time it takes to do a conversion depends partly on the triggering mode. When input stabilization is not too much of an issue (i.e., when you don’t switch inputs) you can achieve conversion times of just over 2 μs.

Two registers enable comparing the ADC’s output to maximum and minimum values, producing an interrupt when the new value is either in or out of bounds. This function is also available in Snooze mode. In this mode, the processor itself is stopped and consumes very little power, but ADC conversions continue under control of the hardware trigger. When a conversion triggers an ADC interrupt, the processor can then wake up from Snooze mode and resume normal operation.


The RL78 features multifunction serial units. The devices with 25 pins or less have one such unit, the others have two. Only serial unit 2 provides LIN bus support.

A serial unit can function in asynchronous UART mode, in synchronous CSI mode (three-wire bus with clock, data in and data out signals, master and slave mode supported), and in simplified (master-only) I²C mode. Again, depending on the device, you can have up to four UARTs or eight CSI and/or simplified I²C ports. Of course a mix is also possible. Full I²C is possible with the specialized I²C unit.

UART0 and UART2, CSI00 and CSI20 provide Snooze mode functionality similar to the ADC. In Snooze mode, these ports can be made to wake up on the arrival of incoming data without waking up the CPU. If the received data is interesting enough, it is also possible to wake up the CPU.

LIN communications are possible with UART2 together with Timer 7 of Array 0. The LIN bus is an inexpensive alternative to the CAN bus in automotive systems to control simple devices like switches, sensors, and actuators. LIN only uses one wire and is rather low speed (20 Kbps maximum). The timer takes care of the LIN synchronization issues and the UART performs the (de)serialisation of the data.

Full blown I²C communication is possible with the specialized I²C peripheral IICA. The 80-pin and more devices have two channels, the others only one. Communication speeds up to 20 MHz are permitted to enable I²C “fast mode” (3.5 MHz) and “fast mode plus” (10 MHz). This module is capable of waking up the CPU from Stop mode.


Of interest is the hardware multiplier and divider module intended for filtering and FFT functions. This module is capable of 16 × 16 bits signed and unsigned multiplications and divisions producing 32-bit results. It can also do 16 × 16 bit multiply-accumulate. We are talking about a module here, not an instruction, meaning that you have to load the operands yourself in special registers and get the result from yet another. The multiplication itself is done in one clock cycle, a division takes 16. The accumulate operation adds another cycle.

Another special math function is the binary-coded decimals (BCD) correction register that enables you to easily transform binary calculation results into BCD results.


To speed up data transport without loading the CPU, the RL78 core features direct memory access (DMA), up to four channels. DMA transfers up to 1,024 words of data (8 or 16 bit) to and from SFRs and RAM and they can be started by a range of interrupts (e.g., ADC, serial, timer). Although DMA transfers are done in parallel with normal CPU operation, it does slow down the CPU. For time-critical situations, it is possible to put a DMA transfer on hold for a number of clock cycles and let the CPU finish its job first.


Interrupts are pretty standard on the RL78 and many sources are available. The “key interrupt” function on the other hand is less common. It provides up to eight (depending on the device, you guessed it) key or push button inputs that are ORed together to generate an interrupt on a key press (active low).


Besides the aforementioned Stop and Snooze modes, the RL78 also provides a Halt mode. In this mode, the CPU is stopped but the clocks keep running, making a fast resume possible. In Stop mode, the clocks are stopped too reducing power consumption more than in Halt mode. Snooze mode is like Stop mode, but with one or more peripherals in a snoozing state, ready to wake up when something interesting happens. Interrupts can be used to wake up from Snooze, Stop, or Halt mode. A reset usually works too.

Reset, by the way, can have seven origins, three of which are related to safety functions: illegal instruction, RAM parity, and illegal memory access. Two others involve the power supply: power-on reset (POR) and low-voltage detection (LVD). All these reset options are needed to conform to the International Electrotechnical Commission (IEC) 60730-1 (“Automatic Electrical Controls for Household and Similar Use; Part 1: General Requirements”) and IEC 61508-SER (“Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems”) safety standards. Since the RL78 is compliant, it also implements flash memory CRC checking, protections to prevent RAM and SFRs to be modified when the CPU stops functioning, an oscillator frequency-detection circuit, and an ADC self-test function.

The hardware used for the flash memory CRC check is also available as a general-purpose CRC module for user programs. It implements the standard CCITT CRC-16 polynomial (X^16 + X^12 + X^5 + 1).

The RAM guard function protects only up to 512 bytes, so be careful where you put your sensitive data.


Those familiar with the fuse bytes of PIC and AVR processors will be happy to know that the RL78 contains four of them, the option bytes that configure such things as the WDT, low-voltage detection, flash memory modes, clock frequencies, and debugging modes.

Flash memory is divided into two parts, program memory and data memory, and it can be programmed in-circuit over a serial interface. A boot partition is available too. This partition uses a kind of ping-pong mechanism called “boot swapping” to ensure that a valid bootloader is always programmed into the boot partition so that even power failures during bootloader programming will not harm the boot partition. A flash window function protects the memory against unintentionally reprogramming parts of it.


This concludes our voyage through the Renesas RL78 core. As you have seen, the RL78 offers many interesting peripherals all combined in a flexible low-power optimized design. Thanks to the integrated oscillator and other functions, an RL78 MCU can be used with very little external hardware, enabling inexpensive and compact designs. Once you master its Snooze mode and your low-power design skills, you can use this MCU family in battery-operated metering applications, for instance, but I am sure you can think of something more surprising.

Clemens Valens ( is Editor-in-Chief of Elektor Online. He has more than 15 years of experience in embedded systems design. Clemens is currently interested in sound synthesis techniques, rapid prototyping, and the popularization of technology.


[1] Texas Instruments, Inc., “Ultra-Low Power MSP430 – The World’s Lowest Power MCU,” 201.

[2] Microchip Technology, Inc., “AN1267: nanoWatt and nanoWatt XLP Technologies: An Introduction to Microchip’s Low-Power Devices,” 2009.

[3] Renesas Electronics Corp., “RL78 Family,”


International Electrotechnical Commission (IEC), “60730-1, Automatic Electrical Controls for Household and Similar Use; Part 1: General Requirements,” 2002.

———, “61508-SER, Functional Safety of Electrical/

Electronic/Programmable Electronic Safety-Related Systems,” 2010.

Renesas Electronics Corp., Renesas Rulz, “RL78/G13 Demonstration Kit,”

For more information about the RL78 Family of microcontrollers, visit

For information about the 2012 Renesas RL78 Green Energy Challenge (in association with Elektor & Circuit Cellar), go to

This article appears in Circuit Cellar 261 (April 2012).



Design West Update: Compilers Unveiled

IAR Systems announced Tuesday at Design West in San Jose, CA, that GainSpan selected IAR Embedded Workbench as its primary development tool chain for MCU drivers and next-generation chip. “By standardizing on IAR Systems’ embedded software development tool chain, GainSpan will more easily support a wide range of MCUs to communicate with their modules,” IAR publicized a in a release.

It’s an important aspect of a larger plan, IAR’s ARM Strategic Accounts Manager Mike Skrtic said. IAR has overall tool chain standardization goals aimed at giving designers’ more flexibility when choosing MCUs for product development.

Remember: IAR Systems is teamed with Renesas for the RL78 Green Energy Challenge, which is administered by Circuit Cellar and Elektor. Designers are challenged to transform how the world experiences energy efficiency by developing a unique, low-power application using the RL78 MCU and IAR toolchain.

In other compiler-related news, Microchip Technology announced Monday at Design West its new MPLAB XC C compiler line, which supports its approximately 900 microcontrollers. Microchip’s Joe Drzewiecki said the compilers reduce code size by about 35% and improve code execution speed by about 30%. But you can judge for yourself because Microchip offers 8-, 16-, and 32-bit free editions of MPLAB XC compilers. According to Microchip reps, they are” fully functional and have no license restrictions for commercial use.”

So, if you give MPLAB XC a try, let us know what you think!

Renesas RL78 Green Energy Challenge

Up for an international design challenge? It’s time for the Renesas RL78 Green Energy Challenge! Renesas has partnered with IAR Systems to deliver engineers a power-house combo of low-power devices and high-quality software. They’re steering a great, green revolution and are challenging you to transform how the world experiences energy efficiency by developing a unique, low-power application using the RL78 MCU and IAR toolchain. Succeed and win a share of $17,500 in Grand Prizes from Renesas! * The Renesas Grand Prize winner will also win a free trip to Renesas DevCon in October where winners will be announced.

But that’s not all. Earn additional prizes like developments tools, Pmods, Wi-Fi modules, embedded systems books, and more from Contest Partners through weekly prize drawings. Follow Renesas on Twitter and Facebook for weekly challenge questions from official Contest Partners. Weekly Partner Challenges, and the respective winners, will be announced every Monday throughout the competition.

So, do you have a great idea for a remote device that monitors pollution? What about a box collecting data on home power usage or an energy harvesting biometric design? Perhaps your grand plan is for a low power controller scavenging heat from an oven or furnace, a meter reading biomass parameters, or a braking system for a wind turbine? It’s up to you! Send us your best RL78 based ideas to help make the world a better place.

The Challenge starts March 26, 2012 and ends on August 31, 2012. Winners will be announced in October at Renesas’ DevCon 2012.

Hundreds of free RL78/G13 development kits (“RDK”s), loaded with IAR’s Kickstart edition, are being distributed to those who qualify. Click here to see if you qualify for a complimentary RDK!

*Prizes in U.S. dollars.

Circuit Cellar, Inc. and Elektor International Media is the Contest Administrator.