Infineon-AP32339 Managing Firmware Integrity XMC-An-V01 00-En
Infineon-AP32339 Managing Firmware Integrity XMC-An-V01 00-En
Infineon-AP32339 Managing Firmware Integrity XMC-An-V01 00-En
Intended audience
The document is intended for users of XMC1000 and XMC4000 family devices.
Table of contents
Application Note Please read the Important Notice and Warnings at the end of this document V1.0
www.infineon.com/xmc 2016-06-10
Managing firmware integrity in XMC
XMC1000 and XMC4000 family devices
Flash integrity and management overview
Given that the focus of this document is on testing integrity in large amounts of data, a higher bit CRC will
calculate a more unique code. We can take a polynomial, such as the Ethernet polynomial 0x04C11DB7, which
is available in the FCE. It translates to:
or in binary:
100000100110000010001110110110111
As an example of polynomial division for the remainder, we take a 32 bit word, 0x01234567, and calculate the
CRC below:
0x01234567 -
00000001001000110100010101100111 00000000000000000000000000000000
xor 100000100110000010001110110110111
000100111100001000111101010110111000000000000000000000000
xor 100000100110000010001110110110111
000111000111000101100100000001111 000000000000000000000
xor 100000100110000010001110110110111
011000011110101110101110111001111 000000000000000000
100000100110000010001110110110111
xor 01000001101101111101001100010100100000000000000000
100000100110000010001110110110111
0000000100001111001010001111001010000000000000000
xor 100000100110000010001110110110111
000001011111010011110111100110111 000000000
xor 100000100110000010001110110110111
0011110011111110011111011010101110000
xor 100000100110000010001110110110111
01110001100110010111100001110101100
xor 100000100110000010001110110110111
0110000101010010011111100011000010
xor 100000100110000010001110110110111
010000001100010001110010101110101
0x8188E575
Figure 2 Example calculation of 32 bit CRC with FCE Kernel 0/1 polynomial
Above, we have the original data, given on the left. At the end of the data, we append a 32 bit seed value, N-1
the size of the polynomial (or 32 bits in this case). Here we use 0x00000000 as the appended seed value - it is
also common to use 0xFFFFFFFF as a seed value. The operation of the CRC is to run sequential exclusive or
(XOR) operations upon each bit position that will provide a leading 1. After the XOR operations are completed
across the data, the remainder is our calculated CRC value. We can confirm this behavior on the XMC4000
device. Figure 3 below shows the above example running on the hardware engine:
The FCE Input Register (IR) receives the data in 32-bit width format. The hardware then runs the above
operations and produces a result (RES). As we can see above, the data matches the calculation example in
Figure 2.
2.1 Methodology
As briefly discussed, we need to control two items in order to accurately calculate the data integrity CRC.
Firstly, we have to know the definititive application size. One method is to put a key at the end of the
application. This unique identifier key will allow a routine to calculate the size by finding the key, thus
determining the end of data. Another important step is to fill a given sector or multiple sectors of flash. The
sector termination point usually coincides with flash partitioning for various functions (i.e. application code vs
emulated EEPROM or other forms of calibration). Setting a limit at a given sector is a clean method for
placement of the CRC. Next we need to consider installing the correct CRC in our application, in order to run a
comparison. We have to compare this to a known good value, a part of the hex file (a value installed by PC-side
tool), in order to confirm our calculation. In order to do this, we will need to apply the correct CRC at a known
address. At the time of compiling, we cannot know the correct CRC value, so we have to allocate a location
where we can later calculate the CRC and change the address location to the correct CRC value. Our application
will appear as follows:
This will open up a window with properties for the project. Under Settings, there will be another set of
selections for properties related to the GCC compiler, linker, and assembler. Under ARM-GCC Create Flash
Image and the subheading Output, you will find an option to select the flash image output type. By default,
it will be Intel Hex, or ihex. You can change this choice to srec as described below.
First, go to Properties, which you can right-click the project to open the properties of the project. Then go to
C/C++ Build and Settings. Under ARM-GCC Create Flash Image you can choose Output and change to
srec.
On the ARM-GCC Create Flash Image options page, you also need to inform the compiler of the preferred
output file name, which requires some manipulation of the Command line pattern:
When you build the project , an SRecord file will appear in your Debug folder. The SRecord file is raw
application code, with no fill or CRC value added.
Here, we can see the image with fill and the Magic Key (excerpt from srecord file):
3 Example application
3.1 XMC1000 family devices
The example application, XMC12_CRC_Blinky provides an example of how the explained image file
conditioning works on a target device. The example first sets up a couple of indicators; P0.0 (which is
connected to an LED circuit on the XMC1200 Boot Kit) is a 5Hz pulse which lets the user know that the
application is running correctly. P0.2 is also an LED indicator that is used to show whether the CRC calculation
is pass or fail. If the LED is OFF, the calculation has failed,and if the LED is ON, the calculation has passed. The
passing condition is that the calculation matches the PC-placed CRC in a specific flash address.
The application also has a UART configured to a UART to USB connection through the debugger on the boot kit.
We can accomplish this by configuring a UART DAVE App to the appropriate pins (P1.3 Rx, P1.2 Tx), which ties
them to the debugger Virtual COM setup. So not only can we check against the LED, we can check the value via
a terminal window as well.
The project is supplied with the document. It is possible to test this by importing the project to DAVETM
Application Note 10 V1.0
2016-06-10
Managing firmware integrity in XMC
XMC1000 and XMC4000 family devices
Example application
(File->Import->Infineon->DAVE Project).
In order to compile and condition the file, the project is conditioned to output an SRecord via the methods
described previously. There is also a batch process file included that will perform the conditioning of the file.
This batch file utilizes both the srec_cat.exe and XMCFlasher.jar utilities, which must both be present in the
directory. Copy the SRecord from DAVE v4 and run the batch file with the filenames adjusted and we will have
a formatted SRecord output.
In order to run the application, we load the application firmware (srec file) via the XMC flasher. To do so, open
the XMC flasher tool:
Choose Connect, and a device selection window will appear. Choose XMC1200-200.
You are now connected to the target, now you choose Select File and in order to see the *.srec file, you will
need to choose the Motorola SREC-Files(*.srec, *.s19, *.mot, *.s) format. The file
new_XMC12_CRC_Blinky.srec is our formatted flash image.
At this point, the application is running and you should be able to verify the process via either the LED
indicators or through a terminal window.
View through terminal window.
The execution time for the example CRC program is 1.52 seconds on XMC1200 running at 32MHz clock.
The XMC4000 family essentially follows the same process as the XMC1000 family, with just a few exceptions.
Now we are using the HW accelerated flexible CRC engine, and as a result we will have to do a little code
conditioning to make this functional. The XMCTM processors are Little Endian. As the CRC32 engines other
primary usage is for managing communication, in particular Ethernet, the FCE is Big Endian. So, in order to
manage the difference, we have to do some conversion. An algorithm has been placed in code to do so:
The same process is followed to generate an SRecord output. A batch process file has been created to convert
the raw application image to the formatted version. When you load the application through the XMCTM flasher,
you will see that the P1.0 LED blinks at a 5 Hz rate, signaling the target is running. P1.1 is an LED indication that
the CRC has passed confirmation. Again, we can view through the terminal window (make sure to connect
through USB port that is connected to target, and you have installed driver.inf on the PC-side..part of
USB_VCOM DAVE generated software, Dave\Generated\USBD_VCOM\inf):
The execution time for the example CRC program is 1.8 ms on an XMC4500 with a 120 MHz clock.
Revision history
Major changes since the last revision
Page or reference Description of change
All First release
Other Trademarks
All referenced product or service names and trademarks are the property of their respective owners.
IMPORTANT NOTICE
Edition 2016-06-10 The information contained in this application note For further information on the product, technology,
is given as a hint for the implementation of the delivery terms and conditions and prices please
Published by product only and shall in no event be regarded as a contact your nearest Infineon Technologies office
description or warranty of a certain functionality, (www.infineon.com).
Infineon Technologies AG condition or quality of the product. Before
81726 Munich, Germany implementation of the product, the recipient of this
application note must verify any function and other WARNINGS
technical information given herein in the real Due to technical requirements products may
2016 Infineon Technologies AG. application. Infineon Technologies hereby contain dangerous substances. For information on
disclaims any and all warranties and liabilities of the types in question please contact your nearest
All Rights Reserved. any kind (including without limitation warranties of Infineon Technologies office.
non-infringement of intellectual property rights of
Do you have a question about this any third party) with respect to any and all
information given in this application note. Except as otherwise explicitly approved by Infineon
document? Technologies in a written document signed by
authorized representatives of Infineon
Email: [email protected] The data contained in this document is exclusively Technologies, Infineon Technologies products may
intended for technically trained staff. It is the not be used in any applications where a failure of
responsibility of customers technical departments the product or any consequences of the use thereof
Document reference to evaluate the suitability of the product for the can reasonably be expected to result in personal
AP32339 intended application and the completeness of the injury.
product information given in this document with
respect to such application.