REN Reg05b0016 Tinymcuap APN 20081028
REN Reg05b0016 Tinymcuap APN 20081028
On April 1st, 2010, NEC Electronics Corporation merged with Renesas Technology
Corporation, and Renesas Electronics Corporation took over all the business of both
companies. Therefore, although the old company name remains in this document, it is a valid
Renesas Electronics document. We appreciate your understanding.
(Note 1) “Renesas Electronics” as used in this document means Renesas Electronics Corporation and also includes its majority-
owned subsidiaries.
(Note 2) “Renesas Electronics product(s)” means any product developed or manufactured by or for Renesas Electronics.
APPLICATION NOTE
Today, as automatic electronic controls systems continue to expand into many diverse applications, the
requirement of reliability and safety are becoming an ever increasing factor in system design.
For example, the introduction of the IEC 60730 safety standard for household appliances requires
manufactures to design automatic electronic controls that ensure safe and reliable operation of their products.
The IEC 60730 standard covers all aspects of product design but Annex H is of key importance for design of
Microcontroller based control systems. This provides three software classifications for automatic electronic
controls:
1. Class A: Control functions, which are not intended to be relied upon for the safety of the equipment.
Examples: Room thermostats, humidity controls, lighting controls, timers, and switches.
2. Class B: Control functions, which are intended to prevent unsafe operation of the controlled equipment.
Examples: Thermal cut-offs and door locks for laundry equipment.
Appliances such as washing machines, dishwashers, dryers, refrigerators, freezers, and Cookers / Stoves will
tend to fall under the classification of Class B.
This Application Note provides guidelines of how to use flexible sample software routines to assist with
compliance with IEC 60730 class B safety standards. Although these routines were developed using IEC
60730 as the basis, they can be implemented in any system for self testing of Renesas MCUs.
The software routines provided for CPU, ROM and RAM testing can be used after reset and also during the
program execution. The end user has the flexibility of how to integrate these routines into their overall system
design.
This section describes CPU tests routines. Reference IEC 60730: 1999+A1:2003 Annex H - Table H.11.12.1
CPU
The CPU test covers testing of General Purpose Registers (GPR), Flag / Status register, Program Counter
(PC) register and other platform specific registers.
The test itself will write test values (like 0x55, 0xAA) into the target register and read it back. It is almost
impossible to access hardware registers of the MCU using ‘C’ language, so it has been decided to write inline
assembly code for individual platform. Hence the source code will be obviously different from one MCU to
another one.
These tests are testing such fundamental aspects of the CPU operation; the API functions do not have return
values to indicate the result of a test. Instead the user of these tests must provide an error handling function
with the following declaration:-
This will be called by the CPU test if an error is detected. It is thought that this function will not return back to
the test code.
The test functions all follow the rules of register preservation following a C function call as specified in the
Renesas tool chain manual. Therefore the user can call these functions like any normal C function without any
additional responsibilities for saving register values beforehand.
The R8C Tiny CPU testing needs to test R0-R3, A0-A1, FB, INTBL, INTBH, USP, ISP, SB and FLG registers.
The source file ‘CPU_Test.c’ provides implementation of CPU test using “C” language with inline assembly for
R8C Tiny. The source file ‘CPU_Test.h’ provides the interface to the function CPU test. The file
‘MisraTypes.h’ includes definitions of MISRA compliant standard data types.
IMPORTANT NOTE: Please keep the "Optimisation" option "OFF" for the ‘CPU_Test.c’ file.
Syntax
void CPU_TestAll(void)
Description
Runs through all the tests detailed below in the following order:-
1. TestGPRs
2. TestIntRegs
3. TestStackRegs
4. TestPCReg
5. TestFlagReg
It is the calling function’s responsibility to ensure no interrupts occur during this test.
If an error is detected then external function ‘ErrorHandler’ will be called.
See the individual tests for a full description.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Description
This function provides CPU General Purpose Registers Testing to test R0, R1, R2, R3, A0, A1 & FB in Register
Bank0 and Bank1.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void TestIntRegs(void)
Description
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
void TestStackRegs(void)
Description
This function provides Stack (USP, ISP) and Static Base (SB) Registers testing.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void TestFlagReg(void)
Description
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Description
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
bool_t TRUE - Success, FALSE - Fail
The M16C Tiny and R8C Tiny devices have an identical set of CPU registers.
Please refer to §1.1.1 on page 5 for details of the CPU tests.
The SH Tiny CPU Tests consist of the files cpu_test_sh7124.c and cpu_test_sh7124.h. Despite it being a ‘C’
file and the function APIs being ‘C’ the majority of the code is written in assembly.
The API allows a number of tests to be selected individually but it also provides a function called
‘CPU_Test_ALL’ which will go through all of the individual tests in sequence. It is recommended that interrupts
are disabled before calling any of these tests. However it is only test ‘CPU_Test_GBR_VBR_SR’ and
consequentially ‘CPU_Test_All’, where it is imperative that no interrupts occur.
The read/write bits of the following 32 bit registers are tested using a simple write then read back test using
values h’AAAAAAAA and then h’55555555.
Syntax
void CPU_Test_ALL(void)
Description
Runs through all the tests detailed below in the following order:-
1. CPU_Test_R0toR7
2. CPU_Test_R8toR15
3. CPU_Test_MACH_MACL_PR
4. CPU_Test_GBR_VBR_SR
5. CPU_Test_PC
It is the calling functions responsibility to ensure no interrupts occur during this test.
If an error is detected then external function CPU_Test_ErrorHandler will be called.
See the individual tests for a full description.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void CPU_Test_R0toR7(void)
Description
The rules for register preservation state that registers R0 to R7 are free for a function to use without preserving
their values. Hence this function does not preserve the values of registers R0 to R7.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
The rules for register preservation state that registers R8 to R15 must be preserved by a function.
Hence this function preserves the values of R8 to R15
It assumes registers RO to R7 are working to achieve this.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void CPU_Test_MACH_MACL_PR (void)
Description
It assumes registers RO to R7 are working. Register values of MACH, MACL and PR are preserved.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Description
It is the calling functions responsibility to ensure no interrupts occur during this test.
It assumes registers RO to R7 are working. Register values of GBR, VBR and SR are preserved.
For SR not all bits are read/write so other test values have been chosen. Also to avoid this function accidentally
allowing an interrupt to occur the I bits of the SR are not tested.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void CPU_Test_PC(void)
Description
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
The H8 Tiny CPU testing needs to test ER0-ER7, PC and CCR (Condition Code Register or Status) registers.
The source file ‘CPU_Test.c’ provides implementation of CPU test using “C” language with inline assembly for
H8 Tiny. The source file ‘CPU_Test.h’ provides interface to the function CPU test. The file ‘MisraTypes.h’
includes definitions of MISRA compliant standard data types.
IMPORTANT NOTE: Please keep "Optimisation" option "OFF" for the ‘CPU_Test.c’ file.
Syntax
void CPU_TestAll(void)
Description
Runs through all the tests detailed below in the following order:-
6. CPU_Test_ER0toER7
7. CPU_Test_SR
8. CPU_Test_PC
It is the calling function’s responsibility to ensure no interrupts occur during this test.
If an error is detected then external function CPU_Test_ErrorHandler will be called.
See the individual tests for a full description.
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void CPU_Test_ER0toER7 (void)
Description
This function provides CPU General Purpose Registers Testing to test ER0 to ER7.
For each of register:-
1. Store original contents of the register
2. Write H'55555555 to the register.
3. Read and check the value is are equal.
4. Write H'AAAAAAAA to the register.
5. Read and check the value is are equal.
6. Restore original contents of the register
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void CPU_Test_PC (void)
Description
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
Syntax
void CPU_Test_SR (void)
Description
Input Parameters
NONE N/A
Output Parameters
NONE N/A
Return Values
NONE N/A
CRC is a fault / error control technique which generates a single word or checksum to represent the contents of
memory.
A CRC checksum is the remainder of a binary division with no bit carry (XOR used instead of subtraction), of
the message bit stream, by a predefined (short) bit stream of length n + 1, which represents the coefficients of
a polynomial with degree n. Before the division, n zeros are appended to the message stream.
During the memory self test the same algorithm generates another checksum, which is compared with the
saved checksum. The technique recognises all one-bit errors and a high percentage of multi-bit errors.
CRCs are popular because they are simple to implement in binary hardware and are easy to analyse
mathematically.
1.2.1 CRC16-CCITT
• Width = 16 bits
• Truncated polynomial = 0x1021
• Initial value = 0xFFFF
• Input data is NOT reflected
• Output CRC is NOT reflected
• No XOR is performed on the output CRC
The polynomial for the CRC16-CCITT is 0x1021 (x16 + x12 + x5 + 1). The initial value for the CRC16-CCITT is
0xFFFF. This value is known as the “seed” value.
The CRC value can be calculated in software using two methods: Look-up table, and bit shifting.
The look-up table method requires more ROM space (512 bytes for 256 16-bit words) than the bit shifting
method but uses fewer CPU clock cycles.
The source file ‘CRC16-CCITT.c’ provides implementation of CRC16_CCITT using the “C” programming
language. The source file ‘CRC16-CCITT.h’ provides an interface to the function CRC16_CCITT. The file
‘MisraTypes.h’ includes definitions of MISRA-compliant standard data types.
Syntax
uint16_t CRC16_CCITT(const uint8_t* const pui8_DataBuf, const uint32_t ui32_DataBufSize)
Description
This function provides an interface to calculate the CRC16–CCITT using the polynomial (x16 + x12 + x5 + 1).
Input Parameters
const uint32_t ui32_DataBufSize Length of the data buffer / memory. This should be a 32-bit constant.
Output Parameters
NONE N/A
Return Values
uint16_t 16-bit calculated CRC16 value.
March Tests are a family of tests that are well recognised as an effective way of testing RAM.
A March test consists of a finite sequence of March elements, while a March element is a finite sequence of
operations applied to every cell in the memory array before proceeding to the next cell.
In general the more March elements the algorithm consists of the better will be its fault coverage but at the
expense of a slower execution time.
The algorithms themselves are destructive (they do not preserve the current RAM values) but the supplied test
functions provide a non-destructive option so that memory contents can be preserved. This is achieved by
copying the memory to a supplied buffer before running the actual algorithm and then restoring the memory
from the buffer at the end of the test.
The following section introduces the specific March Tests that have been implemented. Following that is the
specification of the software APIs.
1.3.1.1 March C
The March C algorithm (van de Goor 1991) consists of 6 March elements with a total of 11 operations. It
detects the following faults:
The March X algorithm consists of 4 March elements with a total of 6 operations. It detects the following faults:
The March X Word-Oriented Memory (WOM) algorithm has been created from a standard March X algorithm in
two stages. First the standard March X is converted from using a single bit data pattern to using a data pattern
equal to the memory access width. At this stage the test is primarily detecting inter word faults including
Address Decoder faults. The second stage is to add an additional two March elements. The first using a data
pattern of alternating high/low bits then the second using the inverse. The addition of these elements is to
detect intra-word coupling faults.
The following implementations of the test are available depending upon the required memory access width.
The source is written in ANSI C and uses MISRA-compliant data types as declared in file MisraTypes.h.
Declaration
bool_t RamTest_March_C_XXBit(const uint32_t ui32_StartAddr,
const uint32_t ui32_EndAddr,
uintXX_t* const puiXX_RAMSafe);
ui32_StartAddr
The address of the first word of RAM to be tested. This must be aligned with the
selected memory access width.
ui32_EndAddr
The address of the last word of RAM to be tested. This must be aligned with the
selected memory access width and be a value greater or equal to ui32_StartAddr.
The following implementations of the test are available depending upon the required memory access width.
The source is written in ANSI C and uses MISRA-compliant data types as declared in file MisraTypes.h.
Declaration
bool_t RamTest_March_X_XXBit(const uint32_t ui32_StartAddr,
const uint32_t ui32_EndAddr,
uintXX_t* const puiXX_RAMSafe);
ui32_StartAddr
Address of the first word of RAM to be tested. This must be aligned with the selected
memory access width.
ui32_EndAddr
Address of the last word of RAM to be tested. This must be aligned with the selected
memory access width and be a value greater or equal to ui32_StartAddr.
The following implementations of the test are available depending upon the required memory access width.
The source is written in ANSI C and uses MISRA-compliant data types as declared in file MisraTypes.h.
Declaration
bool_t RamTest_March_X_WOM_XXBit(const uint32_t ui32_StartAddr,
const uint32_t ui32_EndAddr,
uintXX_t* const puiXX_RAMSafe);
ui32_StartAddr
Address of the first word of RAM to be tested. This must be aligned with the selected
memory access width.
ui32_EndAddr
Address of the last word of RAM to be tested. This must be aligned with the selected
memory access width and be a value greater or equal to ui32_StartAddr.
The tests were run with optimisation set for none, minimal size or maximum speed.
The reduced-memory CRC algorithms and the March X algorithms were developed in a second phase
(referred to as Phase 2). The SH and H8 tool chains had been updated and so there are two sets of settings for
these tool chains.
2.1.1.1 No optimisation
Compiler: -c -finfo -dir "$(CONFIGDIR)" -Wall -R8C25 -O5OA
2.2.1.1 No optimisation
2.2.2.1 No optimisation
Compiler: -cpu=sh2
-include="$(WORKSPDIR)\..\..\..\SharedTests\ROM","$(WORKSPDIR)\..\..\..\SharedTests"
-object="$(CONFIGDIR)\$(FILELEAF).obj" -optimize=0 -noinline -gbr=auto -chgincpath -errorpath
-global_volatile=0 -opt_range=all -infinite_loop=0 -del_vacant_loop=0 -struct_alloc=1 -nologo
Compiler: -cpu=sh2
-include="$(WORKSPDIR)\..\..\..\SharedTests\ROM","$(WORKSPDIR)\..\..\..\SharedTests"
-object="$(CONFIGDIR)\$(FILELEAF).obj" -size -noinline -gbr=auto -chgincpath -errorpath
-global_volatile=0 -opt_range=all -infinite_loop=0 -del_vacant_loop=0 -struct_alloc=1 -nologo
Compiler: -cpu=sh2
-include="$(WORKSPDIR)\..\..\..\SharedTests\ROM","$(WORKSPDIR)\..\..\..\SharedTests"
-object="$(CONFIGDIR)\$(FILELEAF).obj" -speed -noinline -gbr=auto -chgincpath -errorpath
-global_volatile=0 -opt_range=all -infinite_loop=0 -del_vacant_loop=0 -struct_alloc=1 -nologo
2.3.1.1 No optimisation
Compiler: -c -finfo -dir "$(CONFIGDIR)" -fFP -Wall -WMT -WNC -WNP -WNS -WNUA -WNUF -WNWS -WSAL
-WSAW -Wstdout -WUM -WUP –WUV
Compiler: -c -finfo -dir "$(CONFIGDIR)" -O5 -OR -O5OA -OGJ -OSA -fCE -fD32 -fFP -fNA -fNC -fSA -fUD
-Wall -WMT -WNC -WNP -WNS -WNUA -WNUF -WNWS -WSAL –WSAW
Compiler: -c -finfo -dir "$(CONFIGDIR)" -O5 -OS -OFFTI -OGJ -OSA -OSTI -OLU=10 -fCE -fD32 -fFP -fNC
-fSA -fUD -Wall -WMT -WNC -WNP -WNS -WNUA -WNUF -WNWS
2.4.1.1 No optimisation
2.4.2.1 No optimisation
The function execution time was measured using the pulse-width measurement function on a TDS3034B
digital oscilloscope. A port pin was set low at function entry and high at function exit.
The clock cycle count was calculated using the following equation:
For clarity the clock cycle counts have been scaled down by 1000.
3.1.2.1 March C
Table 13: R8C/Tiny test results (CRC16-CCITT with small lookup table)
Optimisation
Measurement None Size Speed
Code size / bytes 177 152 152
Constant size / bytes 32 32 32
Stack usage / bytes 15 14 14
1 kbytes 216 224 224
16 kbytes 3480 3580 3580
Clock cycle count (/ 1000)
64 kbytes 13520 13840 13840
128 kbytes 27000 27600 27600
1 kbytes 10.8 11.2 11.2
16 kbytes 174 179 179
Time Measured (ms)
64 kbytes 676 692 692
128 kbytes 1350 1380 1380
Table 14: R8C/Tiny test results (CRC16 with small lookup table)
Optimisation
Measurement None Size Speed
Code size / bytes 166 178 144
Constant size / bytes 32 32 32
Stack usage / bytes 15 11 11
1 kbytes 252 224 224
16 kbytes 4040 3580 3580
Clock cycle count (/ 1000)
64 kbytes 15640 13840 13840
128 kbytes 31200 27600 27600
1 kbytes 12.6 11.2 11.2
16 kbytes 202 179 179
Time Measured (ms)
64 kbytes 782 692 692
128 kbytes 1560 1380 1380
3.2.2.1 March C
Table 24: SH/Tiny test results (CRC16-CCITT with small lookup table)
Optimisation
Measurement None Size Speed
Code size / bytes 288 180 180
Constant size / bytes 32 32 32
Stack usage / bytes 44 24 20
1 kbytes 112 64 64
16 kbytes 1848 1032 984
Clock cycle count (/ 1000)
64 kbytes 7400 4120 3944
128 kbytes 14800 8240 7880
1 kbytes 2.8 1.6 1.6
16 kbytes 46.2 25.8 24.6
Time Measured (ms)
64 kbytes 185 103 98.6
128 kbytes 370 206 197
Table 25: SH/Tiny test results (CRC16 with small lookup table)
Optimisation
Measurement None Size Speed
Code size / bytes 208 120 128
Constant size / bytes 32 32 32
Stack usage / bytes 32 8 12
1 kbytes 88 48 40
16 kbytes 1400 752 720
Clock cycle count (/ 1000)
64 kbytes 5560 3016 2880
128 kbytes 11120 6040 5760
1 kbytes 2.2 1.2 1.0
16 kbytes 35 18.8 18.0
Time Measured (ms)
64 kbytes 139 75.4 72.0
128 kbytes 278 151 144
3.3.2.1 March C
Table 35: M16C/Tiny test results (CRC16-CCITT using the on-chip CRC module)
Optimisation
Measurement None Size Speed
Code size / bytes 95 74 74
Constant size / bytes 0 0 0
Stack usage / bytes 19 19 19
1 kbytes 48 48 44
16 kbytes 770 736 736
Clock cycle count (/ 1000)
64 kbytes 2818 2684 2684
128 kbytes 5636 5376 5376
1 kbytes 2.40 2.41 2.21
16 kbytes 38.50 36.80 36.80
Time Measured (ms)
64 kbytes 140.90 134.20 134.20
128 kbytes 281.80 268.80 268.80
Table 36: M16C/Tiny test results (CRC16-CCITT with small lookup table)
Optimisation
Measurement None Size Speed
Code size / bytes 200 145 145
Constant size / bytes 32 32 32
Stack usage / bytes 17 14 14
1 kbytes 192 156 156
16 kbytes 2888 2500 2500
Clock cycle count (/ 1000)
64 kbytes 11900 9560 9560
128 kbytes 23800 19140 19120
1 kbytes 9.6 7.8 7.8
16 kbytes 144.4 125 125
Time Measured (ms)
64 kbytes 595 478 478
128 kbytes 1190 957 956
Table 37: M16C/Tiny test results (CRC16 with small lookup table)
Optimisation
Measurement None Size Speed
Code size / bytes 188 147 147
Constant size / bytes 32 32 32
Stack usage / bytes 17 17 17
1 kbytes 180 140 140
16 kbytes 2880 2240 2240
Clock cycle count (/ 1000)
64 kbytes 11080 8660 8660
128 kbytes 22200 17320 17320
1 kbytes 9 7 7
16 kbytes 144 112 112
Time Measured (ms)
64 kbytes 554 433 433
128 kbytes 1110 866 866
3.4.2.1 March C
The block count was capped at 56k bytes as this is the maximum supported by the H8/3687 group.
Table 47: H8/Tiny test results (CRC16-CCITT with small lookup table)
Optimisation
Measurement None Size Speed
Code size / bytes 334 170 198
Constant size / bytes 32 32 32
Stack usage / bytes 32 20 12
1 kbytes 446 236 166
Clock cycle count (/ 1000) 16 kbytes 7133 3797 2654
56 kbytes 25068 13308 9290
1 kbytes 24.2 12.8 9.0
Time Measured (ms) 16 kbytes 387 206 144
56 kbytes 1360 722 504
The following tables compare graphically the RAM and ROM test results for each MCU family.
16
14
R8C Tiny
12 M16C Tiny
H8 Tiny
10 SH Tiny
0
March C March C March X March X March X WOM March X WOM
small large small large small large
180
R8C Tiny
160 M16C Tiny
H8 Tiny
140
SH Tiny
120
100
80
60
40
20
0
CRC16-CCITT CRC16-CCITT CRC16-CCITT CRC16 with
using a static table using bit shifting with small lookup table small lookup table
Inquiries
http://www.renesas.com/inquiry
All trademarks and registered trademarks are the property of their respective owners.