True Random Number Generation on an Atmel
AVR Microcontroller
Josef Hlaváč, Róbert Lórencz
Faculty of Information Technology
Czech Technical University in Prague
Kolejnı́ 550/2, 160 00 Praha, Czech Republic
Email: {josef.hlavac,robert.lorencz}@fit.cvut.cz
Abstract—We present a method of generating true random
numbers on an Atmel AVR microcontroller. The jitter of the
built-in RC oscillator is used as the source of entropy to generate
8 random bits per second. When implemented on the AVR
Butterfly demo board, our method needs no external components;
otherwise, only an external oscillator is needed. We tested the
generated random bitstream using the “sts” test suite by NIST
and discuss the result. Finally, we suggest a possible way of
generating slightly more entropy and a method of avoiding
external components altogether.
I. I NTRODUCTION
Random number generation is a frequent requirement in
embedded applications. Random numbers are used, for exam-
ple, to control the behavior of computer-controlled opponents
in computer games, to simulate dice throwing, or to generate
cryptographic keys.
The mentioned uses require various degrees of randomness.
In some situations, it is sufficient to use a pseudo-random
generator whose output is deterministic but difficult to predict
by a human. In other situations, such as in cryptographic
applications, generated bits must be truly random, otherwise
the security of the entire application could be compromised.
In this paper, we present a method of generating true random
bits on an Atmel AVR microcontroller [1]. Although the AVR
series of 8-bit microcontrollers is not equipped with dedicated
hardware random number generation facilities, we show that
it is possible to get entropy from the built-in RC oscillator.
We demonstrate our method on an AVR Butterfly demo board
[2] with no extra components or modifications.
II. R ANDOM NUMBER GENERATION
The ATmega169 microcontroller [1] on the AVR Butterfly
demo board [2] can access several oscillators. The default
configuration uses an on-chip RC oscillator for the system
clock, and can utilize an oscillator with an externally con-
nected crystal as an asynchronous clock generator for the
Timer/Counter 2 unit. There is also another built-in oscillator
dedicated for the watchdog timer, which we do not use in our
design (but discuss its possible use later in this paper).
These oscillators are never perfectly stable. Their frequen-
cies are influenced by many physical factors, such as the the
supply voltage or ambient temperature, and also subject to
inherent jitter. It is important to note that the effect of these
c
978-1-4244-6349-7/10/$26.00 2010 IEEE
Martin Hadáček
Faculty of Electrical Engineering
Czech Technical University in Prague
Technická 2, 166 17 Praha, Czech Republic
Email: hadacmar@fel.cvut.cz
Fig. 1. Principle of operation. The inherent jitter of the RC oscillator leads
to a different count being read in each interrupt handler invocation.
factors is significantly different on each of the oscillators.
The crystal oscillator is much more stable in the entire range
of operating conditions, while the RC oscillator, although
calibrated, exhibits significant variations. Even if the board
is kept in a stable environment and powered from a stabilized
source, the RC oscillator exhibits easily measurable jitter.
The jitter of the RC oscillator is the source of entropy in
our method. We use the crystal oscillator to time a constant
period (1 second), and we count the number of cycles of the
RC oscillator that occur during that time. In an ideal world,
the cycle count would always be the same; however, in reality,
we observed a difference of up to 212 clock cycles between
successive measurements (0.2% of the total number of clock
cycles).
Now, to generate the actual random bits, we use the fol-
lowing method. The Timer/Counter 1 unit counts the cycles
of the system RC oscillator (running at the default setting of
2 MHz). The Timer/Counter 2 unit with the crystal oscillator
(32.768 kHz) and an appropriate prescaler configuration is
used to generate an interrupt every 1 second. In the interrupt
handling routine, the 16-bit value in the Timer/Counter 1
register TCNT1 is read (that is, the number of clock cycles
counted modulo 216 ) and the TCNT1 register is reset to zero.
Then, bits 1 through 8 are extracted from the retrieved 16-bit
value and output as a part of the generated random bit stream.
The interrupt handler then exits.
The principle of operation is depicted in Fig. 1.
V2-493
 0.0006 the LSB stays constant.
For the remaining bits 1–8, some randomness tests still
0.0005 failed. These were the “Universal” test [6], which failed due
to insufficient length of the random sequence, and several out
0.0004 of many instances of the “NonOverlappingTemplate” test. In
the latter case, the results should be still OK because at the
0.0003
1% level of significance, one can expect 1 in 100 tests to fail
0.0002 even if the tested sequence is actually random [5].
Then, we tested the final bitstream obtained by extracting
0.0001 bits 1–8 from each measured value. The results were again
satisfactory, with still not enough data to complete the “Uni-
0 versal” test.
0x0 0x4000 0x8000 0xC000 0xFFFF
Fig. 2 shows the “raw” data – relative frequencies of
individual encountered values. Notice that the graph shows
Fig. 2. Relative frequencies of generated “raw” values (cycle counts modulo
216 ). Data in the graph were concatenated from two test runs under somewhat two distinct Gaussian-like distributions. This is due to the fact
different operating conditions; hence, two distinct Gaussian-like distributions that the test data were obtained in two test runs, each under
are present. somewhat different ambient conditions.
Fig. 3 shows the relative frequencies of 8-bit values ex-
0.005 tracted from each 16-bit count. The distribution looks suffi-
ciently uniform now.
0.004
IV. S UGGESTIONS FOR FUTURE WORK
A. Input capture unit
0.003
As mentioned above, the least significant bit of the retrieved
0.002
timer value must be discarded because it is not sufficiently
random. This is due to the fact that the value of Timer/Counter
1 is read in an interrupt handler. To avoid this problem, one
0.001
could connect the Output Compare output of the asynchronous
Timer/Counter 2 unit to the Input Capture input of the
0 Timer/Counter 1 unit. This way, it would be possible to access
0x0 0x40 0x80 0xC4 0xFF
the exact value in the TCNT1 register at the very moment
Fig. 3. Relative frequencies of extracted 8-bit values. These values are then
of timer 2 overflow, avoiding the mentioned drawback and
concatenated to form the random bit stream. Their distribution is sufficiently gaining one additional truly random bit.
uniform. Obviously, this method would require one additional ex-
ternal component – a wire connecting the ICP1 and OCR2A
pins.
III. R ESULTS , TESTS AND DISCUSSION Unfortunately, on the ATmega169 microcontroller, the ICP1
For all tests, we used the NIST sts-2.0b suite described in signal shares a physical pin with the SEG22 signal (LCD
[5]. segment 22). Therefore, on our testing platform, the operation
First, it is necessary to determine which bits of each of the Input Capture unit interfered with the operation of the
measured value are sufficiently random. In order to do that, LCD. So, we did not explore this option further.
we tested bitstreams created by extracting a specific bit from
each measured 16-bit value. The resulting 16 bitstreams were B. Watchdog timer
then tested. As expected, the results show that bits 15–10 are All Atmel AVR microcontrollers are equipped with a watch-
obviously non-random – many P-values are below the 0.01 dog timer. The primary purpose of the watchdog timer is
threshold, and simply looking at the file one finds long runs to reset the microcontroller if the firmware stops working
of 1’s or 0’s. Bit 9 is still non-random (still many P-values are properly. The watchdog timer is essentially a counter that is
below the 0.01 threshold). clocked with an independent on-chip RC oscillator. Software
It is important to realize that bit 0 (the LSB) is also non- must periodically reset the counter; if it fails to do so, it is
random. This is due to the fact that before an interrupt can assumed that the software is not functioning correctly, and a
be serviced, the current instruction must be completed. Most reset is triggered as soon as the counter overflows.
AVR instructions take 1 or 2 clock cycles to complete, making Instead of system reset, some AVR microcontrollers can
the LSB highly dependent on the code being executed. In generate an interrupt when the watchdog timer overflows.
an extreme case, when the code does nothing but wait for Thus, one could utilize the main RC oscillator and the watch-
interrupts in an infinite loop, the microcontroller only executes dog RC oscillator to generate entropy. This method would
RJMP instructions, each of which takes 2 clock cycles, and need no external components besides the microcontroller itself.

V2-494 2010 2nd International Conference on Computer Engineering and Technology [Volume 2]
On the other hand, it needs to be verified whether the two
oscillators are really independent (ruling out any parasitic
dependencies) and how much entropy can be generated. It
would also mean losing the built-in watchdog functionality, at
least while generating random numbers.
We did not test this method yet because the ATmega169
microcontroller in our testing platform does not support watch-
dog interrupts.
C. More testing
As mentioned in Section III, we tested the random number
generator using the NIST sts-2.0b test suite [5]. We also
attempted to test the generator with two other popular test
suites, Diehard [4] and Dieharder [3]. However, these test
suites need a lot of data (10 to 11 megabytes for Diehard,
and up to 2 GB for dieharder), and that will still take some
time to generate using our generator.
In addition, the random number generator should be tested
under a wider range of operating conditions, especially ambi-
ent temperatures.
It also remains to be fully tested whether a shorter sampling
interval (less than the presently used 1 second) may lead
to more entropy. The reasoning behind this idea is that
certain fluctuations in the generated clock signal may average
themselves out over a longer period. Indeed, preliminary
experiments do suggest that a shorter interval may perform
better.
[Volume 2] 2010 2nd International Conference on Computer Engineering and Technology
V. C ONCLUSION
We presented a method of generating true random numbers
on an Atmel AVR microcontroller. The method generates 8
random bits per second. That is not much; however, one
must remember that AVR microcontrollers have no dedicated
facilities for generating true random numbers. We tested the
randomness of the generated bitstream using the NIST sts test
suite, with satisfactory results; however, more testing needs to
be done before making final conclusions about the properties
of the generator.
R EFERENCES
[1] Atmel Corporation. “8-bit AVR Microcontroller with 16K Bytes In-
System Programmable Flash ATmega169P, ATmega169PV.” Document
No. 8018N-AVR-08/09. 2009. [Online]. Available: http://www.atmel.com/
dyn/resources/prod documents/doc8018.pdf
[2] Atmel Corporation. “AVR Butterfly Evaluation Kit – User Guide.” Doc-
ument No. 4271C-AVR-04/05. 2005. [Online]. Available: http://www.
atmel.com/dyn/resources/prod documents/doc4271.pdf
[3] R.G. Brown. “Dieharder: A Random Number Test Suite.” [Online].
Available: http://www.phy.duke.edu/∼ rgb/General/dieharder.php
[4] G. Marsaglia. “The Marsaglia Random Number CDROM, with The
Diehard Battery of Tests of Randomness.” Florida State University. 1985.
[Online]. Available: http://www.stat.fsu.edu/pub/diehard/
[5] A. Rukhin et al. “A Statistical Test Suite for the Validation of Ran-
dom Number Generators and Pseudo Random Number Generators for
Cryptographic Applications.” National Institute of Standards and Tech-
nology. NIST Special Publication 800-22rev1. 2008. [Online]. Available:
http://csrc.nist.gov/groups/ST/toolkit/rng/documentation software.html
[6] U.M. Maurer, “A Universal Statistical Test for Random Bit Generators,”
Journal of Cryptology, vol. 5, no. 2, pp. 89–105, 1992.
V2-495