DSP56858 self-boot technology of dual-chip system

Aguilera

DSP56858 self-boot technology of dual-chip system [Copy link]

1 Introduction

With the increasing application of DSP in communication, control, test/measurement, electronic entertainment and other fields, DSP technology is developing faster and faster, and the self-boot technology of ROMless DSP chip has become one of the important technologies in DSP application. In a single-chip working system, if there is not enough ROM space in the chip, a ROM chip can be connected externally in the usual way; but for a dual-chip working system, if one chip can provide enough ROM space for the other, it is unnecessary to add an external ROM. This article analyzes the principle of DSP56858, analyzes the self-boot program solidified in the chip, discusses the technical process and key points of several source program downloads, proposes a self-boot solution for ROMless DSP chip in a dual-chip working system, and finally gives the functional implementation of DSP56858E self-boot mode.

2. Design

In DSP application development, it is often necessary to use some external bootstrap functions provided by the chip. Usually, the self-bootstrap mode provided by the chip can be selected according to different needs to realize the import of programs from the external ROM. Most of the current software development tools are integrated development tools, which integrate multiple functions such as compilation, linking, debugging and burning, and can provide users with convenient and integrated services. In this development environment, the target code generated by the link, in addition to the binary code corresponding to the source code, also adds many control codes, so that users can perform real-time online debugging of the downloaded program. To this end, the problem of realizing the self-bootstrap of ROMless DSP chips can be decomposed into two levels: first, how to extract the source code from the target code and download it to the external ROM, and second, how to use the self-bootstrap program solidified in the chip to realize external booting. This article takes the DSP56858 chip as an example to study the self-bootstrap of ROMless DSP chips. Combined with practical applications, it introduces the problems that may be encountered, proposes solutions, and realizes its functions. The application example scheme of this article uses MC9S12DP256 (hereinafter referred to as HCS12) as the main chip in the design, and DSP56858 is the auxiliary chip for building a test platform. The connection block diagram is shown in Figure 1. The scheme makes full use of the sufficient Flash EEPROM space in HCS12 chip, uses its Flash as the external Flash memory of DSP56858, and stores the source code of DSP in HCS12 in the form of data.

2.1 Basic information of DSP56858

(1) A 16-bit digital signal processor from the Motorola DSP56800E chip family.

(2) A set of peripheral devices are integrated on a single chip, combining the processing power of a DSP with the functions of a microcontroller, providing users with a low-cost solution.

Figure 1 Schematic diagram of the connection between DSP56858 and HCS12

(3) The dual Harvard structure with separate program memory and data memory can achieve an instruction execution speed of 120MIPS and a highly efficient pipeline instruction execution method.

(4) The chip has 40K×16-bit program RAM, 24K×16-bit data RAM and 1K×16-bit ROM to store the boot program; external expansion can reach 2M×16-bit program and 6M×16-bit data storage space.

(5) Provides a powerful system interface:

——6 channels of DMA (Direct Memory Access)

——2 ESSI (EnhancedSynchronousSerialInterfaces)

——2 SCI (SerialCommunicationInterfaces)

——1 SPI (SerialPortInterface)

——8-bit parallel host interface (ParallelHostInterface)

(6) Provides developers with an EOnCE (Enhanced On-chip Emulation) module and a JTAG (Joint Test Access Group) interface; under certain debugging environments, the contents of registers, memory, or on-chip peripherals can be observed online, avoiding sacrificing any user-accessible on-chip resources for debugging.

2.2 Basic information of HCS12

(1) Belong to the STAR12 series 16-bit microcontroller;

(2) Low cost, low power consumption, widely used in communications and various electronic products;

(3) 40MIPS instruction execution speed;

(4) There are 256KB Flash EEPROM, 4KB EE-PROM and 12KB RAM on the chip;

(5) The Flash is divided into 16 pages (page 0×30 to page 0×3F), each page is 64KB, and the entire Flash space can be addressed by 16 address lines combined with the page address.

2.3 Software Integrated Development Environment

The software integrated development environment used by DSP56858 and HCS12 is Metrowerks' CodeWarriorIDE. CodeWarriorIDE is easy to use and powerful. It integrates C/C++ compiler, assembler, linker, burner, decoder and multi-purpose debugger. It can simulate and debug embedded applications in real time and simulate hardware for different chips, so that users can design and develop in a pure software environment.

3 Source code download technology

3.1 Target program code merging mechanism

3.1.1 SRecord file format

With proper configuration, CodeWarrior's linker can generate an SRecord file, which follows the format specification established by Motorola and is a standard, printable file. The SRecord file is generated by encoding the target program or data generated by the linker. It is suitable for transmission between computer platforms, and can also be used for transmission between cross-platforms after editing. The SRecord file is simply encoded and can be downloaded through the IDE, but it cannot be debugged online in real time. The SRecord file consists of multiple records, each of which is an ASCII string consisting of 5 fields.

(1) Record type

　　It consists of two characters, describing the possible type of the record (from S0 to S9);

(2) Record length

　　It is a pair of ASCII characters corresponding to a 2-byte hexadecimal number, indicating the number of subsequent character pairs in the record;

(3) Address

　　It consists of 4 to 8 characters, which are also ASCII characters translated from hexadecimal values, giving the address where the data field will be stored in memory;

(4) Data

　　Pairs of ASCII characters are obtained by translating each 2-byte hexadecimal value. These hexadecimal values may be data stored in the memory or description information;

(5) Checksum

　　The corresponding hexadecimal values are obtained by adding the opposite of the sum of the characters in the other fields except the record type in pairs.

(6) Line break

　　Each record is terminated by a line break character. For different target devices, the end characters of each record may be different. The design uses the transmission program to provide consistent line breaks.

All SRecord files have a record of type S0 as the first record. This record gives the file information in the data field, including the path, version number, etc. This information is for reading and will not be stored in the memory. The middle record of the SRecord file may be a record of type S1, S2 or S3, whose address fields correspond to 2-, 3-, and 4-byte addresses respectively. Therefore, the main difference lies in the addressing space. The SRecord file has a record of type S7, S8 or S9 as the last record. Except for the different lengths of the address field, they all give the starting address of the program execution and do not contain a data field.

3.1.2 Typical format of SRecord files

(1) The typical format of the SRecord file of DSP56858 contains 1 S0 record, 3 S3 records and 1 S7 record.

S0 record: Record 3 type S0, record length 0C means there are 12 (0x0C) ASCII character pairs following;

The first S3 record: record type S3, record length 25 means there are 37 (0x25) ASCII character pairs following;

S7 record: Record type S7, record length 05 means there are 5 (0x05) character pairs following.

(2) The typical format of the SRecord file of HCS12 contains 1 S0 record, 1 S1 record, two S2 records and 1 S9 record.

Due to the different addressing spaces, the SRecord file of HCS12 uses a different record type than the SRecord file of DSP56858, but the analysis methods of the two are basically the same.

S0 record: record length is 6 (0x06) character pairs, 4 characters of all-zero address field;

S1 record: The record length is 35 (0x23) character pairs;

S2 record: The record length is 21 (0x15) character pairs;

S9 record: The record length is 3 (0x03) character pairs.

3.1.3SRecord file merging mechanism

It can be seen that since the two files use different record types, a new SRecord file cannot be generated by simply inserting them. However, since the SRecord file format is simple and clear, a simple standard C program written in the VC environment and using the file operation library functions provided by ANSI C can integrate the two SRecord files into a new HCS12 SRecord file according to the following method.

The SRecord file of DSP56858 is processed record by record: read out the data field, then add the corresponding type, length and address fields according to the address of the HCS12Flash to be inserted, and finally calculate the checksum to obtain a record that meets the SRecord file format requirements of HCS12. Note that each record should be followed by a corresponding line terminator. In this way, the assembled record can be inserted into the corresponding position of the original HCS12SRecord file. After downloading the synthesized SRecord file using the integrated burner of CodeWarriorIDE, it can be observed from the real-time debugging environment that the DSP56858 source code has been successfully written into the specified HCS12Flash space.

3.2 Source code serial port download mechanism

Although the merging mechanism is simple, it requires that the integrated development environments of both chips can provide files generated by target codes that meet the standards. The mechanism of downloading source code using the serial communication interface (SCI) overcomes this shortcoming.

3.2.1 Technical methods

(1) Add a program (hereinafter referred to as the source code output program) to the source program of DSP56858. This program is responsible for reading the program code (including the source program and the output program) in the DSP program memory and passing the read program code to HCS12.

(2) At the same time, the receiving program running in HCS12 will receive the data received from the SCI interface and write it to the specified Flash address unit.

(3) In terms of hardware, connect the SCI interfaces of both parties, configure a unified baud rate, and transmit data in the format of 1 start bit, 8 data bits, 1 stop bit, and no parity check.

(4) The source code output program only works during the output process. This section of code should be shielded when running the source program. Therefore, a pin signal of the general purpose input/output interface (General Purpose Input/Output) can be used as a judgment mark to determine whether this section of the program works according to whether the signal is high or low.

3.2.2 Download process

In terms of software, in order to ensure that the program code transmitted by DSP can be received quickly and accurately by HCS12, a simple transmission protocol needs to be developed to support communication between the two parties.

3.2.3 Retransmission and verification mechanism

A retransmission and verification mechanism is added during the sending and receiving process. Both parties reserve a control character for communication synchronization. As the data output party, DSP56858 should try to reduce the extra overhead to ensure the efficiency of data output. In the design scheme, the control word is sent by HCS12, and DSP56858 waits for reception. After each fixed-length program code is transmitted by DSP56858, the sum of the code is sent, and then enters the waiting state; at the same time, after each fixed-length code is received by HCS12, the sum of the code is calculated in the same way. If it is equal to the received sum value, the code can be written into Flash. Regardless of whether the comparison result is equal, HCS12 will send the obtained sum value to DSP56858 to notify DSP56858 to continue transmitting. DSP56858 will decide whether to retransmit the next code segment based on the sum value returned by HCS12. Although this retransmission and verification mechanism is simple, the experimental results show that it can effectively avoid errors, losses, and error propagation that may occur during the sending and receiving process.

3.2.4 Flash Programming and Erasing

Although the system flexibility and reliability of Flash memory are significantly improved compared to EPROM, there are still strict step requirements for the operation of Flash. Only by following these requirements can Flash be programmed and erased correctly.

(1) First, configure the Flash clock to be between 150kHz and 200kHz. Consider the impact of clock synchronization on function timing accuracy. When the bus clock is lower than 1MHz, no programming or erasing operations can be performed on the Flash.

(2) After configuration is completed, operate the Flash according to the command status of programming or erasing Flash provided by the HCS12 technical specification. It is worth noting that programming or erasing Flash has strict timing requirements. The Flash register must be read and written in the order given in the specification. No other instructions can be inserted in this process, and it cannot be interrupted by other actions. Therefore, the SCI interface of HCS12 is best to work in query mode. If it works in interrupt mode, it must be noted that the interrupt must be turned off before operating the Flash.

4 DSP56858 self-boot mode and its application

DSP56858 has a system integration module (SystemIntegrationModule) in the chip, which is responsible for some system control functions, including generating clocks, reset signals, controlling power-on mode, self-boot mode, external I/O control and other functions. In order to meet different usage requirements, DSP56858 provides 7 self-boot modes, and it will start according to the mode selected by the user after each reset. The difference between different modes lies mainly in the interface for program import and the memory where the program is stored after import.

(1) Bootstrap mode 0 is the external memory import mode (BootstrapFromByte-WideExternalMemory). The external memory is selected by the chip select signal, and the imported program is loaded into the on-chip program RAM for execution. This mode requires the header data to synchronize the boot program and peripherals (the header data includes the total length of the program to be loaded and the starting address of the program in RAM), and then load the program code in 16-bit program words at a time. After the import is completed, the boot program will jump to the starting address to execute the imported program. Please note: If the mode configuration is incorrect or the transmission format does not meet the requirements, the boot program will jump into an infinite loop process.

(2) Bootstrap From SPI mode 1 is to import the program from the SPI interface (Bootstrap From SPI). By default, the program is imported from the serial EEPROM via SPI and placed in the on-chip program RAM. This mode is compatible with ATMEL's AT25xxx and AT45xxx series serial EEPROMs. However, even if there is no ATMEL series chip that meets the requirements, the existing chip can also be used to simulate the working mode of the ATMEL chip and upload the program via SPI. In this mode, the bootstrap program configures its own SPI to the master working mode, and therefore requires the other party's SPI to work in the slave mode. Its hardware connection is shown in Figure 2.

Figure 2 Hardware interface

To determine the chip type, the bootloader will first send a certain amount of null characters at a frequency of about 500kHz, and then require the receipt of the ASCII character "BOOT". If the reception is correct, the bootloader will consider the external device to be an ATMEL small AT25xxx series EEPROM. Otherwise, the bootloader will send a certain amount of null characters at the same frequency. If the "BOOT" character is received correctly at this time, it is considered to be an ATMEL large AT25xxx series EEPROM. If neither of the first two is true, the bootloader will use the same method as above to determine whether it is an ATMEL AT45xxx series EEPROM at a frequency of 20MHz. Therefore, even if there is no ATMEL chip that meets the requirements, as long as the header data can be sent in the manner required by the bootloader, it can be simulated into an AT25xxx or AT45xxx series chip and work in this bootloader mode.

Mode 2 is the normal expansion mode (NormalExpandedMode).

Mode 3 is DevelopmentExpandedMode.

In both Mode 2 and Mode 3, the boot program jumps directly to the external program memory to run.

Mode 4 is the import mode through a single-strobe host (BootstrapFromHostPort-SingleStrobeClocking).

Mode 5 is the boot mode from the dual-strobe host (BootstrapFromHostPort-DualStrobeClocking).

Mode 4 and Mode 5 both import programs in parallel through different types of hosts.

Mode 6 is to import the program through the SCI interface (BootstrapFromSCI). According to the requirements of the bootstrap program, the baud rate of HCS12SCI is configured to 38400bps, the data format is 1bit start bit, 8bit data bit and 1bit stop bit, no parity bit, no hardware flow control. This mode is relatively simple to use. Like mode 0, before transmitting the program, the header data is transmitted first to synchronize the communication between the two parties, and then the program word is transmitted.

5 Conclusion
According to the actual situation, the self-booting problem of ROMless DSP chips can be solved well by combining different methods from the above two steps and selecting the best and most feasible solution. Although the self-booting solution of ROMless DSP chips proposed in this paper is a dual-chip system, it can also be used as a reference solution for solving similar problems in single-chip systems.