Detailed description of the two commonly used hexadecimal file formats for programming UCD3xxx series digital power controllers: X0 and Intel Hex

1 X0 and Hex file formats

X0 and Hex files are ASCII (American Standard Code for Information Interchange) text files consisting of lines of text that conform to the corresponding file format. In computers, all data must be represented by binary numbers when stored and calculated. For example, 52 letters such as a, b, c, d (including uppercase), numbers such as 0, 1, and some commonly used symbols (such as *, #, @, etc.) must also be represented by binary numbers when stored in the computer. ASCII code is used to represent these letters, numbers and symbols. It uses a specified combination of 7 or 8 bits of binary numbers to represent 128 or 256 possible characters. X0 and Hex file formats use ASCII code to represent binary information.

The name of the X0 format is "Tektronix Extended hexadecimal file format" and the specific format is shown in Figure 1.

Figure 1 : X0 file format

X0 file uses the percent sign "%" as the record mark, indicating the beginning of a line; the record length refers to the number of characters (not bytes) in each line except the percent sign, which occupies one byte; the record type occupies one character, and there are two types: 6 - represents data, and 8 - represents the end; the checksum is the checksum of the entire line of characters (note that it is not a byte) except the checksum itself and the percent sign, which occupies one byte; the address has a total of 9 characters, the first character is 8, which means that the address occupies a total of 8 characters, and the following 8 characters (4 bytes) are the address to be loaded with data; data is program code or other information.

Take the commonly used computer "Hello, Word! (with line break)" as an example. If it is loaded to address 0x006B, then the X0 file is as follows

express:

%2A6DE80000006B48656C6C6F2C20576F726C64210A

%09819800000000

There are many types of Hex file formats. This article mainly introduces the "Intel Hexadecimal object file format", the specific format is shown in Figure 2.

Figure 2 : Hex file format

Intel Hex files use a colon ":" as a record marker, indicating the beginning of a new line; the record length occupies one byte, which refers to the number of bytes of actual data or information contained in each line; the load offset occupies two bytes, which is a relative address (the load offset plus the extended linear address is the absolute address); there are 6 record types, namely: 0-data record, 1-end of file record, 2-extended segment address record, 3-starting segment address record, 4-extended linear address record, 5-starting linear address record; the data part of each line record is variable, and can be up to 255 bytes, or it may not be, depending on the type of record. The last one is the checksum, which is the checksum excluding the colon and the checksum itself. The specific method is to accumulate each byte, and then take the complement of the last byte of the calculation result (negate and add 1) as the check byte.

Let’s take “Hello, Word! (with line break)” as an example. Load it to address 0x0000. The Hex file is as follows:

:0F00000048656C6C6F2C20576F726C64210A7E

:00000001FF

2 UCD3xxx storage structure

Figure 3 : UCD3xxx memory structure

Before introducing how to generate X0 and Hex files, you need to first understand the storage structure of the UCD3xxx series digital controller, as shown in Figure 3. UCD3xxx has three modes: reset mode, ROM mode, and Flash mode. The storage mapping corresponding to these three states is different. In reset mode, all memory is mapped to ROM; in ROM mode, the program flash is mapped from 0x10000 to 0x17FFF, the data flash is from 0x18800 to 0x18FFF, and the random access memory (RAM) is placed from 0x19000 to 0x19FFF; in Flash mode, the data and random access locations remain unchanged, and the program flash location is remapped to 0 to 0x7FFF. The last 4 bytes of the program flash are the checksum of the entire program flash.

The UCD3xxx startup process is: enter the reset mode after power-on; enter the ROM mode after power-on, and the chip will automatically jump to 0xA000 for execution. In the address range from 0xA000 to 0xAFFF, a ROM program is solidified. In addition to some chip initialization, this program will also calculate the checksum of the program flash memory, and then compare it with the checksum saved in the last 4 bytes of the program flash memory. If they are inconsistent, the program will stop and wait for the host command. If the comparison results are consistent, the chip will enter the Flash mode, and the ROM program will execute the jump instruction to enter the program flash memory for execution.

3How to generate X0 and Hex files in CCS integrated development environment

Figure 4 : CCS compiler compilation option settings

The generation of X0 and Hex files is inseparable from the format conversion programs: Hex470.exe and FusionX0ToHex.exe. Hex470.exe is a program that comes with the assembly language toolkit. FusionX0ToHex.exe is a conversion program that comes with the TI Digital Power Designer graphical user interface (GUI). Hex470.exe and FusionX0ToHex.exe can be called using the command line. The following describes their respective command formats.

The command line format of Hex470.exe is: Hex470 [options] filename, hex470 is the command to call the conversion program, options are additional information to control the conversion process (for details, please refer to reference 2), and filename refers to the name of the input file. Hex470 can convert files with the suffix Out generated by CCS compilation into Hex files of various formats, such as:

Hex470 –i sample.out

This command converts the generated sample.out file into an Intel Hex format file named sample.hex.

Hex470 –x sample.out

This command converts the generated sample.out file into an X0 format file with the file name sample.x0.

Since Hex470 can directly convert Out files into Hex files, why do we need to convert them into X0 first and then into Hex files? There are two reasons: Hex470 does not calculate the checksum of the program flash memory; the Hex file address generated by Hex470 is based on the program flash memory mode, and the address required by the burner is ROM mode, that is, from 0x10000 to 0x17FFF, so UCD3xxx does not support the Hex file directly generated by Hex470. It is necessary to use the FusionX0ToHex.exe conversion program to convert the X0 file into a Hex format file. The specific command format is:

FusionX0ToHex       --infile x0-file

--format intel|srec|hexdump

--pflash-checksum calc|none|source

--export pflash|dflash|both|source

--outfile hex-file

--infile mainly specifies the input X0 file.

--format mainly specifies which Hex format to generate, which are intel, srec (Motorola S-Record) and hexdump.

--pflash-checksum mainly specifies the verification mode of the program flash memory. calc mode - calculates the check bit based on the X0 file and writes it to the corresponding position; none mode - the check bit defaults to 0xFFFFFFFF; source mode uses X0's own check bit.

--export specifies which part of the storage to export. pflash means exporting only the program flash memory. dflash means exporting the data flash memory. both means exporting both the program and data flash memory. Regardless of which part, if X0 does not exist in the file, fill it with 0xFF. source means exporting X0 directly.

--outfile specifies the output Hex file name.

The following describes how to embed hex470 and FusionX0ToHex command lines in the CCS compilation environment.

In the CCS (version 3.x) compilation environment, enter the Project menu, then select Build Options, and then click the General tab, and the interface shown in Figure 4 will appear. In the Final build steps, we can enter the following two command lines:

hex470 -x -memwidth 8 .\debug\FB_48V_HS.out

FusionX0ToHex --infile FB_48V_HS.x0 --pflash-checksum calc --export both --format intel –outfile FB_48V_HS.hex

In the first command: -x option means converting .\debug\FB_48V_HS.out into X0 file, -memwidth 8 defines the system memory word width as 8 bits.

Figure 5 : Generated X0 file ( UCD3xxx )

Figure 6 : Generated Hex file ( UCD3xxx )

In the second command: the input file to be converted is FB_48V_HS.x0, the output file is FB_48V_HS.hex, the check bit of the program flash is calculated, and the program and data flash contents are output at the same time, the format is Intel hexadecimal.

4 Further understanding of X0 and Hex file formats based on UCD3xxx

To further understand the X0 and Hex formats, let’s take a look at the specific X0 and Hex files generated by the UCD3xxx hard-switch full-bridge evaluation board software, as shown in Figures 5 and 6.

The first column of Figure 5 starts with a percent sign; the following two columns (one byte) indicate the length of characters in each line except the percent sign, and the maximum number of characters in each line is 0x4E (78); then one column indicates the data type, except for the last line which is 8 (end), the others are all 6 (data); the next two columns are the checksum of the entire line; the address occupies 9 columns, starting with 8, and the following 4 bytes represent the actual address; the address is followed by data. As can be seen from the figure, the address of the program flash memory of the X0 file starts from 0, and there is no checksum of the entire program flash memory. TI burning software and tools mainly use files in the X0 format. The burning software will calculate the checksum of the program flash memory by itself, and then write to the last 4 bytes, so X0 does not need to calculate the checksum of the entire program flash memory.

The first column of Figure 6 is all colons; the following byte refers to the number of bytes of data contained in the entire row; two bytes are offset addresses; one byte refers to the record type; and then there are data of varying bytes. The last byte is the checksum for each row. The first row of Figure 6 specifies the extended address, which is 0x0001; the last row marks the end of the file. In addition, the last 4 bytes of the program flash memory (pink area) are the checksum of the entire program flash memory. If this checksum is incorrect, the program will not jump to the program flash memory for execution.

5. Summary

If you use the burning software (GUI) and tools (USB adapter) provided by TI to burn, you only need files in X0 format; if you use a third-party burner to burn on the production line, you will need files in Hex format. You can generate the required X0 or Hex files according to the introduction in this article.

6 References

1．SLUS868D - Digital Power Controllers, Texas Instruments Inc., 2012

2．SPNU118J - ARM Assembly Language Tools v4.9 User's Guide, Texas Instruments Inc., 2011

3．SRecord V1.59- Manipulate EPROM load files, 2012

4．Fusion Digital Power Designer, Texas Instruments Inc., 2012