ReferenceManual_HexView
ReferenceManual_HexView
HexView
Reference Manual
Version 1.15.04
Caution
Vector Informatik GmbH is furnishing this item “as is” and free of charge. Vector
Informatik GmbH does not provide any warranty of the item whatsoever, whether
express, implied, or statutory, including, but not limited to, any warranty of
merchantability or fitness for a particular purpose or any warranty that the
contents of the item will be error-free.
Document Information
History
Vishp 2018-05-10 1.12.02 > Fiat container files not generated correctly
> Neg. Hex-values not accepted
> Public key hash overwritten when merging
VBF
> Sw_signature may be written with no
contents.
Vishp 2018-02-13 1.12.01 > Fill operation with random data failed
> Improve handling of LoadAddress for s-rec.
Vishp 2018-02-05 1.12.00 > Fix range operation issues in V1.11 if not
starting on block start address.
> Fix checksum calculation issues of V1.11 for
restricted ranges or checksum target
address is located inside the csum data.
> Remove BAFA restrictions to crypto
operations.
> Restricting compression/decompression to
non-streaming operations.
> Fixing verification_structure_address output
for Ford-VBF V3.1.
> Fix startup issue on some Windows10 PCs
> Improved Hexview return codes
Vishp 2017-08-03 1.11.01 > Performance improvements for large files
operation (compared to 1.11.00).
> Fix VBF generation issue.
> Substitute binaries for VBF without changing
the VBF header (/xvbfsubst).
Vishp 2017-06-09 1.11.00 > Switches /gmal and /gmad for separate GM
header alignment operations
> Support for further VCC VBF version.
> Support for further Ford VBF version.
> Support for ed25519 signature
> Remove encryption from standard package
due to BAFA export restrictions.
> Support for GM compression (0302) and
BDL (0601) envelope types.
> Support for signature verification
> Support large files (see release notes).
Vishp 2017-03-09 1.10.04 > Tag length calculation for validation structure
corrected.
> GM SLP5: Extend use of of cal-files from 20
to 128.
> Extend number of regions from 32 to 256.
> Extend number of partitions from 20 to 128.
Reference Documents
No. Title
[1] Fiat-Specification 07284-01, dated 2003-05-15
[2] Ford/Volvo: Versatile Binary Format V2.2, V2.3, V2.4, V2.5, V2.6, V3.0, V3.1, JLR3.0
[3] Ford: Module programming and Design specification, V2003.0
[4] GM: GMW3110, V1.5, chapter 11
[5] vHSM Core: Technical Reference, Version 3.1.0
[6] Mazda Versatile Binary Format Specification, V5.0, SD-CSS66199-59, Jan-2020
[7] GB6002, Bootloader Specification, V1.8.1
[8] Chery CBF file format description, V1.3, 2021.12
Contents
1 Introduction .................................................................................................................. 17
1.1 Important notes ...................................................................................................... 18
1.2 Release notes ........................................................................................................ 18
1.2.1 Hexview V1.15.03 ......................................................................................... 18
1.2.2 Hexview V1.15.02 ......................................................................................... 18
1.2.3 Hexview V1.15.00 ......................................................................................... 18
1.2.4 Hexview V1.14.01 ......................................................................................... 18
1.2.5 Hexview V1.14.00 ......................................................................................... 19
1.2.6 Hexview V1.13.01 ......................................................................................... 19
1.2.7 Hexview V1.13.00 ......................................................................................... 19
1.2.8 Hexview V1.12.06 ......................................................................................... 20
1.2.9 Hexview V1.12.05 ......................................................................................... 20
1.2.10 Hexview V1.12.00 ......................................................................................... 20
1.2.11 Hexview V1.11.00 ......................................................................................... 20
2.2.1.9 Export..................................................................................................... 28
2.2.1.9.1 Export as S-Record ......................................................................... 29
2.2.1.9.2 Export as Intel-HEX ......................................................................... 30
2.2.1.9.3 Export as HEX-ASCII....................................................................... 30
2.2.1.9.4 Export as CCP Flashkernel.............................................................. 31
2.2.1.9.5 Export as C-Array ............................................................................ 33
2.2.1.9.6 Export Mime coded data .................................................................. 36
2.2.1.9.7 Export Binary data ........................................................................... 36
2.2.1.9.8 Export binary block data .................................................................. 37
2.2.1.9.9 Export Fiat Binary File ..................................................................... 37
2.2.1.9.10 Export Ford Ihex data container....................................................... 38
2.2.1.9.11 Export Ford VBF data container ...................................................... 39
2.2.1.9.12 Export GM data ............................................................................... 40
2.2.1.9.13 Export GM-FBL header info ............................................................. 41
2.2.1.9.14 Export VAG data container .............................................................. 42
2.2.1.9.15 Export GAC binary files ................................................................... 45
2.2.1.10 Print / Print Preview / Printer Setup ........................................................ 45
2.2.1.11 Exit ......................................................................................................... 45
2.2.2 Edit................................................................................................................ 45
2.2.2.1 Undo ...................................................................................................... 45
2.2.2.2 Cut / Copy / Paste .................................................................................. 46
2.2.2.3 Copy dsPIC like data .............................................................................. 48
2.2.2.4 Data Alignment ....................................................................................... 49
2.2.2.5 Split blocks ............................................................................................. 50
2.2.2.6 Fill block data ......................................................................................... 51
2.2.2.7 Create Checksum................................................................................... 52
2.2.2.8 Run Data Processing.............................................................................. 53
2.2.2.9 Signature verification .............................................................................. 54
2.2.2.10 Edit/Create OEM Container-Info ............................................................. 54
2.2.2.11 Remap S12 Phys->Lin ........................................................................... 55
2.2.2.12 Remap S12x Phys->Lin .......................................................................... 55
2.2.2.13 General Remapping ............................................................................... 55
2.2.2.14 Generate file validation structure ............................................................ 56
2.2.2.15 Run Postbuild ......................................................................................... 59
2.2.2.16 Options ................................................................................................... 60
2.2.3 View .............................................................................................................. 61
2.2.3.1 Goto address… ...................................................................................... 61
2.2.3.2 Find record ............................................................................................. 61
2.2.3.3 Repeat last find ...................................................................................... 62
2.2.3.4 View OEM container info ........................................................................ 62
2.2.4 Flash Programming ....................................................................................... 62
6 Contact........................................................................................................................ 151
Illustrations
Figure 1-1: Typical use-case for Hexview in an embedded system environment ......... 17
Figure 2-1: Main Menu of HexView ............................................................................. 22
Figure 2-2: Edit-Line dialog ......................................................................................... 23
Figure 2-3: Change the base address of a segment ................................................... 23
Figure 2-4: Customizing merge data in the merge dialog ............................................ 25
Figure 2-5: Overlapping data when merging a file ....................................................... 25
Figure 2-6: Compare Info dialog ................................................................................. 26
Figure 2-7: Export data in the Motorola S-Record format ............................................ 29
Figure 2-8: Export dialog for the Intel-Hex output ........................................................ 30
Figure 2-9: Export HEX ASCII data ............................................................................. 31
Figure 2-10: Export flashkernel data for CCP/XCP ....................................................... 31
Figure 2-11: Export data into a C-Array ........................................................................ 33
Figure 2-12: Export binary block data ........................................................................... 37
Figure 2-13: Export dialog for the FIAT binary file ......................................................... 37
Figure 2-14: Export dialog for Ford I-Hex output file...................................................... 39
Figure 2-15: Export dialog for the Ford/VolvoCars-VBF data file format ........................ 40
Figure 2-16: The output information for the GM data export.......................................... 41
Figure 2-17: Export dialog to generate the GM-FBL header information for GENy ........ 41
Figure 2-18: Exports data into a VAG-compatible data container .................................. 42
Figure 2-19: Example of ‘Copy window’ when Ctrl-C or “Paste” is used. ....................... 47
Figure 2-20: Example of cut-data using start-address and length as a parameter ......... 47
Figure 2-21: Pasting the clipboard data into the document specifying the target
address..................................................................................................... 48
Figure 2-22: Copy dsPIC like data ................................................................................ 49
Figure 2-23: Data alignment option ............................................................................... 50
Figure 2-24: Specify the maximum size of the blocks in a dialogue ............................. 50
Figure 2-25: Dialog that allows to fill data ..................................................................... 52
Figure 2-26: Dialog to operate the checksum calculation .............................................. 53
Figure 2-27: Dialog for Data Processing ....................................................................... 53
Figure 2-28: Running signature verification from the dialog. ......................................... 54
Figure 2-29: Configuration window for general remapping ............................................ 56
Figure 2-30: Generate the validation structure for your target memory. ......................... 57
Figure 2-31: Hexview configuration options to change the memory thresholds ............. 60
Figure 2-32: Jump to a specific address in the display window ..................................... 61
Figure 2-33: Find a string or pattern within the document ............................................. 62
Figure 2-34: Dialog to run a CANoe trace ..................................................................... 63
Figure 2-35: Example output for building ID based download files. ............................... 65
Figure 2-36: Scan EepM dialog and example ............................................................... 65
Figure 3-1: Order of commandline operations within Hexview. .................................... 76
Figure 3-2 Example on how to select the checksum calculation methods in the Edit
-> “Create Checksum” operation ............................................................... 80
Figure 3-3: Various checksum calculation options using forced and limited ranges..... 81
Figure 3-4: Various options for checksum calculation using excluded ranges (no
range) ....................................................................................................... 81
Figure 3-5: Calling sequence of the post-build functions .......................................... 108
Figure 3-6: Mapping pysical to linear address spaces............................................... 113
Figure 4-1: Build the list box entries for the GUI ........................................................ 147
Figure 4-2: Function calls when running checksum calculation ................................. 148
Tables
Table 2-1: Auto-file format detection .......................................................................... 24
Table 2-2: Currently available commands in the log-file ............................................. 27
Table 2-3: Description of the elements for the VAG SGML output container .............. 44
Table 2-4: Description of Hexview options. ................................................................ 60
Table 2-5: Hexview return values. ............................................................................. 67
Table 2-6: Accelerator keys (short-cut keys) available in Hexview ............................ 68
Table 3-1: Command line options summary............................................................... 75
Table 3-2: Checksum location operators used in the commandline ........................... 83
Table 3-3: Functional overview of checksum calculation methods in “expdatproc.dll” 86
Table 3-4: Functional overview of data processing methods in “expdatproc.dll” ......... 94
Table 3-5 Parameter options for AES operations .................................................... 100
Table 3-6: OpenPBFile ............................................................................................ 108
Table 3-7: OpenPBFile ............................................................................................ 109
Table 3-8: ClosePBFile ............................................................................................ 109
Table 3-9: GetPBData ............................................................................................. 110
Table 3-10: Correspondence table of signature generation and verification ............... 112
Table 3-11: Elements of the HSM validation structure ............................................... 116
Table 3-12: INI file to configure VSHSM. ................................................................... 117
Table 3-13: INI-file information fort he Fiat file container generation .......................... 121
Table 3-14: INI-File definition fort he C-Code array export function ........................... 122
Table 3-15: INI-file description for Ford I-Hex file generation ..................................... 124
Table 3-16: VBF versions known by Hexview and associated companies ................. 127
Table 3-17: INI-File description for VBF export configuration ..................................... 130
Table 3-18: An example for the Ford VBF V3.1 format to generate a signed VBF file.131
1 Introduction
This document describes the usage of the PC-Tool “Hexview”. It can show the contents of
different file formats, mainly Intel-HEX, Motorola S-record binaries or other car manufacturer
specific file formats. Furthermore, it can perform several data processing operation like
checksum calculation, signature generation, data encryption/decryption or
compression/decompression, but also re-arrange the data contents of a file.
Some of the features of Hexview can be used by the graphical user interface. But there are
also powerful features available via a command line interface. Some features are even just
accessible via the command lines.
Caution
The application of this product can be dangerous. Please use it with care.
Note that this tool may be used to alter the program or data intended to be downloaded into
an ECU for series production. The results of this data manipulation must be observed very
carefully and thoroughly tested.
In no respect shall Vector Informatik GmbH incur any liability for any damages,
including, but limited to, direct, indirect, special, or consequential damages arising
out of, resulting from, or any way connected to the use of the item, whether or not
based upon warranty, contract, tort, or otherwise; whether or not injury was sustained
by persons or property or otherwise; and whether or not loss was sustained from, or
arose out of, the results of, the item, or any services that may be provided by Vector
Informatik GmbH.
Fiat binary and parameter files could not be generated with data processing. The parameters
were ignored. This has been augmented so that even a two-stage data processing is now
possible. This allows to compress and then encrypt files in one step.
New specification from GM are now supported for bootloader files. This includes the latest
release of GB6002, V1.8.1 and CY2310. For details, see the Vector GM-FBL specification.
Versions with V1.12.xx, have problems when performing a data processing operation on
restricted address ranges. This could cause in wrong results, especially when the start
address of the data processing is not the beginning of a block. This issue was fixed.
1.2.8 Hexview V1.12.06
This version of Hexview comes along with expdatproc V2.05.02.
Fix for SplitBlock (‘/SB’) option. This option is not possible with V1.12 or even since V1.11.
Fix VBF validation structure generation when applying split blocks (validation structure did
not contain the splitted blocks).
Support for modified GAC header according to the reprogramming specification V2.4.
Possible issues to apply keys from a file.
1.2.9 Hexview V1.12.05
This version of Hexview comes along with expdatproc V2.05.01.
If there are still problems with Windows10 (hang-up of Hexview when starting), check if the
file pbuild.dll is located in the same directory as Hexview.exe. If so, remove the DLL
completely. This will just eliminate the ability to run the post build option.
1.2.10 Hexview V1.12.00
The version contains some bug fixes to V1.11. especially problems with the segmented
operations on files such as merge parts of data into a file, extracting data out of a middle of
a block, data processing operation on big files e.g. for signature generation. Performance
parameters can now be specified on command line to make operations transparent and
portable.
Note that all compression algorithm still do not support streaming interfaces. Thus, if a block
is too large and cannot be handled in memory but on a hard disc, compression of this file is
not possible. Same applies for decompression, unless “Vector decompression 0” is used.
Possible workaround is the increase of the “Buffer to file size threshold” (/BTFST).
Older version experienced problems with some Windows10 PCs. This version aims to fix
the problems.
Hexview return codes have been approved. A list of return values are provided in this
document.
adjusted, see section 2.2.2.16 for details. As a drawback, operations on such files is a bit
slower. So, please be patient if you want to operate on large files.
Please note, that data compression and most of the decompression algorithms cannot be
applied if the
2 User Interface
This chapter describes the user interface and menu items of the program.
To understand the user interface, some basics of file contents need to be clarified.
First, an Intel-HEX or Motorola S-Record consists of data assigned to specific addresses.
The data can be continuous from a specific start address. A continuous data block is named
as a section or segment. Such files can contain one or more data sections.
The figure above shows the main menu of HexView after a HEX-.File has been loaded. In
the upper part of the tool the sections of the file are listed. In the example above, the file
consists of 2 section2, named “Block 0..1”. For each block the start and end address is
given, as well as the length in hexadecimal and decimal value.
After the block section description, the data itself are displayed. Two adjacent blocks are
separated by a blank line (between 00000190 and 0009000).
A HEX-display line consists of the start address and its data. On the right side, the data is
partly interpreted as characters if possible (if the data is lower 32, the character is shown as
a ‘.’).
Any mouse click with the left button restores the display in the window.
On the bottom of the window some status information is displayed.
From left to right:
Information about the selected menu option
Total number of bytes (decimal) of the currently loaded file (Size=Xxxxx)
The file format of the data file that is currently loaded (see section 2.2.1.2.1 for
possible values).
If only a few characters or hex values are entered, HexView will only change these lines. All
others will remain.
2.1.2 Change base address, erase or jump to a block
It is also possible to make a double click onto the block info which is on top of the main
menu. This opens the block shift address menu:
This dialog allows you to change the address of a block. Simply enter the new base address.
You can also use that to jump to the beginning of the specified block to display the data by
selecting the “Goto”-button (Note that it may also shift the address if another value in “New
Address will be specified).
It is also possible to delete the whole block from the list by pushing the button “Erase entire
block” button.
2.2 Menu
The main menu is grouped into the categories
File
Edit
View
Flash Programming
The file menu operates directly on complete files. The view menu allows searching for
options and the Edit menu can operate on the data.
Each of the elements of the menu will be described now.
2.2.1 Menu: “File”
2.2.1.1 New
Closes the current file and restarts a new session
2.2.1.2 Open
This dialog allows to open a data file. Hexview analyses the data container and checks for
a known format. The resulting data format is displayed in the status line in the bottom area.
2.2.1.2.1 Auto-file format analysing process
The format analyse process uses the following method and order:
File-format detection Scan process and order during file-read operation
> Fiat File Check the filename extension if it is a “.prm” – file, and try to read it as a
Fiat parameter and BIN-File combination.
> GM binary files Check the filename extension if it is a “.gbf” – or “.bin” – file, and try to
(GBF) load it in the GM-binary file format.
> Binary file, if no Read the first line with non-zero length and check if it contains non-
ASCII is found ASCII characters. If so, read the file as a binary block
> I-Hex if the line If the first 25 lines of the file corresponds to an ASCII string and starts
begins with ‘:’ with a ‘:’, the data are read as Intel-HEX.
> S-Rec if the line If the ASCII-string starts with the character ‘S’ it will be read as Motorola
begins with ‘S’ S-Record
> Ford VBF-File Check, if the contains the string “vbf_version”. Load it as VBF-file in that
case.
> Ford I-Hex Check if the file contains one of the Ford’s Intel-HEX header information
and read it as Ford-Ihex file.
> Binary file in all In all other cases, read the file as a binary data input with the base
other cases address of 0.
Table 2-1: Auto-file format detection
2.2.1.3 Merge
This item reads a file and adds the data to the current document data. After selecting this
item, a file-select dialog will open. You can select any of the files in the format of the autofile-
type selections (see section 2.2.1.2.1). After selsecting the file and pressing OK, the
following dialog will appear:
The specified range shows the area of data from the merge file. A smaller range can be
selected that shall be merged to the current document. An offset can be specified that will
be applied to each segment that will be merged. The offset can be positive or negative and
will be added or subtracted. Use a minus-sign to subtract the offset from the base address
of each segment.
If the data of the merged file overlaps with the file data, a warning will be displayed.
If “Overwriting existing data” is accepted, the newly read data will overwrite the data that is
internally present. If this is not accepted, the internal data is kept and just the surrounding
data is read into the internal memory.
All filetypes can be merged that are also supported with the automatic filetype detection
method.
2.2.1.4 Compare
This item provides the means to compare the internal data against the data in an external
file. The compare option can load the same filetypes as supported with “File open”.
After selecting this item, a file select dialog will open. Select the file that contains the data
you want to compare. Afterwards, the file compare dialog will be opened.
The left window displays the internal data, whereas the right window displays the data from
the external file. All differences are marked in colors. Data sections that are not present in
the internal or external document are marked with ‘-‘.
The green up- and down arrows in the upper middle can be used to search for further
differences in the file. The next/previous search procedure starts always from the first line
displayed in the window.
As mentioned above, the next/prev search algorithm starts from the top line of the window.
It uses the next/previous line and searches for the next equal data. If equal data found, it
searches for the next difference or non-presence of data. If this is found, the first appearance
will be displayed on top of the window.
2.2.1.5 Save
After any modification of the data (e.g. modifying a hexline or the base address of a block),
the save option will be enabled. This indicates, that the file has been modified. In that case,
the “Save” option enables you to store the data to the current file name. Hexview writes the
data in the current file format. The current file format is displayed in the status line.
2.2.1.6 Save as
Enables you to store the internal data to a file with a different filename. Hexview uses the
current file format displayed in the status line. If a file format cannot be stored (e.g. the Intel-
Hex/Motorola S-Record “Mixed” file type), a warning will be shown and no data can be
saved. Use the export function of Hexview to store the data in a different format.
2.2.1.7 Log Commands
This option is reserved for future use. It is intended as a certain kind of macro recorder. If
selected, the “save as” dialog will open. Within it, a log file can be selected. HexView will
create a new file or delete the contents of an existing file. Once this has been selected, some
commands will be stored within it.
The following commands are implemented at the moment:
2.2.1.9 Export
This item groups a number of different options to store the internal data into different file
formats. Each export can contain some options to adjust the output information.
The record type will be selected automatically depending on the length of the highest
address information.
The default values for start and end address will be the lowest respectively the highest
address of the file. The Output range specifier can be used if just a portion of the internal
data shall be exported. The range can be specified using the start and end address
separated by a ‘-‘, or can be specified using the start address and length separated by a
comma. Several ranges can be separated by a colon ‘:’. Address and length can be specified
in hexadecimal with a preceding ‘0x’. Otherwise it is treated as a decimal value.
Examples: 0x190,0x20:0x9020-0x903f
The option “Max. bytes per record line” specifies the number of bytes per block for the S-
Record file. The [Browse] option allows to locate the file with the file dialog.
Exports the data in Intel-HEX record format. This opens the following dialog for the export:
The address range of the output can be limited (see 2.2.1.9.1 for a description on the format
and how to use the range specifier).
Hexview supports two different types of output on the Intel-HEX file format, the extended
linear segment and the extended segment. The extended linear segment can store data with
address ranges up to 20 bits, whereas the extended linear segment format can support
address ranges with up to 32 bits (address ranges with up to 16 bit length of addresses are
not using any extended segments).
In the auto-mode, the used segment mode depends on the address length of each line. If
the address length of a line that shall be written exceeds 16 bits, but is lower or equal than
20 bits, the extended segment will be used. If the size of the address is larger than 20 bits,
the extended linear segment type will be used.
Sometimes it is necessary to restrict the number of bytes per record line in the output file.
This can be adjusted with the “Max bytes per record line” parameter.
2.2.1.9.3 Export as HEX-ASCII
The internal data will be exported as HEX-ASCII. Each byte will be written as a pair of
characters. A separator between bytes can be specified as well as the number of bytes that
shall be written per line before a newline will be inserted.
The number of characters per line can be entered in decimal or hexadecimal value. To use
hexadecimal values, the value must start with ‘0x’, e.g. 0x20 will output 32 bytes per line.
The kernel header contains a few information about the kernel file name, both the addresses
of the RAM and the start address of the main application in the flash kernel.
Note
The main application of each flash kernel starts with the function:
ccpBootLoaderStartup(), ensure FLASH_KERNEL_RAM_START has got the right
function address. Sometimes the flash kernel location is at the same address like a
vector interrupt table, to prove this, the developer must add the size of the kernel to the
FLASH_KERNEL_RAM_START address. For Example here
FLASH_KERNEL_RAM_START + FLASH_KERNEL_SIZE = 1533. That mean the
RAM area from 0x1000 – 0x1533 must be clear.
FLASH_KERNEL_NAME=”xxxxx.fkl”
FLASH_KERNEL_COMMENT=”Flash Kernel for xxxxxx”
FLASH_KERNEL_FILE_ADDR=0x1000
FLASH_KERNEL_SIZE=0x0533
FLASH_KERNEL_RAM_ADDR=0x1000
FLASH_KERNEL_RAM_START=0x1000
The parameters of the flash kernel reflect directly the input of the dialog.
These parameters are also written to an INI-file, so that it can be retrieved the next time
when this dialog will be opened. An example of the INI-file is shown below:
[FLASH_KERNEL_CONFIG]
;FLASH_KERNEL_NAME=”S12D64kernel.fkl”
FLASH_KERNEL_COMMENT=”CCP Flash Kernel for Star12D64@16Mhz Version
1.0.0”
;FLASH_KERNEL_FILE_ADDR=0x039A
;FLASH_KERNEL_SIZE=0x0426
;FLASH_KERNEL_RAM_ADDR=0x039A
FLASH_KERNEL_RAM_START=0x039A
; or: [email protected]:
ccpBootLoaderStartup %lx
Note
FLASH_KERNEL_NAME: If omitted, HexView will use the filename of the loaded file.
FLASH_KERNEL_ADDR: If omitted, HexView will use the lowest address of the block
FLASH_KERNEL_SIZE: If omitted, HexView will use the total size of the block
FLASH_KERNEL_RAM_START: If omitted, HexView will use the lowest address of the
block. See also description below.
line by using the remaining parameter in an SSCANF function call. The parameter “%lx”
must represent the address value of the function ccpBootLoaderStartup. If the scan process
was not successful, HexView will add the complete line to the parameter.
The example above extracts successfully the information from the following map-file (extract
of a Metrowerks compiler output):
MODULE: -- boot_ccp.obj –
- PROCEDURES:
ccpBootLoaderStartup 38EB 1E
30 0 .text
The array size can be either 8-, 16- or 32-bit. If 16-bit or 32-bit is selected, the output can be
chosen as either Motorola (big-endian) or Intel (little-endian) style.
The array can be exported as plain C-data. But it is also possible to encrypt it. The encryption
will be an XOR operation with the specified parameter. The decryption parameter is also
given in C-style.
The data is written into a C-array. The array name will use the prefix given from the dialog.
If the block contains several blocks, the data will be written into several C-Arrays. Each block
will contain the block number as a postfix.
#include <fbl_inc.h>
#include <_page4a.h>
#if (FLASHDRV_GEN_RAND!=1739)
# error “Generated header and C-File inconsistent!!”
#endif
*
****************************************************************/
#include <fbl_inc.h>
#include <_page4a.h>
#if (FLASHDRV_GEN_RAND!=1739)
# error “Generated header and C-File inconsistent!!”
#endif
*
****************************************************************/
The macro [Prefix-name]_DECRYPTDATA() can be used to extract and encrypt the data. It
will be generated according to the encryption option and value.
The output can also generated via the command line. Refer to section 3.3.3 for further
information.
The declaration of the C-arrays are dedicated to the Vector 36ootloader. In some cases, it
might be necessary to use these structures in a pure C-environment without compiler
abstraction used by Vector’s naming convention. Use the “Use strict Ansi-C declaration” in
this case.
Another option is to use so-called memmap-statements. Hexview will generate statements
to declare a define and then include the file memmap.h:
Example
Memmap declarations generated by Hexview:
#define FLASHDRV_START_SEC_CONST
#include “memmap.h”
The dialog shown above can only be understood if the Fiat file format is known. This
document does not intend to explain this file format. Refer to 0728401.pdf for further
explanation.
During the export, an INI-file will be updated or generated. If the INI-File was specified by
the commandline, this file will be used. Otherwise, an existing file will be updated or new file
will be generated with the same name and location as the export filename. For the INI-file
format, refer to section 3.3.2, “Output a Fiat specific data file (/XB)”.
2.2.1.9.10 Export Ford Ihex data container
The file format generated with this output is based on the Ford-specification “Module
Programming & Configuration Design Specification”, V 2003.0, dated: 25 April 2005, Annex
C.
Besides the download data itself, there are some optional and mandatory values added to
the output file. The optional fields can be selected/unselected with the option checkbox.
All values entered in the dialog below will be written to the INI-File. The INI-file can also be
used for the command line option to generate the output without the needs of a user input.
For detailed description of each item of the data fields, refer to the document mentioned
above. Further information can be found in section 3.3.4, “Output Ford files in Intel-HEX
format”.
Information: The file format has been replaced by VBF.
Figure 2-15: Export dialog for the Ford/VolvoCars-VBF data file format
Figure 2-17: Export dialog to generate the GM-FBL header information for GENy
</FBLConfiguration>
</ECU>
2.2.1.9.14 Export VAG data container
This item exports the data into a VAG-compatible data container format.
Note
The generated VAG data file is NOT compatible with the ODX-F format used for UDS.
The VAG data container is a SGML-file that can be divided into five sections. Three sections
are merged from external files, two others are generated.
<DATEN-VERWEISE>
Section 2: <DATEN-VERWEIS>FLASHDRV</DATEN-VERWEIS>
Generated “Data Reference section” <DATEN-VERWEIS>dav_pfu_01</DATEN-
VERWEIS>
The reference section contains a reference to </DATEN-VERWEISE>
each segment or block. An external Hex-file can
be added for reference, e.g. a HIS-flash driver. It
is necessary that this hex field contains only one
segment or block.
</ABLAUF>
Section 3: </ABLAEUFE>
“SGM post-header file”.
<DATENBLOCK-
Section 4: NAME>dav_pfu_01</DATENBLOCK-NAME>
Generated “data section”. <DATENBLOCK-FORMAT-
NAME>dfn_mime</DATENBLOCK-FORMAT-NAME>
This section contains the current data. On the <START-ADR>0x9000</START-ADR>
right side an example of the output is shown. <DATENBLOCK-FORMAT>0x00</DATENBLOCK-
FORMAT>
Start and end address is taken from the block <GROESSE-DEKOMPRIMIERT>0xFA2</GROESSE-
information. The checksum is calculated with the DEKOMPRIMIERT>
<LOESCH-BEREICH>
given checksum method (see section 2.2.2.7 or <START-ADR>0x9000</START-ADR>
3.2.10 for further details on checksum <END-ADR>0x9FA1</END-ADR>
</LOESCH-BEREICH>
calculation). The erase section is calculated out <DATENBLOCK-CHECK>
of the section length. The value of <START-ADR>0x9000</START-ADR>
<DATENBLOCK-FORMAT> is taken from the <END-ADR>0x9FA1</END-ADR>
<CHECKSUMME>0xA866</CHECKSUMME>
“Data Format ID” field in the dialog box. </DATENBLOCK-CHECK>
The <DATENBLOCK-DATEN> contains the data <DATENBLOCK-DATEN>
MIME-Version: 1.0
of the block or segment in a MIME-coded format.
WflaW1xdXl9gYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXp
7fH1+f4CbgoOE
hYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqe
oqaqrrK2ur7Cx
srO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09T
V1tfY2drb3N3e
</DATENBLOCK-DATEN>
</DATENBLOCK>
</DATENBLOECKE>
</DATEN>
</SW-CNT>
Section 5:
Appending file contents from „SGM footer file“
Table 2-3: Description of the elements for the VAG SGML output container
It should be noted, that the filename is automatically generated out of the part number and
the S/W-version fields whenever the fields are changed. You can overwrite the name if the
filename is changed at last. When editing the filename or [Browse] for a file, the name will
not automatically adapted.
It is also possible to preprocess the data before it is MIME-coded. This process is done after
the checksum calculation. It is intended to be used for e.g. Data Encryption.
It uses the standard interface functions from the EXPDATPROC.DLL (refer to section 4.2,
2.2.2.8 and 3.2.11 for further details).
information in separate files. It is a prerequisite that the INI-file resides in the same folder as
the HEX-file.
This INI-File can then also be used in the command line option.
The following list file shows an example of the INI-file:
[SGMDATA]
DATENBLOCKNAME=dav_pfu
FLASHDRVSECTION=FLASHDRV
FLASHDRV=D:\Usr\Armin\VC\HexView\FLASHCODE_SH70XXF_704.hex
SGMHEADERPRE=header1.txt
SGMHEADERPOST=header2.txt
SGMFOOTER=footer.txt
CHECKSUMTYPE=2
DATAPROCESSINGTYPE=0
DATAPROCESSINGPARAMETER=1234567890
PARTNUMBER=123456789ab
SW_VERSION=cdef
FLASHDRV_DLID=12
DATA_DLID=24
MAXBLOCKLEN=0x400
Note
This INI-file is automatically created when executing this dialog.
Example
Address range with start and end address: 0x9020-0x903f
This specifies start- and end-address in hexadecimal value. A ‘0x’ is required to
preceed. If ‘0x‘ is omitted, the value is treated as a decimal value. This allows to use
the parameters in both hexadecimal or decimal values.
Cut or paste can only be used if data are present inside Hexview.
The paste-operation is activated when something is present in Hexview’s internal
clipboard.
When ‘Paste’ (Ctrl-V) is entered, a window will open where the target paste
address can be specified. By default, the clipboard’s start address will be shown
as a default value. This can be overwritten. An address offset will be applied to
the pasting range from the clipboard.
Figure 2-21: Pasting the clipboard data into the document specifying the target address
When expanding data, Hexview will add 2 zero bytes to the expanded location, one for the
ghost byte and one for the remaining byte. After flashing these data into dsPIC memory, the
data can be access using a byte pointer to data. The correct data will be read now.
When shrink operation is used, the upper two high bytes will not copied, only the lower two
bytes are copied to the new location.
When selecting the “Clear ghost byte” Copy type, no data will be copied, but the highest of
the four bytes will be set to 0. This allows to calculate a correct checksum over the data,
since internally of the dsPIC the ghost byte is always read with 0.
A target location is only required if the shrink or expand address is not double or half of the
specified source address. This option is also available through commandline.
2.2.2.4 Data Alignment
Data Alignment operates on the block start address and its length. This can be used to adjust
the start address and length on all blocks/segments.
This option ensures, that the start address of all blocks is a multiple of the segment size
alignment value. E.g., if this parameter is 2, then HexView ensures that all addresses are
even (dividable by 2 without remainder). If an odd address is detected, HexView fills bytes
with the “Fill character” at the beginning of a block until the address is even.
If “Align size” is selected, too, the size of all blocks is a multiple of the given segment
alignment value. If a length of a block is not a multiple of the segment align value, a fill
pattern will be added until the size meets this condition.
Some export file formats contain separate address and length information used to specify
the erasable ranges of a flash memory. These address ranges require different alignment
definition. This align value can be specified in the “Erase segment alignment”. It is mainly
used with Ford-VBF and Fiat binary/parameter files. This value can also be specified through
the commandline option /AE.
2.2.2.5 Split blocks
This option is used to split larger blocks into smaller one (see also chapter 3.2.25). This can
be useful if data processing shall be applied to large blocks, e.g. data compression, that
cannot be applied to huge blocks due to restrictions on the implementation of the data
compression algorithm. Another use case is if the programming time of a huge block
exceeds the timeout restriction of an OEM download procedure. In this case, one huge block
can be split into smaller parts.
The values in the dialogue can be entered in decimal or hexadecimal with a preceding “0x”
as a marker for hex values. Actions will be taken immediately after pressing OK.
Caution
It must be noted that Hexview cannot maintain splitted blocks over some other
operations such as filling or merging data. The reason is, that in these cases blocks are
analysed if they are adjacent and merged together.
It must also be noted that data compression on adjacent blocks is risky. Depending on
the compression algorithm, a compressed block can even be larger than the original
size. In this case, one enlarged compressed block will reach into the beginning of the
next block. This must be considered when using this operation. The operation has
more an experimental status, not a productive and should be used with great care.
Consider, to export the data as a binary data stream. An LZSS decompression
algorithm should be able to decompose the binary data stream into the original block(s)
back again.
The checksum type depends on the capability of the underlying checksum DLL. For the
interfaces, refer to section 4.1. Also, section “Checksum calculation method
(/CS[R]x[:target[;!Forced-range[#fill pattern]][;limited_range][/no_range]]” provides further
details on checksum calculation.
The button [Calculate] will run the calculation and shows the result in the field checksum
value. If [Insert] is selected, the checksum calculation will be performed and the result will
be added to the internal data blocks on the given address.
When the checkbox “Reverse results” is selected, the checksum will be inserted in reverse
order, with lowest byte first (“little endianness”).
2.2.2.8 Run Data Processing
The second method that uses the EXPDATPROC.DLL functions is the data processing field.
As already mentioned in the Checksum calculation section, the data processing directly
operates on the internal data. Most of these operations requires a parameter for this
operation. Typically, the resulting data is the manipulated data. Therefore, no result of the
data processing can be inserted or added to the data sections.
The data processing allows to operate on the data. Typical applications are data
decryption/encryption or compression/decompression.
The string value given in the Parameter field is passed to the routines for the data
processing.
The Data processing range can limit the data range, where the data processing will operate
on. The parameter will be stored in the registry, to retrieve the information the next time this
option is activated. Please note, that you can specify only one range. If several ranges are
specified using the colon separator, only the first one will be used to limit the data area.
See also section 4.2 for further details on the DLL-interface. Please, read also section “Run
Data Processing interface (/DPn[:@placement]:param[,section,key][;outfilename])” for more
details on available data processing functions.
Some data processing options allow to use a file that contains the parameter. You can
browse for the specific file using the “Browse” button.
Please note that all file references within the data processing operation are relative to the
location of the data file that is currently loaded. So use either full path or use relative paths
related to the location of your input file!
2.2.2.9 Signature verification
A signature that was previously generated with the data processing interface can also be
verified. For calculation, the data, signature and the counter key, namely the public key is
required. The data are the internal data of Hexview, the key parameter and the signature
can be referenced in the corresponding dialog parts. The values for key and signature can
either be given directly or referenced by a file. The available verification methods are shown
in the dialog. These should be the counterparts of the previously used algorithm to calculate
the signature. Otherwise, the signature verification will fail. If the verification was successful
or not will be shown in the resulting dialog after pressing the OK button.
Figure 2-30: Generate the validation structure for your target memory.
Example
Below is an example of the generated C and H-file:
_page3a.h:
/***************************************************************
* Filename: D:\uti\_page3a.h
* Project: Header-File for validation structure
* File created: Tue Mar 11 19:59:54 2014
****************************************************************/
#ifndef ___PAGE3A_H__
#define ___PAGE3A_H__
#define VALIDATEINFO_STOP_SEC_CONST_EXPORT
#include “memmap.h”
#endif
_page3a.c:
/****************************************************************
* Filename: D:\uti\_page3a.c
* Project: C-File for validation structure
* File created: Tue Mar 11 19:59:54 2014
****************************************************************/
#include “_page3a.h”
#define VALIDATEINFO_START_SEC_CONST
#include “memmap.h”
#define VALIDATEINFO_STOP_SEC_CONST
#include “memmap.h”
• Word type:
This specifies the endianness for 16- and 32-bit fields of the generated data structure.
• Force 32-bit variables
If not checked, Hexview will use either 16-bit or 32-bit values, depending on the length
of the largest address in the hex file. When checked, the address and length values
of the validation table will always use 32-bit types.
• ID tag begin:
Will be placed at the beginning of the address/length list. This can be used to uniquely
identify if the address/length field is actually present there.
• Data source:.
For sure, the internal data of Hexview will be used. A limited range of the data can be
specified. In addition, a range can be specified if an address range shall be spared
out. It could be useful to add also address/length information from other files. These
files can be specified In the file list as well. Hexview will scan the address/length
information and will add it to the list, and also calculate its checksum if soecified.
• Block Checksum:
If checked, Hexview will calculate and add the specified checksum to each
address/length field.
• Total checksum:
if checked, a checksum/CRC will be calculated over the complete set of data. This
checksum can be calculated in addition or instead to the block checksum values.
• ID tag end:
Here you can specify a magic number that indicates the end of the list. It can be used
to verify if the complete validation list is present.
• 16-bit byte checksum:
This is a checksum that is generated over the complete validation array. It can be
used in addition to check if the complete validation structure is present.
When generating the data, all parameters will be written to the INI-file. This INI-file can be
used for the commandline option.
2.2.2.16 Options
This option allows to change threshold parameters for Hexview. Since V1.11.00, Hexview
can handle large data files, even bigger than 1 GB (but definitely not more than 4.7 GB since
it is currently a 32-bit program). To achieve this, data blocks must be handled on the file
system, because the internal memory would exhaust to keep everything there. However,
operations are much faster when the data blocks can be kept in RAM. Therefore, memory
thresholds were introduced so that the user can decide when to switch from RAM operation
to file operation. This option is used to change the pre-configured thresholds.
The dialog above shows the default values of Hexview. See also sections 3.2.6, 3.2.7 and
3.2.8 for further explanations.
Caution
Modifications will be stored permanently on your machine.
If you change the values, they will be stored in the windows registry of the
current user on this machine. You cannot port them to other machines. In other
words, if you run Hexview on another machine or as another user, you will see
here the default values again.
Note
Parameters can be given by commandline for temporary usage. This makes it more
portable.
2.2.3 View
This menu item provides some features to control the view.
2.2.3.1 Goto address…
This item allows to jump to a specific address within the view.
If the address is valid, the slider will be moved to the beginning of the address. Thus, the
address information will be shown on the top of the display. The line is not highlighted.
A way to jump to the beginning of an address block can be done by jump to the beginning
of the file (press POS1 or Ctrl-Pageup button)
2.2.3.2 Find record
This option allows to search for a pattern within the file.
The format of the pattern can be selected on the right side of the window. By default, the
data pattern is given as a hexadecimal data byte stream. The search algorithm searches
from the beginning until the presence of this pattern is found. HexView tries to display the
value on the top of the screen. If a pattern has been found, the search can be repeated from
the last position where the pattern has been found.
If the “Find-string format” is changed to “ASCII-string”, the pattern entered in “Find what” will
be treated as an ASCII pattern and will search for the ASCII values.
2.2.3.3 Repeat last find
This option is only present after a successful search operation. This item will continue the
search given from “View -> Find record”.
2.2.3.4 View OEM container info
This option was implemented to present some OEM-specific information available in the file.
However, at the moment only the GM header information will be shown.
This may be extended in the future.
2.2.4 Flash Programming
This menu item is directly related to the flash process.
2.2.4.1 Scan CANoe trace log
This menu allows you to backtrace a download of CAN data. You need an ASCII-based log
file from CANoe.
You need to go through the menu step-by-step. First, you need browse for the CANoe trace
file, which normally has the file extension “.ASC”. Then, select the channel. Hexview will
show the available channel numbers in the list box. Then select the functional and physical
CAN identifier. Also here, Hexview will show you all available CAN IDs found in the trace
file.
Not only UDS downloads are supported, but also KWP2000 and GMLAN. Pre-select the
desired option before running the scan.
Select the checkbox “Scan Data” if the resulting data information shall be scanned and
placed into the memory buffer. Now you can run the trace by clicking on the “Run Trace”
button. An output window like shown above can be seen. Depending on the “log verbosity
level”, more or less information per trace can be seen. The internal Transport layer analyser
will analyse the timing of each service and indicated in the list box. The information can be
stored into a CSV file through the “Save log” button, to further process this with a
spreadsheet.
After finishing the trace you can exit through the “Exit” button. But if you have selected the
“Scan data” checkbox and the trace ran successfully, you can also leave using the “Exit and
insert scan” button. Then, all scanned data will be placed into the memory buffer with the
specified addresses, length and data found in the RequestDownload/TransferData services.
2.2.4.2 Build ID based EEP download file.
This option is intended to be used to create an address based data file with EEPROM
information. Each segment in the memory represents one entry of an EEPROM block. The
virtual address space shall address a special driver that extracts the block number and data
from each record and writes the data to an EEPROM emulation.
Hexview takes the information from an XML-file with the following format:
<?xml version=”1.0”?>
<DataFlash>
<AdministrativeSection>
<SectionSize>0x0800</SectionSize>
<Offset>0x0000</Offset>
<VirtualBaseAddress>0x100000</VirtualBaseAddress>
<IdMultiplier>256</IdMultiplier>
</AdministrativeSection>
<Record>
<ID>0x80</ID>
<Length>4</Length>
<Data>
0x47, 0x48, 0x49, 0x4a
</Data>
</Record>
<Record>
<ID>0x81</ID>
<Length>8</Length>
<Data>
0x20, 0x30, 0x31, 0x32,
0x40, 0x40, 0x41, 0x42
</Data>
</Record>
</DataFlash>
Each record consists of its ID, length and data. The block address of a segment will be
created by the formula:
<VirtualBaseAddress> + <IdMultipler> * <ID>
The above example generates the following output:
The offset and SectionSize information is not used and just present for compatibility.
2.2.4.3 Scan EepM data section
The EepM is a software component from Vector to emulate EEPROM in data or program
flash. If EepM has written data into a flash memory, it is often difficult to re-trace the block
information. This option is used to provide the possibility to upload the memory contents of
the flash memory into a HEX file and then let Hexview trace back the block number, length
and information and put the results into an XML file.
The above picture shows the flash memory data in the background and the dialog for scan
in the foreground. You need to specify the flash segment size (flash sector size, the minimum
write unit of the flash memory), but also specify the range of data and the XML output file.
If the scan could be executed successfully, an output fiel as shown below can be seen:
<?xml version=”1.0”?>
<DataFlash>
<AdministrativeSection>
<SectionSize>0x2</SectionSize>
<Offset>0x0000</Offset>
<VirtualBaseAddress>0x400</VirtualBaseAddress>
<IdMultiplier>1</IdMultiplier>
</AdministrativeSection>
<Record>
<ID>12</ID>
<Length>17</Length>
<Data>
0x10, 0x4D, 0x16, 0x0F,
0x10, 0x11, 0x02, 0x03,
0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0A, 0x0B,
0x0C
</Data>
</Record>
<Record>
<ID>13</ID>
<Length>17</Length>
<Data>
0x10, 0x4E, 0x17, 0x0D,
0x0E, 0x0F, 0x10, 0x11,
0x02, 0x03, 0x04, 0x05,
0x06, 0x07, 0x08, 0x09,
0x0A
</Data>
</Record>
<Record>
<ID>11</ID>
<Length>1</Length>
<Data>
0xFD
</Data>
</Record>
</DataFlash>
Caution
An error level of 0 does not mean that all operations are successfully performed. You
need to verify carefully the output if it matches the desired expectation!!
HexView cannot only be used as a PC-program with a GUI to display information. It is also
possible to manipulate the data via command line. There are even some options only
available through command lines.
The following section describes the usage of the command line.
The command line can be grouped roughly into two groups: general options that operates
generally and OEM-related command line options. The OEM command line options control
the generation of files in OEM specific file formats.
1 A rangedefines a section area. It can be entered in two ways, either with start address and
length separated by comma or with start address and end address separated with ‘-‘.
Examples are: “0x1000,0x200” (range) or “0x1000-0x11FF” (start and end address). Both
parameters span the same range and will be treated the same way. Note that the end
address must be higher than the start address. Values are accepted as binaries, integer or
hex with C-like pre- or postfixes.
Note
Parameter /Xx cannot be used multiple times. /Xx can be specified only once in the
parameter list.
/Mt and /MO cannot be used in parallel.
Apply /RB
The commandlines can be specified in any order. Hexview will first summarize the
commandline operations and will then execute them. Since some operations may have
influences to subsequent operations, the commandline operation sequence within hexview
is important to know. The following commandline sequence will be applied (if specified):
This section describes command line options of HexView, that can be used in general. There
is no restriction or limitation in the combination of the options (as long as they are useful).
3.2.1 Align Data (/Adxx or /AD:yy)
The start address of each block will be aligned to multiples of the given parameter xx. If the
separator ‘:’ or ‘=’ is omitted, the parameter xx is a hexadecimal value. If the separator is
used, the value xx is interpreted in C-style, e.g. /AD:0xFF is the same as /AD:255 or
/AD:11111111b. This value can only be an unsigned char value.
Example
/AD2
Aligns address to be a multiple of 2.
If a block starts at 0xFE01 a fill byte will be inserted at 0xFE00. The inserted character
will be 0xFF by default. The default character can be overwritten with the /AF
parameter.
An address starting at 0xE000 will be left unchanged. No characters are inserted.
/AD:0x80
Align the addresses of all sections to a multiple of 128
If an address starts at e.g. 0xE730, the address will be aligned to 0xE700.
Example
/AD4 /AL
A block 0xE432-0xE47E will be aligned to 0xE430-0xE47F. All characters will be filled
with 0xFF or the value specified by /Afxx.
Example
/AE:0x200
Erase blocks are always aligned to multiples of 0x200
Example
/AF:0xEF
Fill character is 0xEF
/AFCD
Fill character is 0xCD
Example
/AR:0x1000,0x200
Only the data between 0x1000 and 0x11FF are loaded to the memory and then further
processed.
/AR:0x7000-0x7FFF
This loads the data from 0x7000 to 0x7FFF
the computer itself. Therefore, threshold parameters have been introduced to increase
performance on powerful computers.
The BHFCT parameter specifies the total file size of a hex file. If the file is bigger than this
threshold, Hexview will extract the data by putting the contents directly to a temporary file
on hard disc (the temporary file will be located in the %TEMP% folder). If the extracted data
further processed on hard disc or memory depends on the size of each section block.
The value is specified in kB. The default is 64MB (65536kB; /BHFCT=65536). See also
section 2.2.2.16.
3.2.7 Buffer to file threshold (/BTFST=xxx)
A file handled by hexview consists of one or more regions or blocks. Hexview operates these
blocks in a list. Typically, after loading a file, the data of the blocks are stored temporarily in
internal memory. However, if one block exceeds the limit its data will be stored on hard disc.
The threshold, when to put data to hard disc is specified with this parameter. Thus, smaller
blocks can still be handled in memory, whereas bigger ones are stored on hard disc.
The value is specified in kB. The default is 16MB (16384kB; /BTFST=16384 or
/BTFST=0x4000). See also section 2.2.2.16.
3.2.8 Temporary buffer size (/BTBS=xxx)
This parameter is used when operating on large blocks stored on hard disc. The operation
is done on portions in a streaming operation, e.g. for signature calculation parts of the block
data are read into the temporary buffer and then processed. The result is written back and
the next portion is taken from the file for the block operation until all data of a block have
been processed. Thus, this parameter is a performance parameter.
The value is specified in kB. The default is 1MB (1024kB; /BTBS=1024 or /BTBS=0x400).
See also section 2.2.2.16.
3.2.9 Cut out data from loaded file (/CR:’range1[:’range2’:…]
The parameter option /CR is used to cut out a range from the loaded data file. It removes
any data within the specified ranges. More than one range can be specified. Each range
must be separated by a colon ‘:’.
Example
/CR:0x1000,0x200
If a data section in the range from 0x1000-0x11FF exist, the data will be removed from
the file. All successive operations will operate on data that don’t include this section. All
other sections remain unchanged. If this section is located within a segment or block, it
will be splitted into two.
/CR:0x7000-0x7FFF
This removes the data from 0x7000 to 0x7FFF if present.
Example
Figure 3-2 Example on how to select the checksum calculation methods in the Edit -> “Create Checksum” operation
Various additional parameters can follow. At first, separated by a colon ‘:’ it can be specified
where Hexview shall place the result of the checksum calculation. This can either be a file
or it can be placed directly into the internal data buffer. Be careful when placing the
checksum into the data buffer. It will overwrite data without complain. The parameter
“@append” is the default. Thus, if no target parameter is specified, Hexview will
automatically append the checksum result to the last block. Other target addresses can be
specified. Please check Table 3-2 what type of specifications are possible. If placed into the
data file, the location of the checksum value will automatically be spared by Hexview so that
the checksum itself does not influence the calculation.
Further parameters specify ranges for the checksum calculation separated by semicolon ‘;’.
The first optional range is a “forced range” marked with a preceding exclamation mark ‘!’.
Hexview will calculate the checksum over this forced range as virtual data information and
uses either the data that exist in the internal memory or, if no data exist at the specified
address, a fill value. Internally, Hexview will create a filled range over this forced address
range and will merge the existing data into it. Existing data always have certainly higher
priority than filled data. This fill operation has no effect to the internal data itself and is just
generated for the checksum calculation. A fill character or pattern can be specified and can
be added directly to the forced range separated but must be separated by a hash sign ‘#’1.
The value is given in hexadecimal value with or without preceding ‘0x’. If no fill value is
provided, the fill value ‘FF’ is used. Typical use case is to build a checksum over a flash
memory that also include the programmed and non-programmed data. The fill value
corresponds to the erase value of the flash. You can specify only one forced range.
Figure 3-3: Various checksum calculation options using forced and limited ranges
It is also possible to calculate the checksum just over a specified range of the loaded
memory. Only one range can be specified here. The limited_range parameter is optional. If
not provided the checksum will be calculated over all specified data.
Figure 3-4: Various options for checksum calculation using excluded ranges (no range)
The “no_range” can be used to extract ranges from checksum calculation. It works similar
to the /CR option, but will extract the specified ranges only for the checksum calculation.
1 From V1.12.00 and upwards. In earlier versions a fill character was mandatory.
This can be useful if you want to explicitly exclude ranges from checksum calculation. You
can specify a list of excluded ranges each separated by a forward slash. The “no_range” will
be applied AFTER the forced range so that it can also be applied to virtual resp. non-
programmed address areas.
Note, that the relative target address specifier such as @append, @upfront, etc are relative
to the currently loaded data without the no_range or force_range address data. This was
cleaned up in Hexview V1.12.00.
Example
/CS6:csum.txt
Runs the checksum calculation method “Wordsum LE into 16-Bit, 2’s Compl LE-Out
(GM new style)” and writes the results into the file CSUM.TXT.
This example uses the checksum method “Wordsum LE into 16-Bit, 2’s Compl LE-Out
(GM new style)”, as this is the 7th option in the checksum dialog menu shown above.
/CS1:@append;0x1000-0x7FFF or /CS1:@append;0x1000,0x7000
Runs the checksum calculation method “Bytesum into a 16-Bit LE-out” and appends
the checksum at the very end of the internal file. The checksum is calculated over the
limited range from 0x1000-0x7FFF as specified.
A range within the checksum range can be excluded, if for example a data array shall
not be used for checksum calculation, Such an excluded range can be specified with a
preceding ‘/’.
/CS7:@upfront;0x2000-0x3fff/0x2800-0x29ff/0x3000,0x200
The option above calculates the checksum using method 7 (the 8th) on data within the
range from 0x2000-0x3ffff. The range from 0x2800-0x29ff and 0x3000-0x31ff will be
excluded for the checksum calculation. The exclude has no effect to the real data. The
result of the checksum calculation will be written before the very beginning of the file
data (Note: it will be written not upfront to 0x2000, but to the very beginning of the
loaded file. This applies to all other labelled address specifier, such as ‘upfront’, ‘begin’
and ‘append’).
/CS4:@0xFFFC;!0x01000-0xFFFFF#FF
It might be useful to calculate the checksum over a range of pre-filled data that do not
exist in the internal data representation. A command can be given to calculate the
checksum also over this range. This feature is only available through the commandline
interface. For example, if the checksum shall be calculated over the range of 0x0.1000-
0xF.FFFF which is pre-filled with the pattern FF, a checksum can be calculated over the
existing data including the specified range.
With HexView version V1.2.0 and higher, the results of the checksum can now also be
written into an output file or placed into a location within the internal data. The location is
separated by a ‘:’ or ‘=’ sign, followed by the target where the resulting checksum value shall
be placed in. The example above shows how to write the results of the checksum calculation
into the file “csum.txt”.
The following target IDs can be used:
Filename (e.g. csum.txt) Writes the result into a file. The value is
written from high to low byte in hexadecimal
form. Each byte is separated by a comma.
@append The results of the checksum will be added at
the very end of the file.
@begin Writes the contents at the very beginning of
the file.
Important Note: It will overwrite the first
bytes of your data. The number of bytes that
will be overwritten depends on the checksum
method.
@upfront Write the checksum results prior to the
beginning of the first block. No data will be
overwritten.
@end Places the checksum on the last bytes of the
last section of the file. The address is
automatically calculated.
Important Note: It will overwrite the last
bytes of your data. The number of bytes that
will be overwritten depends on the checksum
method.
@0x1234 Writes the checksum result into the address
location given after the @ operator.
Table 3-2: Checksum location operators used in the commandline
Caution
Whenever using the @ operator to write the results into the internal data, make sure
that the checksum is at the proper location and is not overwriting accidentally any
imported data!
Since Hexview V1.10.01 the parameter /CSR can be used which accepts the parameter in
the same way as /CS does. The only difference is, that /CSR reverses the output to ‘little
endian’ instead of ‘big endian’.
The available checksum methods depend on the expdatproc.dll. Version 1.05.00 of the DLL
provides the following methods:
0 ByteSum into 16-Bit, BE-out Sums the bytes of all segments into a
16-bit value. The result is a 16-Bit
value in Big-Endian order (high byte
first).
1 ByteSum into 16-Bit, LE-out Sums the bytes of all segments into a
16-bit value. The result is a 16-Bit
Caution
Take care not to overwrite data when placing any results into the data array. Make
sure, that no important data of your application are located at the same place. Hexview
may not check that user data are overwritten!
Examples
HexView testfile.dat /DP1:CC
This option runs the second data processing method in the list. It passes the parameter
string “CC” to the function.
Hexview testfile.dat /dp11:00112233445566778899aabbccddeeff;RFC1321#IV=0
This command encrypts a file using AES128 in CBC-mode. The initialization vector is 0
and the padding mode according to RFC1321 is applied.
The EXPDATPROC that comes with this delivery of Hexview can manage the following data
processing methods:
ID Name Description Parameter
0 No action Does no modification on the -
data
1 XOR data with byte Runs XOR operation on the If no parameter is given, all data will
parameter data be inverted (XOR by 0xFF).
Otherwise, it will run a byte-wise
operation with a HEX-string passed
as parameter.
2 AES-ECB encryption Encrypts the data with the A 16/24 or 32 byte hex string
AES standard encryption 00112233445566778899aabbccdde
method. eff[;padding method]
(This represents the HIS Padding at the end of the block is
security class AAA). optional. The following padding
Selection of AES-128/AES- methods are accepted:
196 or AES-256 selected by - PKCS7
the key length (16, 24 or 32 - RFC1321
byte key length activates - ANSIX.923
either AES-128, AES-192 or Example: /DP2:
AES-256). 00112233445566778899
aabbccddeeff;PKCS7
Example: /dp57:#LZSS12,5
58 LZSS decompression LZSS decompression with See description for #57
variable sliding
window/repetition length
59 LZSS compress and AES- LZSS compression with See description for #57. In addition,
CBC encrypt variable sliding see description for AES parameter
window/repetition length in chapter 3.2.11.3.
followed by AES encryption
Example:
/DP59:00112233445566778899aab
bccddeeff;PKCS7#IV=0#LZSS=12,4
60 AES-CBC decrypt and AES decryption followed by See description for #57. In addition,
LZSS decompress LZCSS decompression with see description for AES parameter
variable sliding in chapter 3.2.11.3.
window/repetition length
Table 3-4: Functional overview of data processing methods in “expdatproc.dll”
In many data processing operations not all parameters that are listed above are useful (and
thus not be supported). In some operations, parameters can be optional. The interpretation
of parameters, especially for param1…param4 differs for every data processing operation.
The following chapter strives to provide details on the data processing parameters for
individual operations (like XOR) or group of operations (such as RSA or ECC operations).
Examples may highlight the data processing operations.
There are some general rules that apply to certain types of parameters which will be
explained at next, before describing the individual parameters for the operations in
subsequence sub-chapters.
➢ param1 Provides the main parameter. Since many of the operations require a key,
this parameter provides the key value as an input string in hexadecimal format. Since
some keys are long and since it is also cumbersome to provide them through
commandline interface, this parameter value can be used to reference a file. The
algorithm is, that param1 is analyzed if it is a pure hex string (tolerates to start with
“0x”, all other characters must be ‘0-9’, ‘a-f’ or ‘A-F’). If so, the hex string will be parsed
and converted to binary. The result will be processed as the input value, e.g. as the
main key.
Otherwise, param1 will be interpreted as an input file specifies and an attempt will be
made to read the data from a file. First, the file must exist. At next, all characters will
be read. Carriage return (‘\r’) and newline (\n’) will be removed, as well as any space
(‘ ‘), commas (‘,’) and the value ‘x’. The content of the file will then be used as input.
➢ param1,param2,param3: These three parameters together are used to read data
from an INI-file. If an INI-file exist with the name “param1”, then the tool will try to
extract a parameter from the section specified by “param2” and the key entry
“param3”.
Example: File “abc.ini” contains the values
[test]
MyKey=123456789ABCD
Important
Some data processing parameters are referencing files on the disc. But note, that
Hexview sets the execution path relative to the input file. Thus, relative file references
for data processing parameters are always relative to the input file. This has the
advantage, that the same relative input file references can be used even if the input
files are located on different places (e.g. the signature output file can be located
relative to the input file).
With EXPDATPROC.DLL, V1.02 and higher, it is also possible to pass the parameters not
only directly but through a file or an INI-file. The parameter must be passed as follows:
Passing the parameter through a file:
/DP:input-filename[;output-filename]
Passing the parameter through an INI-file:
/DP:input-filename,sectionname,keyname[;out-filename]
The INI-file has the format:
[sectionname]
keyname=’0011223344’
In every case, an output-filename can be optionally entered, preceeded by a “;”. This output-
filename will overwrite the default output filename.
Please note that all file references within the data processing operation are relative to the
location of the data file that is currently loaded. So use either full path or use relative paths
related to the location of your input file!
The output is always written relative to the location of the Hex-File loaded by HexView.
Expert Knowledge
Methods 17 and 18 for RSA operation are different in behavior depending on the length
of input data and thus somewhat tricky for use. That is to pack several use-cases into
this method.
17 RSA Encryption: If the input data are a multiple of the modulo length, a public key
operation will be applied on each of it. Example: If an RSA512 key is used and the
input data is a multiple of 64 bytes, then the data will be “sliced” into junks of 64 Bytes
and each one will be encrypted separately.
If the data length is not equal to the public key length (typically the modulo length),
Encryption with the public key will be applied according to PKCS#1, V1.5. That is, a
maximum of <RSA-Length> - 12 bytes are taken, 00 02 is added, then filled with (non-
zero) random values, a ‘0’ is added followed by the data. This package is encrypted
with the public key.
18 RSA Decryption: If the input data are a multiple of the modulo length, the RSA
operation will be applied on a try-and-error method. First, PKCS#1, V1.5 decryption
with the public key is applied. If the result does not start with 00 02, then the RSA
operation will be applied without interpretation using the private key.
If the length is not a multiple of the modulo, then the encryption according to PKCS#1,
V1.5 will be applied. Thus, 00 01 will be set, followed by a number of FF and one 00
until the fill value and data provides a multiple of the RSA key length. This data is then
encrypted with the private key.
The data processing operation /DP1 performs XOR operation on the input file. If no
parameter is provided, every input byte will be XORed with 0xFF, means, the values will
simply be inverted. As a parameter you can specify a byte or a list of bytes as a hex string.
Then, the first byte of the input stream will be XORed with the first byte of the parameter,
then the next byte of the input byte will be used for the next byte of the input stream, and
so on. At the end of the parameter input string it will wrap around to the beginning and so
on.
Example
/DP1:1234ABCD
Input: Output:
58 59 5A 5B 5C 5D 5E 5F 7B 13 E6 56 7F 17 E2 52
AES can operate in several modes. Therefore, Hexview provides several data processing
options for each of the modes through “Expdatproc.dll”. It supports the modes ECB, CBC,
CTR and GCM. Besides the <symm-key > necessary for all AES operations, additional
parameters are required depending on the modes, such as an initialization vector or a
padding mode. The following table provides further details on the additional parameter for
the modes.
Use a 32 char hex string if you want to provide a complete and explicit vector. If less
than 32 characters are provided the initialization vector will be padded with 0. Thus,
a parameter like “#IV=0” will set the complete IV to 0.
Example:
/DP11:00112233445566778899aabbccddeeff;PKCS7#IV=
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Note that GCM, CBC and CTR require an initialization vector. If the parameter #IV is
not provided for these modes, Hexview will take the first 16 Bytes of the first input
block buffer (the first 16 Bytes of the HEX-block from the input file) as the
initialization vector. In this case, the Init-Vector will be placed in plain text to the
output data. Subsequent data will be en-/decrypted.
;<padding-mode> ECB, AES itself is a block cipher and therefore requires inputs of blocks of 16 bytes as a
CBC[, must. To encrypt data that is not a multiple of 16 Bytes, some tweaks are required to
CTR] add data to a block that is not a multiple of 16 bytes. In some cases, the mode of
operation does that for you like CTR or GCM, but some are not capable to do that,
such as CBC or ECB. For the latter ones, you either need to ensure to provide an
input that is a multiple of 16 bytes or you can use a standardized padding mode.
Padding according to a standard has the advantage that the encryption operation
adds a set a number of bytes for you to ensure 16-byte block operations on AES.
This padding can be recognized (if supported and activated) during decryption and
the padded data are then automatically extracted. Thus, encrypting of, e.g. 200
bytes will result in a 208 bytes cipher text 3. But decrypting the data will provide you
200 bytes back (if the padding mode is recognized).
Hexview supports three types of padding modes. To activate the padding for the
mode, use the keyword listed below in bold.
• PKCS7: Padding all remaining data with the length value of the padding
data. Example: Padding a block with length of 254 will add 2 bytes at the
end with the value ‘2’ (256-254).
Example:
8899AABBCCDDEEFF
Padded: 8899AABBCCDDEEFF0808080808080808
• RFC1321: First padded byte is 0x80, all remaining bytes are filled with ‘00’.
Example:
8899AABBCCDDEEFF
Padded: 8899AABBCCDDEEFF8000000000000000
• ANSIX.923: All padding data will be filled with 0, except for the last byte that
contains the number of padded bytes.
Example:
8899AABBCCDDEEFF
Padded: 8899AABBCCDDEEFF0000000000000008
Example commandline:
/DP11:00112233445566778899aabbccddeeff;ANSIX.923#IV=0
3The drawback of padding is, when you provide a block that is a multiple of 16 bytes, it will add 16 bytes of
extra data to the cipher. Thus, providing 256 bytes plain data will result in 272 bytes of cipher data.
#TAG=<tag-data> decryption, so that the GCM mode can verify the authenticity of the data.
Additionally, an authentication value can be provided that is typically not part of the
encrypted data. This can be a character string or a HEX-string as input.
For the encryption operation, the <auth-data> is an optional input for GCM and the
<tag-data> is an output. For the GCM decryption, both <auth-data> and <tag-data>
are inputs. The <tag-data> created by the encryption operation must be provided as
input to the decryption operation and the same <auth-data> must be provided as
used during the encryption.
With Hexview, there are three options to provide these input values for operation.
1. Provide the value from the input data (the hex file that is currently loaded by
Hexview) and take the value from the data stream. In this case, the address
and length of the data are specified with a preceding ‘@’ character.
2. Specify the value as a Hex-character string with the commandline.
3. Provide a filename where the data is located in. The file data can be a HEX-
string or can contain binary data4.
Due to the order of the AES-GCM processing operations, corresponding data must
be available at the point in time when the operation shall be performed. The AUTH
data must be first data available at the very beginning of the GCM operation. Thus,
the AUTH data must be provided first. This must be considered when providing the
data from the input data through address and length parameter. In this case, the
AUTH data must be at the very beginning of the data stream. The <tag-data> should
be located at the end of the data stream (especially for decryption) since it is used
for the verification at the end of the input data operation, but can also be placed
somewhere else. Hexview will check continuously the input data stream if the <tag-
data> are part of the input and will copy it (and extract it from the decryption input)
into a separate buffer to perform the check at the very end of the operation.
However, the restriction is, that the <tag-data> can only be located at the beginning
or the end of block or segment, not somewhere in-between.
Note: The tag length is always 16 Bytes.
Example:
/DP55:00112233445566778899aabbccddeeff#IV=0#AUTH=@0x1000,32
#TAG=@0x2FF0,16
/DP55:00112233445566778899aabbccddeeff#AUTH=4155544844415441;tagfile.txt
The tag-data is a result of the encryption operation. Therefore, the tag value can be
placed with the [@placement] operator for the /DP operation (see chapter 3.2.11).
Thus, it is also possible to use this commandline parameter to place the tag output
to a location:
/DP55:@append:00112233445566778899aabbccddeeff#AUTH=4155544844415441
To place the tag data at the very end of a data file.
It can also be written to a file as a hex string. The filename must be added in the tag
field:
4Hexview will analyze the data contents of the file. If the data contain non-ASCII character (characters >=
0x80) it will be considered as binary. Otherwise it will read the input as a HEX-ASCII string input and will
convert the contents into binary for further processing.
/DP55:
00112233445566778899aabbccddeeff#AUTH=4155544844415441#TAG=tag.dat
An HMAC is an authentication code that is calculated over a set of data together with a
secret key over a Message Authentication Code (MAC-) operation. The HMAC code must
be provided together with the data. Anyone who’s in the possession of the HMAC code
and the key can then run the same operation on the data and verifies the result with the
given HMAC value. This provides authentication to the data and that the verified data has
not been altered.
The input the the HMAC is therefore the data itself (as the loaded HEX file or any other
file) and the symmetric key. This key can be provided in several ways.
The easiest way is to provide the key as a HEX string (as “param1”).
The format for HMAC keys according to HIS always starts with FF 59 or FF 5B followed
by a length definition according to the ASN.1 format. Next value must be ‘D3’ followed by
another ASN.1 like length value, followed by the symmetric key itself.
As a summary, the following format is given (all values in HEX):
Example:
0xFF,0x5b,0x12,0xD3,0x10,0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99,0xaa,0
xbb,0xcc,0xdd,0xee,0xff
Commandline: /DP4:FF5B12D31000112233445566778899aabbccddeeff
Hexview tries to read the HMAC key in this format first. If this format cannot be recognized,
the whole hex string will be used as the input to a symmetric key.
Hexview also recognizes the symmetric key from the example above in the following
format:
/DP5:00112233445566778899aabbccddeeff
Note, that for a public key, only the modulus and the publicExponent is needed. The
subsequent elements are then optional and may or may not be present.
For a private key, the privateExponent must be present. All subsequent parameters are
optional and may or may not be present.
If none of the above was successful, Hexview will try to read the Public Key part and will
analyze the MIME file with the tag “-----BEGIN PUBLIC KEY-----” and will try to read it in the
following format:
RSAEncPublicKey ::= SEQUENCE {
OID {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsaEncryption(1)},
Any ::= INTEGER,
rsaKey ::= RSAPublicKey
}
If this was not successful, Hexview will try to extract the RSA keys from the RSAPublicKey
format directly.
If none of the above approaches were successful, Hexview will start to analyze the key as
an X.509 certificate. It will start to check the MIME file if it starts with the tag “-----BEGIN
CERTIFICATE-----”. If so, it will analyze the ASN.1 coding as follows:
This is used to extract the subjectPublicKeyInfo to extract the key material from there.
The AlgorithmIdentifier 1.2.840.113549.1.1.1 is supported.
If none of the checks above provides an RSA key, e.g. because they are not provided as
MIME coded files with the requested tags at the beginning of the file, Hexview tries to read
and analyze the data from the file as HEX-strings or binaries (if the file contains non-ASCII
character). Binary data will be used as-is, HEX-string characters are converted to binary.
The input data will then be checked if they correspond to the encoding rule of
RSAPrivateKey or RSAPublicKey.
There was also a definition for RSA keys by the HIS. Since Hexview is still supports this,
the format shall be described here.
All HIS RSA keys need to start with two bytes as a header tag with the values 0xFF 0x49
or 0xFF 0x4B for private keys or with 0x7F 0x49 or 0x7F 0x4B for public keys. The total
length of the upcoming data in ASN.1 length encoding rule follows directly the two header
byte tags.
The three RSA values for public and private exponent and the modulo are preceded by a
specific tag as follows:
0x81: Tag for the modulo.
The following example provides a 1024 bit RSA key in HIS format with public and private
exponent and the modulo (data values are shortcuted):
FF49 82010a 81 8180 F724…3A83 82 02 9D85 91 8180 afcb…6d8d
There is no real standard available yet for a representation of ECC keys. In the wild,
several key format descriptions have been seen. A few of them are now supported by
Hexview. First difficulty is the MIME decoding and the MIME encoding tag that is used.
The MIME file may start with either “-----BEGIN PRIVATE KEY-----” or “-----BEGIN EC PRIVATE
KEY-----”. In this case, the key information will be interpreted as ECC private key. For the
MIME string “-----BEGIN EC PUBLIC KEY-----” or if the key is extracted from a certificate, it
will be considered as a public key.
Or
ECCKey ::= SEQUENCE {
version INTEGER(0),
algorithmType ::= OID { so(1) member-body(2) us(840) ansi-x962(10045) keyType(2) ecPublicKey(1)},
keyInfoPriv ::= OCTET STRING {
priv_key ::= OCTET STRING}
keyInfoPub ::= OCTET STRING {
pub_key ::= OCTET STRING}
ECC key from certificates can also be used. However, domain specific parameters are not
considered. The certificate must follow this definition:
Or in a reduced form:
A compression flag in the first byte (0x04) will be considered. Also, leading 0’s can be
removed. Points are stored in “little endian” format.
Examples:
NIST curve P(256) public key = X(32) | Y(32)
NIST curve P(192) public key = X(24) | Y(24)
Note
Only one DLL can be active at a time. Thus, if you specify your own DLL, the default
methods are not available.
normal input file. However, if you want to use this option, you cannot read in a normal HEX
file while you are also want to read in HEX-ASCII data. The accepted format is as follows:
23456789
0x12, 0x23, 0x34, …
All data are expected to be in HEX data format. No integers will be recognized.
Typically, the input data will be located at start address 0. An offset can be specified with the
parameter, e.g. /IA:myhexstring.asc;0x1000, which will place the string at address 0x1000.
No data overlapping is allowed with data from the input file! If data overlaps, a warning is
generated and the HEX input is completely ignored.
Hint: Set the filename in double quotes if spaces or other untypical characters are used for
the filename itself.
3.2.18 Import Binary data (/IN:filename[;AddressOffset])
This option can be used to import explicitly a binary data file. This option is used to avoid
the file interpretation algorithm. It corresponds to the “File -> Import -> Import Binary” option
from the GUI.
3.2.19 Execute logfile (/L:logfile)
This option is intended to load a logfile command. Similar to a macro recorder, actions in the
GUI can be logged and later on re-executed using this command line option. Refer to section
2.2.1.7 for further description).
3.2.20 Merging files (/MO, /MT)
One or more files can be merged into the internal data memory of the program. The files are
read using the auto-detect filetype mechanism described in chapter 2.2.1.2.1. The
commandline operation has some optional parameters to control the merge operation.
First, the type of merge operation need to be chosen. The merge can done in a transparent
(/MT) or opaque (/MO) mode. Both cannot be mixed. Only one can be chosen in one
commandline operation.
In the transparent mode, the loaded filedata will not overwrite data in the internal memory.
The opaque mode does not check if data already exist and will load the data from the merged
file unconditionally. Already existing data may be overwritten.
Option extensions: file1[;offset][:’range’][+file2;offset][:’range’]
The filename must be followed directly to the option, separated by either a ‘: or the ‘=’ sign
(/Mx:file or /Mx=file). An optional offset parameter can be added. The offset can be positive
or negative, specified in hexadecimal or integer. In addition, a data range that’s been loaded
from the merge-file can be specified. This can be given with or without the offset. Note, that
the range will be applied on the unshifted data, then the address shift operation will be
applied.
Further files to merge can be added using the ‘+’ character to separate the next file to load.
Example
HexView will merge the file “cal1.hex” with address offset -0x1000, then loads
“cal2.s19” with address offset 128. Existing address information in the internal memory
will not be overwritten.
Example
/MT:cal1.hex;-0x1000+cal2.s19;128
/MO:testfile.hex;0x2000-0x3FFF
Simply reads the address range from 0x2000-0x3FFF from the file “testfile.hex” into the
memory. No offset will be added or subtracted. Existing data on the same address will
be overwritten.
/MT:testfile1.hex;0x2000:0x1000,0x4000+cal2.s19;-0x3000:0x1000-0x1FFF
Merges the address range 0x1000-0x4FFF of testfile1.hex and shifts all block
addresses of these ranges by the offset 0x2000. Afterwards, merges the address range
0x1000-0x1FFF of file cal2.s19 and changes the block start addresses by -0x3000.
Note: /MT and /MO cannot be combined in one commandline. Only the last in the
commandline-list will be used, in that case.
Caution
Since this operation can manipulate data in a post process, make sure HexView
creates the resulting file containing the desired data and applies the correct changes.
GetPBSegmentInfo(Address[], Length[],
maxNoOfSegments)
GetPBData(srcAddress, dstAddress,
length)
ClosePBFile( )
Parameter
Filename Pointer to the location of the file that shall be opened. This is the full-path of
the file that has been selected in the file dialog when slecting the “Apply
postbuild options”.
Return code
Long Number of segments found in the postbuild file and shall be applied to.
Functional Description
Requests to open a file used for the postbuild operation process. Typically, it is the XML file generated by
GENy to apply the postbuild configuration data.
Particularities and Limitations
> The function must return the number of segments that shall be applied to the postbuild operation
Call context
> -
Table 3-6: OpenPBFile
3.2.22.2 ClosePBFile
Prototype
Void __declspec(dllexport) __cdecl ClosePBFile ( void )
Parameter
- -
Return code
- -
Functional Description
Closes the previously opened file. Concludes all operations within the DLL.
Particularities and Limitations
> -
Call context
> -
Table 3-7: OpenPBFile
3.2.22.3 ClosePBFile
Prototype
Long __declspec(dllexport) __cdecl GetPBSegmentInfo ( DWORD address[], DWORD
length[], long maxSegments )
Parameter
Address Pointer to a list of addresses. Will be filled by the operation.
Length Pointer to a list of length values. Each field for one segment. The index
corresponds to the address field.
Long maxSegments Size of the fields where Address and Length points to. The interface function
shall not place more address and length information into the list as specified
by maxSegments (will exceeds internal data structures within Hexview).
Return code
Long Number of segments found in the postbuild file and loaded to the segment
arrays of Address[] and Length[]..
Functional Description
Provides all segments from the postbuild file that shall be loaded.-
Particularities and Limitations
> The function must return the number of segments that has been loaded to the arrays.
> Segments provided in the list of address[] and length[] shall not overlap, length shall be greater than 0 in
all cases (otherwise, the element in the list should be omitted).
Call context
> -
Table 3-8: ClosePBFile
3.2.22.4 GetPBData
Prototype
Long __declspec(dllexport) __cdecl GetPBData ( DWORD srcAddress, char
*dstBuffer, DWORD length)
Parameter
srcAddress Pointer to the segment that shall be read. Corresponds to at least one of
Length the Addresses of addresses. Will be filled by the operation.
Pointer to a list of length values. Each field for one segment. The index
Long maxSegments corresponds to the address field.
Size of the fields where Address and Length points to. The interface function
shall not place more address and length information into the list as specified
by maxSegments (will exceeds internal data structures within Hexview).
Return code
Long Number of bytes read for post-building.
Functional Description
Reads the segment data from the postbuild file and applies it to the current document.
Particularities and Limitations
> The function must return the number of bytes read from the segment.
> The number of bytes read from the segment must correspond to the size previously specified for the
segment that belongs to the address given in the parameter.
Call context
> -
Table 3-9: GetPBData
parameters are separated with the ‘!’ sign. Each keyinfo and signature info can be a
reference to a file. Hexview will take the corresponding information from the file for internal
processing. The keyinfo follows the rule defined with expdatproc (see description of /DP).
Since public keys are typically located in certificates, Hexview will also analyze X.509
certificate files to extract the public key from it. Note that the certificate will only be parsed
to extract the public key, no other details will be checked. It must be provided in a well-
formed format, but a hierarchical chain will not be validated.
Example1:
Hexview myfile.xy /SV6:keyfile.txt! SignD_PSS_SHA256.RSA /s
Hexview returns with 0 if the signature calculation was successful, otherwise returns
with a non-zero value. A text info is also placed into the log file.
Example2:
Creating a signature:
Hexview test.hex –s -dp28:.\rsakeys_2048.txt
if ERRORLEVEL 1 GOTO Error
Verifying the previously generated signature:
Hexview test.hex –s -sv0:.\rsakeys_2048.txt!SignD_RMD160.RSA
if ERRORLEVEL 1 GOTO Error
Example3:
Assuming we have a signed VBF file, Hexview will read the signature from the VBF
and verifies that with the public key given in the PEM file or certificate.
Hexview test.vbf -s -sv6:public_key.pem
Table of the data processing number with the corresponding signature verification number:
Generate Verify Operation
signature signature
/DPx /SVx
28 0 RSA signature (PKCS#1, V1.5) with RIPEMD-160 on data
9 1 RSA signature (PKCS#1, V1.5) with RIPEMD-160 on address, length and
data
8 2 RSA signature (PKCS#1, V1.5) with SHA-1 on data
10 3 RSA signature (PKCS#1, V1.5) with SHA-1 on address, length and data
32 4 RSA signature (PKCS#1, V1.5) with SHA-256 on data
33 5 RSA signature (PKCS#1, V1.5) with SHA-256 on address, length and data
38 6 RSA signature (PKCS#1, V2.2/PSS) with SHA-256 on data
Note
Some export functions from the GUI automatically generates an INI-file with the same
name and path location as the output file, to write these parameters into it. These
values will then automatically taken when reading or converting the file through
commandline.
The path and filename for the INI-file must follow directly the /P parameter, but separated
either with a colon or an Equal sign. No blank character is allowed for separation or within
the file and path name (or use double quotes to specify such file and path names).
Example
/P:testfile.ini
HexView will read the data from the path of the input file. If no explicit path is used for
the input file, HexView will search for the file in its current path.
/P=c:\testpath\testfile.ini
HexView reads the INI-file from the specified path and filename.
5 Such linear address spaces are also called „virtual“ addresses, because the address itself does cannot
directly used for a read operation on the micro. An address calculation of the virtual address is necessary to
split it to a banked and a physical address.
Bank no.
#3
Bank no.
#2
Bank no.
#1 Bank size
Linear base
address
Non- Non-
banked banked
section #2 Bank end section #2
address
Bank no. Bank no. Bank no. „Peep-
#1 #2 #3 Hole“
Bank start
address Non-
Non-
banked
banked
section #1
section #1
/remap:BankStartAddress-BankEndAddress,LinearBaseAddress,BankSize,BankIncrement
Figure 3-6 gives a reference to the parameters of the memory map. The BankStartAddress
and BankEndAddress spans a range of the memory region, where the remap shall be
applied to. The LinearBaseAddress is the base address, where the first BankStartAddress
shall be mapped to. The BankSize is the maximum size of a block that shall be remapped
and the BankIncrement is the difference of address between two banks, e.g. the difference
between BankStartAddress of bank #1 and BankStartAddress of bank #2.
Please note, that just blocks can be remapped, that fits within the BankStartAddress and
BankEndAddress or multiples of BankIncrement. That is to say, only blocks with maximum
size of BankSize can be remapped. A continuous block section cannot be splitted and
remapped into linear addresses (this is not necessary. In that case, only the whole base
address of a block may be shifted).
The following example shows, how address shift operations are applied:
Assuming, the input file contains the following data sections:
Non-Banked addresses from 0x0000 – 0x7FFF.
Banked addresses: 0x018000-0x01BFFF; 0x028000-0x02BFFF.
In this example, the address mapping consists of a non-banked section and two bank
sections. The bank numbers are 0x01 and 0x02. The physical bank addresses are from
0x8000-0xBFFF. The bank size is 0x4000.
The following option will remap the addresses to a linear address space:
/remap:0x018000-0x02BFFF,0x008000,0x4000,0x010000
This remaps the address space in the example above to 0x0000-0xFFFF.
3.2.29 Write version string to error log file (/v)
The Hexview version string is written to the error log file.
Note that you also need to specify the /E:<filename> option in combination to see the string
in this file.
Version string: “Hexview V1.09.02”
3.2.30 Create validation structure (/vs)
This item is used to create an information structure intended to be used for application
validation. It is typically used for flash download systems where it is difficult or impossible to
determine if all elements necessary for a download are available and complete.
There are some flash download procedures, where it is impossible to verify if the download
is completed. For example, if partial download is used without an information in the download
procedure, where the complete download can be verified, or where a download can be
interrupted at a certain state that appears like a completed download.
For a successful usage of the validation structure, it is necessary, some important
precautions must be considered. To use the structure it is necessary to be able to re-program
it with every download, even if it is just a partial download. Before the validation structure
itself can be used, it is necessary to determine if the validation structure is present and
complete. There are three options that can be used in combination to verify if the structure
is complete. A magic value at the beginning and the end can be added to the structure In
addition, a simple byte checksum can be inserted that is added at the very end to the
structure.
The key information for the validation is the block structure containing the segment start
address and length for each segment or block. The data information is not only (and not
necessarily) taken from the internal data but also from external files. A list of files can be
provided in the list box. An optional checksum per block can be added. The checksum
method can be chosen from the available checksum methods from EXPDATPROC.DLL.
Instead or in addition to the block checksum a total checksum that is calculated over all
segment and block data can be added. The total checksum method can be different from
the block checksum.
The resulting data structure can now generated in two ways, or even in both if wanted. First,
a C-structure can be generated that can be compiled and linked together with your program
data. If the data don’t change, the resulting HEX-files should be the same just with the
additional structure added to the HEX-file. A header-file may help you to access the data
structure during the validation method.
A second method is to insert the data directly into the HEX-data file. Since 16-bit or 32-Bit
values are generated, it is important to select if the CPU uses little- or big-endian format.
The 16- and 32-Bit values will be generated according to the selected option.
When using this commandline option, all parameters will be taken from the INI-file (see
section 3.2.26). The contents of the INI-file have the following parameters:
[VALIDATION]
See section 2.2.2.14: “Generate file validation structure” for further information.
Note
Some changes were made to Hexview V1.10.
The validation structure is added as a separate block into the block chain list of the
hexfiles. Before that, it was merged into the file. Thus, the validation structure always
appears as a separate block even if the preceeding block ends at the start address of
the validation structure. Re-Reading the file will merge the blocks.
IDtags are added as is, e.g. a value of 001A will be added as 2-byte value.
Address/length values can be forced as 4-byte values.
Info
A validation structure can automatically be generated when exporting a VBF file. No
separate validation structure generation is needed. There is also no need to create a
separate [validation] section in the INI file. See VBF export for more details (see
chapter 3.3.5).
• The GroupId is taken directly from the INI field (see below).
• N segments reflects the number of blocks of the HEX file (without the block for the
validation structure).
• Address and Length are the start address and length of each block (without the
block for the validation structure).
• Mode is taken directly from the INI file. This parameter applies to all segments.
• Hash is calculated by the tool over the segment data. The parameter
HASH_METHOD in the INI selects which checksum method of the tool are used to
calculate the hash. The default value is 20 (no parameter in the INI file), which selects
SHA-256. The checksum method applies to all segments in the list.
The signature is calculated over the complete validation structure.
The following parameters of an INI file are used:
Default value is 0.
MODE This specifies the mode of all segments. The
following values are valid.
0 = None (Default)
1 = Parallel
2 = Sequential.
Check the documentation to get the meaning.
The value will not be checked. Invalid values
will be written directly to the segment list.
HASH_METHOD This parameter selects, which checksum
method is used to calculate the hash or
checksum over the segment data (see 3.2.10.
for details on checksum methods). Hexview
calculates the hash and places the result into
the segment list.
Note that this method will be applied to all
segments. It is not possible to select individual
methods per segment.
Default value is 20 if parameter is omitted.,
which selects SHA-256.
SIGNATURE_METHOD Specifies which signature method are to be
used to calculate a signature over the complete
validation structure (see 3.2.11. If omitted, no
signature will be calculated.
SIGNATURE_PARAM This specifies the parameter for the signature
calculation (see ‘param’ description in chapter
3.2.11).
Table 3-12: INI file to configure VSHSM.
Example
Hexview.exe sample.hex -p=test.ini -vshsm:@0x70000 -xs -o sample_vs.hex
Test.ini:
[HSMBOOT]
GROUP_ID=0x1234 # Default is 0. Can be hex or decimal.
#MODE=0: None
#MODE=1: Parallel
#MODE=2: Sequential
MODE=1 # Default is 0.
HASH_METHOD=20 # default is 20.
#If SIGNATURE_METHOD is not specified or negative, no signature
will be generated and added.
SIGNATURE_METHOD=39
#If signature is used, SIGNATURE_PARAM is necessary and provides
the private key information.
SIGNATURE_PARAM=private_key.pem
This will generate an HSM validation structure at address $6F.F00 into the s-record file
sample_vs.hex with an RSA-signature of 256 bytes. The INI parameter from the
example above has been taken.
Result:
Example #1
Output HEX ASCII as a number of HEX strings
. /XA:32
0102030405060708090A0B0C0D0E0F10
1112131415161718191A1B1C1D1E1F20
Example #2
Output HEX ASCII in a formatted string using the separator.
/XA:32:”, “
01, 02, 03, 04, 05, 06, 07, 08, 09, 0A, 0B, 0C, 0D, 0E, 0F, 10
11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20
[C_EXPORT] Description
CreateStruct=0 0=Don’t create a structure
1=Create an additional structure and an array
with the size of the number of sections with a
link to the pointer of the array and the size of
the data of that section each.
MaxBlockSize=4294967295; 0xfffffffful Limits the size of one block. If a segment is
larger than this block size, the segment will be
splitted into several blocks.
Don’t use and set this value if you don’t want
to split blocks!
Table 3-14: INI-File definition for the C-Code array export function
Example
HexView test.dat /XC
Reads data from test.dat as Intel-HEX or S-Record and outputs to test.c/test.h. Tries to
read the INI-Info from test.ini in the same folder where test.dat is located.
HexView /XC test.dat /P:myini.ini –o outfile.c
Reads the data from test.dat and the parameter from myini.ini and outputs the file
outfile.c/outfile.h.
APPLICATION>FORD FNOS-DemoIL
MASK NUMBER>7 or later
FILE NAME>APPL.hex
RELEASE DATE>10/05/2001
MODULE TYPE>Restraint Control Module
PRODUCTION MODULE PART NUMBER>XL5A-14B321-AA
WERS NOTICE>DE00E10757919001
COMMENTS>Any comments can be entered here.
RELEASED BY>John Smith
MODULE NAME>RESTRAINTS CONTROL MODULE
MODULE ID>0x7B0
DOWNLOAD FORMAT>0x01
FILE CHECKSUM>0xBF76
FLASH INDICATOR>1
FLASH ERASE
SECTORS>:0xFC0002,0x5716:0xFF9D00,0xC:0xFF9F54,0x8C:0xFF9F54,0x8C
$
:0200000400FCFE
:2000020011AA0001230000BC614E4141000AFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFF1A
…
The whole file format can be written by HexView. The only information that HexView needs
in addition to the data itself are the parameters for the header shown above.
Some information can be generated automatically by the tool. Further information is
necessary and will be given by the INI-file parameter. The parameters from the INI-file are
controlled according to the INI parameter rule (see section 3.2.26).
The base address and length of the erase sections in the “flash erase sections” field will be
aligned with the erase alignment value. See sections 2.2.2.4 and 3.2.3 on how to specify
this value.
The following table shows the INI-information:
[FORDHEADER]
APPLICATION=FORD FNOS-DemoIL Mandatory text field
MASK NUMBER=7 or later Mandatory text field
FILE NAME=APPL.hex Optional If omitted, the file-output name will be
used. Otherwise, the text field paramter is used.
RELEASE DATE=10/05/2001 If omitted, the current PC-date will be used.
Otherwise, if specified, the textfield will be used.
MODULE TYPE=Restraint Control Module Mandatory text field
PRODUCTION MODULE PART NUMBER=XL5A- Mandatory text field
14B321-AA
WERS NOTICE=DE00E10757919001 Mandatory text field
COMMENTS=Henrys header for flashdata Mandatory text field
RELEASED BY=John Smith Mandatory text field
MODULE NAME=RESTRAINTS CONTROL Mandatory text field
MODULE
[FORDHEADER]
MODULE ID=0x7B0 Mandatory text field
DOWNLOAD FORMAT=0x01 Specifies the download method:
0: Download Application file
1: Download SBL
;FILE CHECKSUM=0x0A33 Will be generated by HexView. This is a byte
sum of the data in the datafield.
FLASH INDICATOR=1 0: for Flashdriver aka. SBL,
1: for normal file download
Note: Writes 0 if paramter is omitted.
;FLASH ERASE Can be given as a textual information. If omitted,
SECTORS=:0xF0000,0x4000:0xF4000,0x4000:0x the block sections will be listed. This can be
F8000,0x4000:0xFC000,0x4000:0xFD800,0x0400 used with GGDS and I3 to specify the erase
values (Note: for I3 und GGDS, usually the VBF-
format is used).
Example 1
Output an application file for FNOS 101 (KWP2000 based):
HexView /FR:0x4000,0x200 /XF /P:test.ini /AD2 /AL –o demo_fill1.hex
INI File contents of test.ini:
[FORDHEADER]
APPLICATION=FORD FNOS-Demo DemoAppl, adapted for Bootloader
MASK NUMBER=Must be adapted by TIER I
;FILE NAME=appl.hex ; Will be filled out automatically if not
present.
;RELEASE DATE=02/18/2005 ; dto.
MODULE TYPE=Demo Software
PRODUCTION MODULE PART NUMBER=XL5A-14B321-AA
WERS NOTICE=DE00E10757919001
COMMENTS=This is just an example software
RELEASED BY=John Smith
MODULE NAME=Test software
MODULE ID=0x7B0
DOWNLOAD FORMAT=0x00
;FILE CHECKSUM=0x0A33 ; dto.
FLASH INDICATOR=1
FLASH ERASE SECTORS=0
Example 2
Output an SBL aka. Flashdriver file:
HexView flash_s12.hex /XF /P:flashdrv.ini /FA
INI File contents of flashdrv.ini:
[FORDHEADER]
APPLICATION=FORD FNOS-Secondary Bootloader
MASK NUMBER=Must be adapted by TIER I
;FILE NAME=Flash_S12.hex ; Will be filled out automatically if not
present.
;RELEASE DATE=02/18/2005
MODULE TYPE=Restraint Control Module
PRODUCTION MODULE PART NUMBER=XL5A-14B321-AA
WERS NOTICE=DE00E10757919001
COMMENTS=Henrys header for flashdata
RELEASED BY=Armin Happel
MODULE NAME=RESTRAINTS CONTROL MODULE
MODULE ID=0x7B0
DOWNLOAD FORMAT=0x01
;FILE CHECKSUM=0x0A33
;FLASH INDICATOR=1 Set to 0 if not present
FLASH ERASE SECTORS=
Hexview shows the detected VBF OEM format of the currently loaded VBF in the lower right
corner. The VBF file format is generated when exporting it using the /XVBF output format
option. The VBF requires additional information that is provided through an INI-file.
Note
Due to the wide variety of options in different formats, the GUI export dialog will only
support all parameters up to VBF V2.4. Even though the different VBF versions can be
specified in the dialog, not all VBF parameters are editable in the dialog.
When exporting through the GUI, Hexview writes currently available parameters into
the currently active INI-File. This can be used as a reference to further edit and extend
the INI file.
A validation or verification structure can be useful or is even mandatory for some VBF
versions. Therefore, Hexview can or will generate such a structure automatically if
necessary parameter are provided in the [VBFHEADER] section of the INI-file. Mainly, the
VS_ADDRESS value is needed here along with the BlockChecksumType as listed in the
table below. Other parameters described in section 3.2.30 can be useful here as well and
will be accepted even if they appear in the [VBFHEADER] section.
The values for ERASE_ADDRESS and ERASE_LENGTH will be aligned with the erase
alignment value in a way that erase address and length are a multiple of this parameter. See
sections 2.2.2.4 and 3.2.3 describes on how to specify this value.
Options and data generation is also controlled by an INI-file. The following INI-file
parameters are used to control the output:
[VBFHEADER] Support
in VBF
VBF_VERSION=2.2 Possible values are 2.2, 2.3, 2.4, 2.5, 2.6,
3.0, 3.1 or JLR3.0 (see reference Table
All 3-16).
SW_PART_NUMBER=12345678 *) All Part-number. Any arbitrary text string.
SW_PART_TYPE=EXE Software part type can be:
EXE, DATA, GBL, SBL, CARFCFG,
All CUSTOM, SIGCFG, TEST
SW_CALL_ADDRESS All Only used if SW_PART_TYPE=SBL or TEST.
[VBFHEADER] Support
in VBF
When SW_PART_TYPE is SBL, the call
address is mandatory.
SW_VERSION 2.5, 2.6 The software version.
FRAME_FORMAT=CAN_STANDARD FRAME Format can be:
CAN_STANDARD, CAN_EXTENDED or
2.2, 2.3, 16BIT_STANDARD
2.4, 3.0, DOIP_STANDARD (Ford 3.2)
3.1, 3.2, (16BIT_STANDARD is not allowed in all
JLR3.0, versions, Hexview may not check if it is
5.0 allowed in the version or not).
DESCRIPTION1=This is the demo Description field, part #1.
application for *) All
DESCRIPTION2=the FJ16LX FBL-Ford Description field, part #2
FNOS-I3. *) All
NETWORK=CAN_MS *) Network parameter. Can be:
2.2, 2.3, CAN_HS, CAN_MS, SUB_MOST,
2.4, SUB_CAN1, SUB_CAN2, SUB_LIN1,
JLR3.0 SUB_LIN2, SUB_OTHER
ECU_ADDRESS=0x7E0 *) All ECU-Address
ERASE_LIST_GEN_MODE This specifies how the erase table shall be
generated:
0 = Generate no erase table
1 = AUTO. Each segment of the input file will
correspond to an address range. The values
can be aligned to a multiple of a factor given
with the /AE parameter. This is useful to let
Hexview generate automatically the erase
table.
2 = Manual: You must specify erase address
All and length value in this INI file (see below)!
ERASE_ADDRESS *) Erase address and length information. This
parameter is not allowed if
SW_PART_TYPE=SBL.
All
ERASE_LENGTH *) See ERASE_ADDRESS.
All
DATA_FORMAT_ID >= 2.4 Data format identifier.
DATPROC_PARAM Data processing parameter. Normally empty
if no data processing or just data
>= 2.4 compression is used.
DATPROC_METHOD ID of the data processing method (see
>= 2.4 chapter 3.2.11).
DATPROC_PARAM Data processing parameter. Normally empty
if no data processing or just data
>= 2.4 compression is used.
[VBFHEADER] Support
in VBF
DATPROC_METHOD ID of the data processing method (see
>= 2.4 chapter 3.2.11).
DATPROC_METHOD2 If you need to chain two data processing
operations, the second operation can be
specified with this parameter. For example, if
you want to first compress and then encrypt
>= 2.4 data, this second operation need to be used.
DATPROC_PARAM2 The parameter for the second data
>= 2.4 processing operation if necessary.
SIGNATURE_METHOD Specifies the method to calculate the
signature. A signature parameter
(SIGNATURE_PARAM) is required if
2.6, 3.1 specified as the private key.
SIGNATURE_PARAM=private_key.pem The parameter for the signature generation.
This is typically the private key in PEM
format (use unencrypted PEM keys only!).
HIS key format is also accepted (see chapter
2.6, 3.1 3.2.11).
CSUM_TABLE_STARTADDRESS *) 2.2, 2.3, Checksum table in the VBF header
JLR3.0
CSUM_TABLE_STOPADDRESS *) 2.2, 2.3, See above.
JLR3.0
CSUM_TABLE_CSUM *) 2.2, 2.3, The checksum value for the address range.
JLR3.0
OMIT_ADDRESS *) 2.3, 2.4, Values for the omit values in the VBF header.
3.0, 3.1,
JLR3.0
OMIT_LENGTH *) 2.3, 2.4, The length for the corresponding omit
3.0, 3.1, address value.
JLR3.0
VS_ADDRESS 2.6, 3.1, Validation resp verification structure address
5.0
IdTagBegin=0001 This is a value written to the validation
All structure. It specifies the beginning of it.
Force32BitFormat=1 This value is required. All address and length
values are handled as 32-bit for the
All validation structure.
BlockChecksumType If a validation structure address is present,
this value specifies which checksum method
shall be used to generate a block checksum
All in the validation (or verification) structure.
PUBLIC_KEY_HASH The value for the public key hash. Not used
by Hexview. The content is transferred “as is”
from/to the corresponding item of the VBF-
3.1 header.
CSUM_METHOD Checksum method ID to calculate the root
2.6 hash.
[VBFHEADER] Support
in VBF
SW_CURRENT_PART_NUMBER *) 2.6 Part number(s)
SW_CURRENT_VERSION *) 2.6 Current software version(s)
SW_SIGNATURE_DEV Data processing method ID to calculate the
2.6 signature for development.
SIGNATURE_PARAM_DEV The parameter for the data processing
method ID, namely the reference to the
2.6 development private key.
SW_PART_NUMBER_DID JLR3.0 DID to read the software part number.
LOGICAL_ADDRESS 3.2 Logical address for Ford.
*) The parameters marked with *) can be specified as a single parameter or in a list format.
In the list format, more than one value can be specified for the item. The item name can be
specified multiple times but distinguished with a continuous counter number at the end of
the parameter. The first one starts with ‘1’, e.g. NETWORK1, NETWORK2, are two values
given for the networks. If the iterator name is used, the name without the number will be
ignored (e.g. NETWORK will not be used). It is much more convenient to generate this file
during an export through the GUI than writing this INI-file by hand. Make modifications after
it has been generated.
The following is an example of a Ford VBF3.1:
[VBFHEADER] Description
VBF_VERSION=3.1 VBF version V3.1 (Ford)
SW_PART_TYPE=EXE One of the allowed part types as string.
SW_CALL_ADDRESS= Call address. Omit or leave unset if not allowed for a
certain part type.
DATA_FORMAT_ID=00 The format identifier (e.g. for compressed or encrypted
files.
DATPROC_PARAM Data processing parameter. Normally empty if no data
processing or just data compression is used.
DATPROC_METHOD ID of the data processing method (see chapter 3.2.11).
DATPROC_METHOD2 If you need to chain two data processing operations, the
second operation can be specified with this parameter.
For example, if you want to first compress and then
encrypt data, this second operation need to be used.
DATPROC_PARAM2 The parameter for the second data processing
operation if necessary.
FRAME_FORMAT=CAN_STANDARD One of the allowed frame format specifier.
Description=This is a text file Description field of the VBF (see examples above)
NETWORK=CAN_HS See example above.
ECU_ADDRESS The ECU address (see above)
SW_PART_NUMBER
Example1
Convert an SBL resp. flashdriver
HexView.exe fhasdrv.hex /FA /s /e:cmderrors.err /xvbf /P:flashdrv.ini -o flashdrv.vbf
flashdrv.ini-File:
[VBFHEADER]
VBF_VERSION=2.4
SW_PART_TYPE=SBL
SW_CALL_ADDRESS=0x10000
DATA_FORMAT_ID=16
SW_VERSION=
DATPROC_PARAM=
DATPROC_METHOD=21
FRAME_FORMAT=CAN_STANDARD
DESCRIPTION=abc
NETWORK=CAN_HS
OMIT_ADDRESS=0x12000
OMIT_LENGTH=0x0A00
ECU_ADDRESS=740
SW_PART_NUMBER=3456
ERASE_LIST_GEN_MODE=2
VS_ADDRESS=0x14000
Output of _page3a.vbf:
vbf_version = 2.4;
header {
//**********************************************************
//*
//* Vector Informatik GmbH
//*
//* This file was created by Hexview V1.12.00
//*
//**********************************************************
description = {"abc"
};
sw_part_number = "3456";
sw_part_type = SBL;
data_format_identifier = 16;
network = CAN_HS;
ecu_address = 740;
frame_format = CAN_STANDARD;
omit = { { 0x12000, 0x0A00}
};
call = 0x10000;
file_checksum = 0xf752c33f;
}.
Example2
Convert an application file for Ford VBF V3.1. Validation structure is on address 0x14000.
HexView.exe testsuit.hex /AD2 /AL /s /p:testsuit.ini /xvbf -o testsuit.vbf
testsuit.ini-File:
[VBFHEADER]
VBF_VERSION=3.1
SW_PART_TYPE=EXE
SW_CALL_ADDRESS=
DATA_FORMAT_ID=00
SW_VERSION=
DATPROC_PARAM=
DATPROC_METHOD=0
FRAME_FORMAT=CAN_STANDARD
DESCRIPTION=abc
NETWORK=CAN_HS
OMIT_ADDRESS=0x12000
OMIT_LENGTH=0x0A00
ECU_ADDRESS=740
SW_PART_NUMBER=3456
ERASE_LIST_GEN_MODE=2
VS_ADDRESS=0x14000
SIGNATURE_METHOD=32
PUBLIC_KEY_HASH=AABBCCDDEEFF0011223344556677889900112233445566778899AABBC
CDDEEFF
SIGNATURE_PARAM=.\input\private_key.pem
BlockChecksumType=20;Required!
IdTagBegin=0001
Force32BitFormat=1;required!
ERASE_ADDRESS=0x00009000
ERASE_LENGTH=0x00001000
testsuit.vbf-File:
vbf_version = 3.1;
header {
//**********************************************************
//*
//* Vector Informatik GmbH
//*
//* This file was created by Hexview V1.12.00
//*
//**********************************************************
//Description
description = {"abc"
};
//Software part number
sw_part_number = "3456";
//Software part type
sw_part_type = EXE;
//Format identifier
data_format_identifier = 00;
//ecu_address or list
ecu_address = 740;
//Format frame
frame_format = CAN_STANDARD;
//erase block
erase = {
{ 0x00009000, 0x00001000}
};
//omit block
omit = {
{ 0x12000, 0x0A00}
};
//Start address of the Validation structure
verification_structure_address = { 0x14000 };
//software signature
sw_signature =
{
"726FEBA3A01E479E24419E23D9C1616BB8811F04A1C2BD6ABC5E5CF7F2E0B7
8784FE150B49BBF0B68D94BA6A7CA8CB4180FF69B4142F2D0D960E265743D588A5
5DCE3D75C73B1A0DBF2CF9B596978C916B6F83BDC4F35880FA345E21574A34E04F
161CDF8D4B81F34056BA72C3AB31B9D6459DFB529F2C21D41AB1DE33551FA3E5E6
A31E4CF9750D4EAD2EEF39F334A9FC634F1E426470444F9AB28FE4E98A1EF7E9D7
F69793B3DA238E261CEA12E611A64D4B1767B15D9F6176709918947222F61124CC
C99CE803E66F5EA89F96AE2B3733C75C1F20BC786DF3DD6A2EAADB44F89396F703
EF8F24B756A19ECFD24FD6021FA758524A3E88B2750DE71343AF0B"
};
//Public key hash
public_key_hash =
"AABBCCDDEEFF0011223344556677889900112233445566778899AABBCCDDEEFF"
;
//file checksum
file_checksum = 0xb5c077c7;
}.
Example commandline:
Takes the VBF header information from PlainData.vbf, substitutes the format_identifier
there with 0x20 and replaces the data contents with the contents of
CompressedData.vbf.
The file header can roughly be divided up into two parts, a static part and a dynamic part.
The static part contains information that changes only the version management and
contains, e.g. version information and other file descriptions like module-id, DLS-code and
DCID. The information is static in respect to the compile and link process.
The dynamic data part contains the address and length of all sections of a file and also the
total checksum over all sections. Thus, the dynamic data contents is changing by the
compile and link process and must therefore be adapted after every link process.
The command line options of HexView are therefore adapted to these two stages and can
roughly be divided up into two groups: manipulating the dynamic part within an existing
header of the hex-file or to create the complete header information including the static and
dynamic parts, without the existence of any predefined data.
If only the dynamic part is inserted, the static part must already be present in the loaded file.
In that case, HexView analyzes the static part and checks if enough placeholder has been
reserved to insert the dynamic part. To avoid the risk that HexView accidentally overwrites
important software part data, a unique ID must be written at the very beginning of the header
block. This ID has the value 0x11AA.
If it’s commanded to HexView to create also the static part, the whole header will be
generated. This also implies, that the information of the static part must be given by the
command line options. These options are the /DLS, /SWMI, /DCID and the /MPFH.
This document does not describe completely the format and meaning of the header. You
must refer to GMW3110 for further details.
3.3.7.1 Manipulating Checksum and address/Length field within an existing
header (/XG)
The option /XG is used to command HexView to change the checksum, address and length
information (the dynamic part) within the existing header data fields of the hex-file. It is a
prerequisite, that the header is at the very beginning of a block or a section. The header
must contain all static information like Module-ID, SWMI, DLS and HFI. There must also
already be data as a placeholder for the PMA and the checksum. The placeholder for the
checksum must have the value 0x11AA, the placeholder data for the address and length
information can be of any value.
Note
HexView will overwrite these data during the conversion process. Make sure that no
important data is overwritten. Test the output results carefully!!.
By default, HexView checks the presence of the header on the lowest address of the block.
However, if the header is at the beginning of another block, the address information of this
block can be specified in this command line, separated by the colon.
Example
/XG /CS5 test.dat
Reads in the file test.dat as Intel-HEX or S-Record file and tries to fill in the header
information into the lowest address. The value 0x11AA must be specified there.
Outputs the data into test.bin (GM-binary format) and test.hex (Intel-HEX).
/XG:0x1000 /CS6
HexView searches for the block at address 0x1000. If this is not the first block in the
internal list (e.g. it’s not the lowest address of the block), the block will be moved to the
front. The specified address must be the beginning of a segment or block.
moduleId01.hex /XG /CS6 /MPFH –o myGMfile.bin
The hex-file “moduleId01” contains a header with placeholder 0x11aa for the
checksum, SWMI, DLS, the HFI and a NOAR with dummy address/length information
and optional DCID. It also contains values for the additional modules (NOAM-fields).
Hexview will fill the placeholder 0x11AA with the calculated checksum, will adjust the
NOAR and address/length information from the address fields of “moduleId01.hex” and
then copies the NOAM fields to the end of the last address/length information.
Note
The parameter /CSx must be given when manipulating the header to specify the
checksum method for the checksum value.
If the existing header already contains data for the additional modules (NOAM-data),
the option /MPFH can be specified to let Hexview copy the contents of the NOAM field
adjacent to the end of the new address region. Extensive checks are done internally to
avoid overwriting existing data. Do not use the /MPFH option if you don’t use
calibration information within the GM file.
Besides the presence of the value 0x11AA, the parameter NOAR in the static part must be
equal or greater than the number of sections available in the hex-file. If the NOAR in the
static part is lower, HexView generates an error and does not write the output.
After the NOAR parameter, there must be at least 8*NOAR data bytes within the header,
reserved for the address and length information.
Note
HexView will overwrite these reserved data bytes with the address and length
information of the sections. Also, the value 0x11AA for the checksum will be overwritten
with the result of the checksum calculation value.
Example
myHexFile.hex /XGC /CS5 /DCID=0x8000 /DLS=AA /SWMI=12345678
/MODID=1 /AL /AD4 /MPFH=cal1.hex+cal2.hex –o myGmFile.bin
This will create a full header with all options passed through command line. It
will put the header data upfront to the first block data on the lowest address.
The base address of the header will be shifted down to match the header size.
The data will be filled in to the block. The DCID-field will be added and the flag
in the HFI as well. The NOAM-field will be 2 followed either with the placeholder
or the real data of cal1.hex and cal2.hex. If placeholder or real data are used
depends on if HexView can read the contents of the data from cal1.hex and/or
cal2.hex.
Please note, that a GM-binary file cannot be used as an input file of CAL-files,
as this file doesn’t contain address information.
3.3.7.3 Creating the GM file header for the calibration software (/XGCC[:address])
The option /XGCC is used to create the header for the calibration software. The major
difference is, that the calibration file does not contain the PMA-field for address information
and the NOAR-field. The corresponding PMA-bitfield is not set in the HFI (typically 0x22).
The parameters /DCID, /SWMI, /DLS and /CS are also accepted. The /MPFH parameter
must not be added to the command line.
Example
myCalHexFile.hex /XGCC /CS5 /DCID=0x8000 /DLS=AA /SWMI=12345678
/MODID=2 /FA /AL /AD4 –o myCalFile.bin
This will create a full header with all options passed through command line. It
will put the header data upfront to the first block data on the lowest address.
The base address of the header will be shifted down to match the header size.
The data will be filled in to the block. The DCID-field will be added and the flag
in the HFI as well. A NOAM-field is not allowed in CAL-files. Therefore, the
/MPFH option is not allowed to be used.
Please note, that a GM-binary file cannot be used as an input file of CAL-files,
as this file doesn’t contain address information. However, Hexview will
automatically generate a myCalFile.hex in parallel to the bin-file. Make sure,
that your input file has not the same name as the output file as this will overwrite
your origin.
Note: The option /FA should be used for CAL-files, because CALs are always
single-region files!
Example
/ DLS=AA
The DLS is AA. The HFI field specifies a two-byte DLS field.
/DLS=ABC
The DLS is ABC. The HFI field is set to be a three-byte field.
Example
/modid=1
The module-ID is 0001 in the module-id field
/MODID:0x0051
The Module-ID is set to 81dez resp. 51hex.
Example
/XGC /DCID:32238
/XGCC /DCID=0x8000
In combination with the /XG or /XGC parameter, HexView will scan the files listed in the
parameter field. If they could be found, the address, length and DCID-fields will be extracted
and added to the header information.
Note that the files listed in the MPFH parameter must be single region files. If they contain
multiple sections, an error will be generated and the address/length information will not be
added.
File format: HexView first tries to read the files as Intel-Hex or Motorola-S-Record files. If
this is not possible, that means, if it results in a zero data container, it will try to read it as a
GM-binary file.
In combination with the /XGC option, HexView will create sufficient data information to store
the information for the calibration files.
If this option is added with /XG, Hexview will analyse for existing data of additional modules
and will copy this field to the end of the address- and length field.
3.3.7.11 GM header alignment (/GMAD=val, /GMAL[=val])
The command line options /AL and /AD are generally used to align the data before
processing. The alignment operation is typically applied to the loaded file and, in respect to
the GM header generation, the data are aligned before the header is generated. However,
it might be necessary to provide align information for the GM header only and keep the
binary data as is without the alignment. For this use case, the additional parameters /GMAD
and /GMAL have been introduced. These align values are applied after the header is
generated. Thus, the alignment of the binary data can be separated or even if no /AL or /AD
is provided, the binary data are kept as is.
/GMAD typically provides the align value and is used to align address information. If /GMAL
is provided without an additional length value, the length will be aligned using the length
parameter specified by /GMAD:len. However, the length alignment value can also specified
as a standalone parameter or even with another parameter. Thus, the length value for
/GMAL is optional. The length value for /GMAL is typically used if no /GMAD is specified
(e.g. when only the header length shall be aligned) or when the length alignment shall be
different from the address alignment.
Note that if /GMAL or /GMAD is not specified, but /AL or /AD is specified, the values from
/AL respectively /AD will be used for the header alignment (for backward compatibility).
3.3.7.12 Signature version (/sigver=value)
With Global Bootloader specification V2.2, GM introduces signature verification within the
Bootloader. The GM-header requires to contain signature information that the Bootloader
will use for signature verification. These values are the signature version, the signature key
ID and the signature itself. With Hexview V1.08.00, it is possible to generate this information
in the header file.
One essential parameter for hexview is the signature version. This value is placed into the
header at the required position and is passed to Hexview with this option. The value can
either be an integer or a HEX-number. Example #1 (integer value): /sigver=12345678.
Example #2 (hex value): /sigver=0x12345678.
The signature version is a 4 byte value in the header.
Note, that the parameter /DP must be used in conjunction with this parameter to instruct
Hexview to calculate the correct signature. Normally, the /DP parameter outputs the
signature value into a file. But here with this option, Hexview will place the results into the
corresponding position of the header within the data.
If this option is given, Hexview outputs a concatenated file without the signature. It is the
exact same output, but without the signature itself. So, this file can be given to GM to let
them generate and insert the signature with real keys.
3.3.7.13 Signature Key ID (/sigkeyid=value)
This option is also required for the signature header generation. It provides the key ID
information used for the signature calculation. It identifies uniquely the private/public key
combination for the signature. The value can be given in HEX or integer format, similar to
the sigver option. The value will be placed as a 2-byte value into the corresponding location
of the header.
3.3.7.14 Generate Routine header (/XGCR[:header-address])
This option is similar to the /XGC, but generates a header suitable for the routines, e.g.
flashdriver, etc. The major difference is, that the start address will not decrease while the
header is placed upfront. Instead, the header is placed at the same start address where the
routines itself are placed to . This is because the Vector bootloader does use the start
address of the header as the start address for the code itself and will use the header
information only for internal processes but will not locate this into the memory (typically
RAM).
3.3.7.15 Generate key exchange header (/XGCK)
This option is used to generate a key exchange file. It contains only the header and signature
information. The data after the header contains the new public key information for
proceeding signature values.
Note, that the signature must be built from the previous keys, not the new key!
3.3.8 Output a VAG specific data file (/XV)
This option generates an SGM-file that can be used for the VAS-tester. The file is generated
as described in section 2.2.1.9.14.
The VAG-export also requires parameters from an INI-file as described in section 0.
Example
HexView testappl.mhx /XV /P:vagparam.ini –o demoappl.sgm
Example
HexView anyfile.hex /XI:32 –o intelhex.hex
Hexview myhexfile.S19 /s /xi:16:2 –o myihex.hex
Example
HexView intelfile.hex /XS:32 –o srecord.s19
Hexview myhexfile.S19 /s /xs:16:2 –o mysrecord.s3
Examples
The following examples show the settings in the INI-file to generate GAC file with
corresponding header information:
Example #1: GAC File V2.3
[GACHEADERINFO]
DCID_0=0x00
DCID_1=0x01
DCID_2=0x00
SoftwareVersion="123"
SoftwarePartNumber="1234567890ABCD"
AppOrCalVersion="123"
EcuCodeAndSupplierId="123456789"
Caution
Please note, that Hexview generates an INI file when recognizing and opening a GAC
file. The contents of an existing INI file can be overwritten.
The required information will take the tool from an INI-file. The corresponding format and
item is listed in the example above.
Besides this information, the GAC header also includes the address and length information
and the number of address/length info. Thus, the GAC binary file header contains three
sections:
• The GAC software information
• The number of address/length, the address and length itself
• The data of the file.
We distinguish two file formats, the GAC file with complete information of all three sections,
which is typically for the program and calibration files, and the file for the software interlock
(SWIL, sometimes also called as the “flash driver”).
The flash driver itself has no GAC software information and consists only of the two parts,
the address/length info and the binary data itself. Note that the SWIL should have just one
region, so it should start with the binary value ‘01’ as the first byte.
The SWIL file can only be generated through the commandline with the option /xgacswil,
whereas the standard GAC file can be generated through the commandline or with “File ->
Export -> GAC Binary File”. For the latter one it is required, that the corresponding INI-file
contains the valid entries (see example in this section). The option “/xgacswil” does not need
an INI and does not use any of the header information.
Please note, that only GAC files that contain software information are recognized as GAC
files (for AUTO filetype recognition). A GAC SWIL-file will always be recognized as a binary
file.
The following INI file describes the parameter for a CBF-file V1.0.0:
[CBFHEADER]
CBF_VERSION=1.0.0
ECU_NAME=BDM
SW_PART_TYPE=ASW1
FLASH_PACKAGE_TYPE=MCU
HW_PART_NUMBER=802000193AA
HW_PART_NUMBER_DID=0xF187
SW_PART_NUMBER=null
SW_PART_NUMBER_DID=0xF013
SW_VERSION=00.00.02
SW_VERSION_DID=0xF188
SYSTEM_SUPPLIER_IDENTIFIER=9JQ
SYSTEM_SUPPLIER_IDENTIFIER_DID=0xF18A
DATA_FORMAT_IDENTIFIER=0x00
FLASH_SEQUENCE=EEA4.0
DIAGNOSTIC_COMMUNICATION_TYPE=CAN
FLASH_TYPE=UDS
TRANSMIT_CAN_DL=8
HASH_ALGORITHM=SHA256
RSA_ALGORITHM=
ECU_PARALLEL_FLASH_SEQUENCE_ID=0x01020001
TESTER_REQUEST_CAN_ID=0x760
ECU_RESPONSE_CAN_ID=0x770
EXTERNAL_TESTER_DOIP_LA=
INTERNAL_TESTER_DOIP_LA=
ECU_DOIP_FUNCTIONAL_LA=
ECU_DOIP_LA=
ECU_IP=
ECU_MAC=
SECURITY_ACCESS_ALGORITHM=SA_2
FILE_INTEGRITY_CHECK=sw_CRC
CRC_table=
VERIFICATION_BLOCK_ROOT_HASH=
ERASE_LIST_GEN_MODE=
ERASE_ADDRESS=
ERASE_LENGTH=
BLOCK_HASH_ADDRESS=
BLOCK_HASH_LENGTH=
DATPROC_PARAM=
DATPROC_METHOD=
DATPROC_METHOD2=
DATPROC_PARAM2=
SIGNATURE_PARAM=
SIGNATURE_METHOD=
The INI-file for CBF V1.1.0 is similar to V1.0.0, but does not support the BLOCK_HASH
anymore.
The following INI-file describes the parameters for the CBF V2.0.0:
[CBFHEADER]
CBF_VERSION=v2.0.0
ECU_NAME=CGW
ECU_TYPE=0
AREA_AB_ENABLE=0
AREA_INFO=A
SW_PART_TYPE=ASW1
FLASH_PACKAGE_TYPE=MCU
HW_PART_NUMBER=802000193AA
HW_PART_NUMBER_DID=0xF187
SW_PART_NUMBER=131000152AA
SW_PART_NUMBER_DID=0xF013
SW_VERSION=00.00.02
SW_VERSION_DID=0xF188
SYSTEM_SUPPLIER_IDENTIFIER=9JQ
SYSTEM_SUPPLIER_IDENTIFIER_DID=0xF18A
DATA_FORMAT_IDENTIFIER=0x00
FLASH_SEQUENCE=EEA4.0
DIAGNOSTIC_COMMUNICATION_TYPE=Eth
FLASH_TYPE=UDS
TRANSMIT_CAN_DL=8
HASH_ALGORITHM=SHA256
RSA_ALGORITHM=RSA2048
ECU_PARALLEL_FLASH_SEQUENCE_ID=0x01020001
TESTER_REQUEST_CAN_ID=0x760
ECU_RESPONSE_CAN_ID=0x770
EXTERNAL_TESTER_DOIP_LA=
INTERNAL_TESTER_DOIP_LA=
ECU_DOIP_FUNCTIONAL_LA=
ECU_DOIP_LA=0xE400
ECU_IP=192.168.69.21
ECU_MAC=18:CF:24:00:00:03
SECURITY_ACCESS_ALGORITHM=SA_2
FILE_INTEGRITY_CHECK=sw_CRC
CRC_table=
VERIFICATION_BLOCK_ROOT_HASH=
ERASE_LIST_GEN_MODE=
ERASE_ADDRESS=
ERASE_LENGTH=
BLOCK_HASH_ADDRESS=
BLOCK_HASH_LENGTH=
DATPROC_PARAM=
DATPROC_METHOD=
DATPROC_METHOD2=
DATPROC_PARAM2=
SIGNATURE_PARAM=
SIGNATURE_METHOD=
SYMMETRIC_ALGORITHM=HMAC-SHA256
FILE_PATH=/tmp/download/2-app-b.zip
4 EXPDATPROC
HexView provides an open interface for data processing and checksum calculation. The
interface is realized by a DLL, called EXPDATPROC.DLL (EXPorted DATa PROCessing).
This item describes how HexView calls these functions.
GetChecksumFunctionCount()
GetChecksumFunctionName()
Figure 4-1: Build the list box entries for the GUI
After the method has been selected, HexView runs the calculation in three steps. First, it
initializes the calculation, runs the calculation by passing the data block wise to the DLL and
then concludes the calculation.
Init and Deinit has the purpose to construct and destruct a context sensitive data section.
This section is passed to the calculation together with the data.
The function GetChecksumSizeOfResult() has been introduced to check the length of
the results of the checksum calculation. This allows HexView to prepare the data container.
It also allows HexView to spare the address section where the checksum calculation shall
be placed to.
The following diagram shows the message flow when processing the checksum calculation
method:
An error code can be passed to HexView during the calculation. HexView asks for the text
description in a separate function. This error text description is then shown in the error report.
GetChecksumSizeOfResult(methodIndex)
InitChecksum(TExportDataInfo)
DoCalculateChecksum(TExportDataInfo,CSumActionBegin)
RepeatPerSection
DoCalculateChecksum(TExportDataInfo,CSumActionDoData)
DoCalculateChecksum(TExportDataInfo,CSumActionEnd)
The diagram above shows the function interface and the message sequence chart. The
function DoCalculateChecksum with the parameter CSumActionDoData is called
several times. Typically, once per section. The segInData contains the pointer to the section
data, dataInLength specifies the length of the data, and dataInAddress contains the base
address of the section.
Note
segInData is a pointer to the internal data buffer of HexView. The function can therefore
operate and destroy the data. Be careful not to write to any location where segInData
or segOutData points to in the DoCalculateChecksum() function.
After the calculation has been completed, the DoCalculateChecksum function is called
the last time, but with the parameter CSumActionEnd. The segOutData must contain pointer
to the data buffer, that holds the checksum. The segOutLength specifies the number of bytes
in segOutData. The segOutAddress parameter is not used and ignored here.
5.1 Glossary
Term Description
HEX-Files Any file that is stored in Intel-HEX or Motorola S-Record format.
> Address Region Area of coherent data that can be described by a start address and length
of data.
> PMA
> Section
> Block
> Segment
5.2 Abbreviations
Abbreviation Description
PMA Programmable memory address
6 Contact
News
Products
Demo software
Support
Training data
Addresses
www.vector.com