AN4772, IEC 60730 Safety Routines for the DSC …19 IEC 60730 Safety Routines for the DSC 56800EX...

Freescale SemiconductorApplication Note

Document Number: AN4772Rev. 0, 8/2013

Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. DSC 56800EX core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. DSC registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34. DSC memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45. DSC safety routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56. Computer operating properly watchdog . . . . . . . . . . . . . . . . . . . . 57. COP timeout test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

7.1.COP test rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77.2.COP test principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

8. CPU register self-test for "stuck at" faults . . . . . . . . . . . . . . . . . 108.1.16, 36-bits data registers, pointer, offset andmodifier registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108.2.Stack pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118.3.Shadow registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118.4.Status register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118.5.Loop counter, loop address and HW stack registers . . . . . . 118.6.Secondary loop counter, loop address, andHW stack registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118.7.Program counter (PC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

9. March X, C, XA5 RAM tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 129.1.March X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129.2.MARCH XA5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139.3.March C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139.4.Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

10. CRC Test of flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610.1.CRC Linker feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1610.2.CRC Application feature . . . . . . . . . . . . . . . . . . . . . . . . . . 17

11. Clock test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1811.1.QuadTimerA0/A1 feature . . . . . . . . . . . . . . . . . . . . . . . . . . 18

12. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

IEC 60730 Safety Routines for the DSC 56800EX CoreBy: Pavel Rech

1 IntroductionThe purpose of the IEC 60730 safety routines for household appliances is to ensure the safe and reliable operation of their products. Freescale has developed safety routines to help manufacturers of automatic control systems in the large appliance and industrial control market meet the IEC 60730 standard class B.

Typical applications for Freescale safety routines are: cooking products, boiler and heater control, dishwashers, household actuators, dryers, motor control, refrigerators and freezers, elevators, vacuum cleaners, and automatic gates and washing machines. The routines’ task is to check the proper functioning of the registers, RAM, and flash memory. These routines have been developed for the 16-bit digital signal controller (DSC).

Freescale also offers the Watchdog test (with windowing feature only for DSC MC56F82xxx devices) and clock test (only for DSC MC56F82xxx devices). These tests should be done before running the main application algorithm.

© Freescale Semiconductor, Inc., 2013. All rights reserved.

DSC 56800EX core

There are three classes of IEC 60730:

• Class A: Not intended to be relied upon for the safety of the equipment

• Class B: To prevent unsafe operation of the controlled equipment

• Class C: To prevent special hazards

The following table indicates the requirements for each routine considering the given class. All tests described by this application note are outlined in red in this table.

2 DSC 56800EX coreThe DSP56800EX core represents the next step in the evolution of Freescale's families of DSCs. The DSP56800EX core extends the capabilities of the DSP56800E core architecture.

The DSP56800EX core has all DSP56800E core features and new enhancements, including:

• 32 x 32 bits multiply and MAC operations

• All registers in the Address Generation Unit (AGU) have shadow registers that effectively reduce the context save and restore time during exception processing, simultaneously reducing latency

• Bit-reverse addressing mode supporting Fast Fourier Transform (FFT)

• New bit manipulation instruction (BFSC) that integrates test-bit field and set/clear-bit field operations into a single instruction

Both cores can be characterized by:

• Low cost

• High-power computing

• Combining DSC power and parallelism with MCU-like programming simplicity

The following text describes the DSC registers, memory, and watchdog, because their functionality is checked using safety routines.

Table 1. IEC 60730 classes and tests

Test IEC 60730 Class B IEC 60730 Class C

IEC 60730 Periodic Test

8-bit S08 16-bit DSC568XXX

32-bit MCF51xx 8-bit S08 16-bit DSC568xxx

32-bit MCF51xx

CPU Register Test

Stuck at Stuck at Stuck at Walkpat Walkpat Walkpat

CPU Instruction Test

NA NA NA CPU Instr. Test CPU Instr. Test CPU Instr. Test

RAM Test March C, X March C March C Walkpat Walkpat Walkpat

Flash Test CRC 16-bit CRC 16-bit CRC 16-bit CRC 16-bit CRC 16-bit CRC 16-bit

Watchdog Test Timeout and Reset

Timeout and Reset

Timeout and Reset

Timeout and Reset

Timeout and Reset

Timeout and Reset

IEC 60730 Safety Routines for the DSC 56800EX Core, Rev. 0

Freescale Semiconductor2

DSC registers

3 DSC registersThe registers in the core that are considered part of the core programming model are shown in Figure 1. Registers for on-chip peripherals are mapped into a 64-location block of data memory.

The MC56F84xxx and MC56F82xxx CPUs consist of these registers:

• Four 36-bit data registers (A, B, C, D)

• Three 16-bit data registers

• Six 24-bit registers with two shadow registers

• One 24-bit offset register with a shadow register

• One 16-bit secondary offset register with a shadow register

• One 16-bit modifier register with a shadow register

• One 24-bit stack pointer register

• 21-bit program counter

• Status register

• Two 24-bit loop address registers

• Two 24-bit hardware stack registers

• Two 16-bit loop counter registers


Freescale Semiconductor 3

DSC memory

Figure 1. DSC registers

4 DSC memoryThe DSC core has a dual Harvard architecture with separate program and data memory spaces, shown in the following. This architecture allows simultaneous access to program and data memory. The data memory interface also supports two simultaneous read operations, enabling simultaneous access for up to three memories.



DSC safety routines

Figure 2. DSC memory

5 DSC safety routinesThe DSC safety routines consist of the five following tests:

• Watchdog timeout test (with windowing feature available only in MC56F82xxx)

• CPU Register self test for "stuck at" faults

• March X, C, XA5 RAM Tests

• CRC test of flash

• Clock test (available only for MC56F82xxx)

All of these tests can run automatically by using the self-test.

6 Computer operating properly watchdogThe computer operating properly (COP) module is used to help software recover from runaway code. The COP provides an enhanced safety feature for ensuring that application software is working in a predetermined and understood manner.

The COP is a free-running down counter that, once enabled, is designed to generate a reset upon reaching zero. Software must periodically service the COP in order to reload the counter and prevent a reset.

The COP includes the following features:



Computer operating properly watchdog

• Programmable prescaler

• Programmable timeout period

• Programmable interrupt timing that can occur for any count less than the TIMEOUT value

• Programmable wait and stop operations

• COP timer is disabled while the DSC is in debug mode

• Causes loss of reference reset 128 cycles after the loss of the reference clock to the PLL is detected

• Optional clock source for the counter:

– Relaxation oscillator output (ROSC)

– Crystal oscillator output (COSC)

– IP bus clock is used to clock the counter

– Low-speed oscillator is used to clock the counter

The device MC56F82xxx has the COP windowing mode, but the device MC56F84xxx includes only pure COP without the windowing mode. It enables the use of programmable window timing, which ensures the COP service routine doesn't occur too early. If the COP counter register has a higher value than the WINDOW register and a service occurs, the COP window reset is generated.

By placing "COP service routine" within the software at known time intervals, the COP will not timeout and the code will execute normally. If the software code gets stuck or loops, the WDOG will reset the DSC, allowing the application to be placed in a known, safe condition. The COP has a choice of four clock sources (Relaxation oscillator, Crystal oscillator, IP bus clock and Low-speed oscillator). By default, it takes the clock from the internal Relaxation oscillator (8 MHz) which can also feed the CPU. The COP should not have the same clock as the core, because in the case of a clock failure, there is no way to recognize it.

The following figure shows the watchdog module block diagram. There are four watchdog clock sources and three reset outputs. The following figure explains the watchdog interconnection.



COP timeout test

Figure 3. Watchdog module block diagram

7 COP timeout testFor IEC 60730 applications, the COP clock source should be different from the core clock source. For example, if the core is supplied from the relaxation oscillator, the COP should be fed from the crystal oscillator to ensure the COP is working independently from the core.

For systems that comply with IEC 60730 and utilize an independent time-based COP, it is good practice, prior to starting the application, to test the COP to timeout and ensure that, if a failure occurs in the system, the COP will still function as expected.

7.1 COP test rulesThe COP test works according to the following rules, as shown in Figure 4



COP timeout test

• The IEC60730B_DSC_OscilInit function is used after each reset (internal or external). This function initially sets up the OCCS to properly run, activate all oscillators, and set up the COP and system clock sources as defined in the macro for the COP and for system clocks.

• The IEC60730B_DSC_Watchdog function sets the COP_TOUT register to a 7 ms time interval according to the selected COP input clock frequency. The IEC60730B_DSC_Watchdog function measures the time to the COP timeout reset using the QuadTimer, which starts immediately after the COP timer. The COP reset is expected and the measured time from the QuadTimer is stored in the register and keeps its value after the COP reset. The COP is turned off and the reset status register SIM_RSTAT is read after reset, thus creating these possibilites:

7.2 COP test principleIf a COP reset does not occur:

• The application continues with the IEC60730B_DSC_Watchdog test routine. The COP timeout register COP_TOUT is set to countdown with 7 milliseconds, and the clock is enabled for the timer TMRA0 by the SIM_PCE0 register. The timer compare register TMRA0 is set to its maximum of 65535, and stops at this value. The TMRA0 is then set to the frequency of the IPBUS clock, and will count up rising edges for comparison. The COP start, which is indicated by the variable COP_TEST, stored at the SIM_SCR0 register, can be cleared only by a start up reset. The type of COP reset depends on the device selected by the macro in the header IEC60730B_DSC_setting. In the case that device 56F82xxx is chosen, the first test reset is the window reset, then the timeout reset. Only the timeout reset is executed (COP does not have a window feature) in the case that device 56F84xxx is used. The window COP feature is tested by setting the COP_WINDOW value to half of the COP_TOUT register value. The COP service routine is complete after the COP is turned on and the delay loop is finished. This should cause the COP window reset. If the COP window reset passed, the COP timeout reset is executed when the next CopTest function is used.

If there is a loss of a reference event:

• The application goes to the IEC60730B_DSC_WatchdogError function. The function then returns the Loss of COP reference error.

If there is a COP window event:

• It will check the variable COP_TEST, stored in the SIM_SCR0 register. If it is not set to 2, there will be an application error and it will finish with an error. If it is set to 2, the test will pass and the COP timeout test can start. The COP is then turned on and the application begins the endless loop, copying the TMRA counter register TMRA0_CNTR to the variable COP_TIMER_COUNTER, stored at the SIM_SCR0 register. This can be cleared only by a power-on reset. The system will then be waiting for the COP timeout reset and the COP_TIMER_COUNTER is periodically checked. If its value reaches the maximum permitted counter value, the application stops the watchdog and finishes with an error.

If there is a COP timeout event:

• The variable COP_TEST will be checked. If it is not set to 1, there will be an application error and it will finish with an error. If it is set, then the test will pass as OK. If the time was shorter or longer than permitted, it will finish with an error.



COP timeout test

The routine IEC60730B_DSC_CopTest includes these COP constants:

• COP_TEST_PASS 0 – COP test passed

• COP_TEST_TIMEOUT_RESET 1 – COP timeout test is executed

• COP_TEST_WINDOW_TIMEOUT_RESET 2 – COP window test is executed

• COP_TEST_NO_TEST_DONE 4 – no COP test is executed

Figure 4. Watchdog test diagram

The routine IEC60730B_DSC_CopTest returns an error code number:



CPU register self-test for "stuck at" faults

• COP_OK (0) – test passed OK

• COP_PERIOD_FAIL (1) – COP reset timeout is not within the permitted period deviation window

• COP_APPLICATION_FAIL (2) – COP timeout reset occurred during the application lifetime

• COP_APPLICATION_FAIL_WINDOW (4) – COP window reset occurred during the application lifetime

• COP_LOSS_OF_REFERENCE (8) – COP loss of reference error

• COP_COUNT_ERROR (16) – COP didn't perform timeout reset until the max permitted time interval reset until the maximum permitted period

• COP_COUNT_ERROR_WINDOW_TEST (32) – COP didn't perform window reset until the max permitted time interval

8 CPU register self-test for "stuck at" faultsA periodic self-test has been designed to test all previously mentioned registers. The self-test is expected to be used immediately after any reset of the MCU, but can also be used in application as long as interrupts are disabled and the stack pointer is reset to the top of the stack.

The two test forms are the large data model (LDM) and small data model (SDM). The right form should be chosen by defining the macro as either LDM or SDM together with device type in the IEC60730B_DSC_RegisterTest.h file.

Each CPU Register and the Program Counter are checked for "stuck at" by using the 0x55 and 0xAA bit patterns.

The registers are first tested for the 0x55 value and then for the 0xAA value. Doing this tests all bits for 0 and 1 conditions. If an error is found, it goes through the error routine and returns with the particular register error code.

The DSC has a lot of registers, though not all of them are used in the application. Therefore, several test routines have been created. The user can access the routines of the used registers. There are also rules that must be followed:

• All routines use the Y register so the IEC60730B_DSC_DataRegisterTest function must be tested.

• The status register is used to determine if the register works and must be tested.

• If the stack pointer test is used, the IEC60730B_DSC_PointerRegisterTest must be tested.

• If the loop registers are tested, the IEC60730B_DSC_StackPointerRegisterTest must be tested.

• If the program counter is tested, the IEC60730B_DSC_StackPointerRegisterTest must be tested.

• The Program Counter is always used and should be tested.

• The Stack Pointer is always used and should be tested.

8.1 16, 36-bits data registers, pointer, offset and modifier registersThe 16-bit (24-bit or 36-bit) data registers are checked by writing 0x5555 (0x55555555 or 0x555555) and the value should be compared with an immediate value (data from the program memory of the DSC). The register value is then loaded with a "complemented" value of 0xAAAA (0xAAAAAAAA or



CPU register self-test for "stuck at" faults

0xAAAAAA) and verified against the immediate value of 0xAAAA. The 24-bit or 36-bit registers are then divided into three parts and compared using the 16-bit registers Y0 and Y1.

8.2 Stack pointerThe Stack Pointer value is first stored into the R0 register and loaded with the value 0x555555 using the R1 register. This SP value is then stored in the R2 register and then in the Y register. The Y0 is then compared with an immediate value of 0x5555, and the Y1 is compared with 0x55. This process is repeated using the value of 0xAAAAAA, and the SP is checked for this complemented value. Afterwards, the original SP value is copied back from R0 to SP. If the SP failure is detected, the processor is forced to reset because any attempt to return could be unreliable.

8.3 Shadow registersThe DSC contains four shadow registers. These registers are mirrored with the R0, R1, N and M01 registers. They are accessed the same way as the basic registers, but the DSC must first be switched to a different bank using the swap instruction.

8.4 Status registerThe Status register maintains condition flags depending on certain circumstances. These flags occupy the lower 8 bits, and the upper 8 bits are dedicated to the DSC settings.The register first clears the lower 8 bits, then loads these lower bits with 0x55. The SR register is then copied into the Y0 register, where the upper 8 bits are cleared, and its value is compared with 0x55. The process is then repeated using the 0xAA value.

8.5 Loop counter, loop address and HW stack registersThe 16-bit LC register can by accessed using the Moveu instruction, and checked by writing 0x5555 via the Y0 register. This is then copied into the Y1 register, and the Y1 register is compared against an immediate value of 0x5555. The process is then repeated with the 0xAAAA pattern.

The 24-bit LA and HWS registers are accessible only through the Stack Pointer. This means the value of 0x55555555 is loaded into the Y register which is pushed on the stack, then popped into the LA and HWS registers. The values of the LA and HWS registers are pushed on the stack again and popped into the Y register. The register Y0 is compared against the value of 0x5555, and Y1, against 0x55. The process is repeated with the 0xAAAAAA pattern.

8.6 Secondary loop counter, loop address, and HW stack registersThe DSC has LC2, LA2, and HWS1 registers. These registers are not accessible by using any instruction. To test them, load the LC, LA, and HWS registers with the pattern 0x5555 or 0x555555, then nest a do loop. If the loop is nested, the LC, LA, and HWS registers will be copied to the registers LC2, LA2, and HWS1. When the loop ends, the LC2, LA2, and HWS1 registers will be copied back to the LC, LA, and HWS registers. The registers are then copied in the Y register into Y0 and Y1. The process is repeated with the patterns 0xAAAA and 0xAAAAAA.



March X, C, XA5 RAM tests

8.7 Program counter (PC)To test the PC for "stuck at" faults, two small subroutines are placed at addresses $5555 and $AAAA for the SDM, and at addresses $AAAA and $1555 for the LDM (because the device has up to 256 KB (128 KW) program flash memory). Using the linker command file, these routines are forced to reside at the desired addresses. The linker command file divides the utilizable portion of the memory into three blocks of the small or large data model used.

First, the CPU executes a JSR to $0x005555 for the SDM or $0x00AAAA for the LDM. The routine at this address then uses the subroutine $0x00AAAA for the SDM or $0x015555 for the LDM. This routine then uses TestRoutineFinal. Note that with every JSR, the stack will be getting a return address and the status register will be pushed onto it. Within the TestRoutineFinal routine, the stack is examined to verify that the PC is set to 0x005555, or 0x00AAAA in the case of the SDM, and 0x00AAAA or 0x015555 in the case of the LDM, verifying there are no "stuck at" faults.

The TestRoutineFinal reads the long value from the stack pointer. The lower 16 bits are the program counter returning address, and the remaining 5 bits are stored in the upper 16 bits (the SR register): the bits 16:20. That's why these bits must be filtered and then checked for 0, because the program memory is limited to 0x40000 for the MC56F84xxx and 0x10000 for the MC56F82xxx. If an SP failure is detected, the processor is forced to reset because any attempt to return could be unreliable.

9 March X, C, XA5 RAM testsFor RAM testing, three different algorithms are implemented, as described in the following sections.

9.1 March XThe March X test pattern is an industry standard for checking RAM memory arrays for "address decoder" and "stuck at" faults. The mechanism of the March X pattern is described below:

1. Write all zeros to the array

2. Start at the lowest address, read zeros, write ones and increment the array address

3. Start at the highest address, read ones, write zeros and decrement the array address

4. Read all zeros from the array




Figure 5. March X

9.2 MARCH XA5The March XA5 pattern differs from the March X only in the actual data stored at each subsequent byte.

1. March X – Write all bytes to 0x00March XA5 –Write all bytes as 0xAA

2. March X – Read 0x00, write 0xFFMarch XA5 – Read 0xAA, write 0x55

3. March X – Read 0xFF, write 0x00March XA5 – Read 0x55, write 0xAA

4. March X – Read all bytes as 0x00March XA5 – Read all bytes as 0xAA

9.3 March CThe March C test pattern (van der Goor, 1991) is an industry standard for checking RAM memory arrays for ‘d.c. faults’. The mechanism of the March C pattern is described below:

1. Write all zeros to array

2. Start at lowest address, read zeros, write ones, and increment the array address

3. Start at lowest address, read ones, write zeros, and increment the array address

4. Start at highest address, read zeros, write ones, and decrement the array address

5. Start at highest address, read ones, write zeros, and decrement the array address

6. Read all zeros from array




Figure 6. March C

All March pattern test sequences are destructive in their nature. To make a transparent March pattern, the RAM is partitioned into four segments, where segment 4 is used as a redundant area for copying other segments temporarily, while the March X test pattern is used on them.

The RAM on the MC56F84xxx has 16 k words and the MC56F82xxx has 4 k words. Therefore, there are four segments of 4 k words (MC56F84xxx) and 1024 words (MC56F82xxx).

9.4 FunctionsThe routines are written in assembler to be as efficient as possible. The application contains several functions that are important for memory tests:

StackCheck This function's purpose is to check if the stack pointer is not found in the tested block of memory. If it is found in the tested block of memory, it is moved to the backup block of memory. The inputs of the function are the pointer to the beginning of the tested block, the pointer to the beginning of the backup block of memory, and the length of the tested memory block. If the SP is within the tested block, it is copied to the backup block with the same offset from the beginning of the block. If this is the case,




the function returns the value to 1. If the stack pointer is not in the tested block of memory, it returns to 0.

CopyMem This function copies the memory block from the source location, defined by the first pointer, to the destination location defined by the second pointer. The length of the copied block is defined by the third argument.

MarchX, MarchXA5, MarchC This function applies the corresponding MarchX, MarchXA5, or MarchC algorithms on the memory, which begins at the position the input pointer points to with the length of the block defined by the second argument. If there is no error, the function returns to 0. Otherwise, the function is 1.

IEC60730B_DSC_RamTest This function carries out the RAM test without damaging the data in the RAM. The memory is divided into four equal blocks, where the fourth block is used to back up the first, second, and third blocks when the RAM test is applied. This function has one input pointer that points to the RAM test function, which is either MarchX, MarchXA5 or MarchC. The following figure shows the way the function works.

Figure 7. IEC60730B_DSC_RamTest test principle

The memory blocks are numbered 0, 1, 2, and 3. Block 3 must be tested first because it will serve as a backup for the blocks. Any possible data in block 3 will be damaged.

First, the stack pointer routine is called to check if the SP is outside block 3. If it is found within block 3, the function returns as an error and the RAM test is discontinued. If the SP is not in this block, block 3 is tested using the test routine defined by the argument of the function. If block 3 has a memory error during the test, the flag is set and the test is not applied on the remaining blocks.

IEC60730B_

DSC_Test_Ram

CopyMem

MarchX

UserPointer to the test function

MarchXA5

MarchC

IEC60730B_DSC_RamTest function call



CRC Test of flash

Blocks 0, 1, and 2 are tested in the following way:

1. The particular block of memory is copied into block 3, and the stack pointer is checked to make certain it is in the block. It is moved to the block 3 if it is in the block.

2. The particular block is then tested by the selected function. A flag is set if the RAM test error occurs.

3. The memory is then copied back from the block 3.

4. If the stack was moved to the block 3, it is moved back.

The IEC60730B_DSC_RamTest function returns the following error codes:

• MEMORY_OK (0) – RAM tested passed successfully without any error

• MEMORY_FAIL_BLOCK0 (1) – RAM error(s) in the block 0




• MEMORY_FAIL_SP (8) – Stack pointer within the block 3

10 CRC Test of flash

10.1 CRC Linker featureThe linker command file language has a command CRC16 that calculates the CRC inside a section and allocates the CRC structure at the current location, defined by its position in the linker command file (LCF).

Any 16-bit polynomial can be used to generate a CRC using the same algorithm. Several 16-bit polynomials are used on a large scale and detect almost all one- or two-bit errors, large sets of burst errors, and so on.

The CRC16 LCF directive allocates the space for the CRC record and places it in memory according to the current directive location in the LCF. The LCF directive CRC16 will return the address of the generated record and assign it to the left hand of the assignment. The CRC16 directive has at least two parameters; the first being an LCF symbol that gives the start address of the memory area you want to protect, and the second symbol gives the end address of the memory zone. The start and end address symbols will need to be defined such as "symbol = ." in the LCF file. The third argument is optional and used when you want to specify a custom polynomial to be used in the computation of the CRC. The polynomial is specified as a hexadecimal number, where 0x1021 represents X^16+X^12+X^5+1 (0x1021 is the simplified notation for 0x11021, because the most significant bit, corresponding to X^16 always needs to be 1 in order to have a 16-bit CRC).

Examples of CRC16 directives:

• addr_sym = CRC16(start_address, end_address, 0x1021)

• addr_sym2 = CRC16(start_address, end_address)

• addr_sym3 = CRC16(start_address, end_address, 0x1005)



CRC Test of flash

If the third parameter of the CRC16 directive is missing, its default value will be 0x1005

(abbreviated from 0x11005), corresponding to "CRC-16" polynomial X^16 + x^15 + x^2

+ 1. In the examples above, the last two CRC16 calls have the same effect.

The linker command file in this application is modified this way for SDM:.interrupt_vectors : { start_int = . ; # interrupt vectors * (interrupt_vectors.text) end_int = . ; } > .p_interrupts_ROM

.ApplicationCode : { F_Pcode_start_addr = .; start_text = . ; # .text sections * (.text) * (rtlib.text) * (startup.text) * (interrupt_routines.text) * (fp_engine.text) * (ll_engine.text) * (user.text) * (.data.pmem) end_text = .;

Fcrc_int = CRC16(start_int, end_int); Fcrc_text = CRC16(start_text, end_text);

} >.p_flash_ROM

The bold marked lines have been added into the linker command file. The start_int and end_int variables keep the start and end addresses of the interrupt vector block in the flash. The start_text and end_text variables keep the start and end addresses of the program block in the flash.

The CRC16 command will then calculate two CRC records and store them right behind the program block.

10.2 CRC Application featureCodeWarrior 10.4 has the block corresponding to the linker command CRC features. This block of the program must be included, #include "crc.h".

Then it is necessary to extern the LCF records with the CRC information as follows:extern __pmem CRC16_record crc_int;extern __pmem CRC16_record crc_text;CRC16_runtime_defs runtime_info1;

Then the CRC check can be done using an appropriate function that returns 1 if the calculated CRC is different from the lcf CRC record, or 0 if it matches.



Clock test

CRC16_check(crc_int, &runtime_info1)

In this application, the IEC60730B_DSC_FlashTest routine is linkable by #include "IEC60730B_DSC_FlashTest.h" and it uses the function IEC60730B_DSC_FlashTest(), which checks the interrupt vectors block CRC and the program block CRC. According to the flash consistency, it returns the corresponding error code:

• FLASH_OK 0 - Flash is ok

• FLASH_FAIL_INT 1 - Interrupt vector block error

• FLASH_FAIL_TEXT 2 - Program block error

11 Clock testThe clock test function uses two internal independent clock sources to check the correct system clock frequency. The clock test does not measure the system clock, but the frequency ratio between two internal oscillators. If both clocks have changed about the same relative deviation, the clock test does not recognize it. However, this is a highly improbable situation.

11.1 QuadTimerA0/A1 featureThe frequency ratio is measured by the QuadTimerA0/A1 (QTA0/QTA1) capture feature, which reinitializes the timer automatically after the capture event occurs. The following steps describe this process.

1. The QuadTimerA0/A1 counts IP bus clock is supplied to the QTA0/QTA1 primary source. This clock is divided by 128 to achieve high accuracy and efficiently use the timer counter register 16-bit length.

2. The QTA0/QTA1 secondary input is set to trigger the capture and reinitialize the timer.

3. The slow internal relax oscillator is connected with the second timer input via PIT0 and the crossbar switch. Such peripheral interconnection has to be chosen because there is no other way to connect the slow internal oscillator and QTA0/QTA1.

4. The PIT0 is fed by the 200 kHz clock from the slow internal oscillator. This clock is divided by 4 using the PIT0 divider. When PIT0 achieves the modulo value, the synchronization trigger signal is generated. The synchronization trigger occurs every 100 ms (0.1 Hz).

5. The crossbar switch creates the interconnection between the PIT0 output synchronization signal and the secondary QTA0/QTA1 input used for capture.

Using the described configuration, there is an actual measured and read clock ratio in the QTA0/QTA1 capture register every 100 ms. After the correct peripheral setting, the whole ratio measurement works autonomously without handling software. The measured frequency ratio is checked by clock test routines, and the captured value is compared for a set deviation range. If the frequency ratio is higher or lower than the outer boundary values calculated from frequency ratio deviation, the clock test routine returns the error and the error clock function is called.

The user can select between QuadTimerA0 or QuadTimerA1 to capture the frequency ratio. The watchdog test uses QTA0 as well, but there is no collision when the watchdog test is done first. Select the option QTA1 for clock test if watchdog test is to run in parallel with clock test.



References

The routine IEC60730B_DSC_Clock returns an internal error code:

• CLOCK_OK (0) – the test passed as OK

• CLOCK_FAIL (1) – Clock test is out of range

The routine IEC60730B_DSC_Clock returns the test results:

• 0: CLOCK_TEST_PASS – Clock test passed as OK

• 1: CLOCK_TEST_FAIL – Clock test failed

12 ReferencesIEC 60730 Software safety requirements for automatic embedded control systems, available at http://www.freescale.com



Document Number: AN4772Rev. 08/2013

How to Reach Us:

Home Page:freescale.com

Web Support:freescale.com/support

Information in this document is provided solely to enable system and software

implementers to use Freescale products. There are no express or implied copyright

licenses granted hereunder to design or fabricate any integrated circuits based on the

information in this document.

Freescale reserves the right to make changes without further notice to any products

herein. Freescale makes no warranty, representation, or guarantee regarding the

suitability of its products for any particular purpose, nor does Freescale assume any

liability arising out of the application or use of any product or circuit, and specifically

disclaims any and all liability, including without limitation consequential or incidental

damages. “Typical” parameters that may be provided in Freescale data sheets and/or

specifications can and do vary in different applications, and actual performance may

vary over time. All operating parameters, including “typicals,” must be validated for each

customer application by customer’s technical experts. Freescale does not convey any

license under its patent rights nor the rights of others. Freescale sells products pursuant

to standard terms and conditions of sale, which can be found at the following address:

freescale.com/SalesTermsandConditions.

Freescale, and the Freescale logo, CodeTest, CodeWarrior, ColdFire, ColdFire+,

Energy Efficient Solutions logo, and Kinetis are trademarks of Freescale

Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. All other product or service names are

the property of their respective owners.

© 2013 Freescale Semiconductor, Inc.

AN4772, IEC 60730 Safety Routines for the DSC …19 IEC 60730 Safety Routines for the DSC 56800EX...

Documents

Transcript of AN4772, IEC 60730 Safety Routines for the DSC …19 IEC 60730 Safety Routines for the DSC 56800EX...