Introduction to a DSP program loading technology based on Ethernet BOOTP protocol

　　introduction

　　With the continuous progress of science and technology, network communication technology and DSP technology are developing rapidly. Many intelligent instruments and industrial remote control equipment can be connected to the Internet to achieve networked and intelligent management and control. Among these devices, there are many devices with DSP as the core. The boot and start of the program code of these devices is a very important issue. The traditional program loading method of DSP devices is completed through hardware emulators, but in actual industrial applications, this method has the disadvantages of inconvenient emulator portability and inconvenient equipment software maintenance and update. Therefore, network-based DSP software update is a good solution.

　　This paper introduces the basic principle of DSP program loading. Taking TI's multi-core DSP TMS320C6670 as an example, a DSP program loading technology based on Ethernet BOOTP protocol is implemented. The dynamic loading of DSP program is realized by network communication, which improves the efficiency of software update.

　　1 Principle

　　Here, a traditional PC is used as the download server, and a DSP device with TMS320C6670 as the core is used as the client. After the client is started, it does not know any network information, and needs to use the functions provided by the TCP/IP protocol related protocols IP, UDP, and BOOTP to realize the transmission of information. The client obtains the required related network information through the BOOTP protocol, and then obtains the boot program to be executed through the UDP protocol packet and runs it.

　　1.1 IP protocol and UDP protocol

　　IP (Internet Protocol) is the network layer protocol in TCP/IP. UDP (User Datagram Protocol) is the connectionless protocol of the TCP/IP transport layer. Since the complete TCP/IP protocol will occupy a lot of system resources, the UDP protocol can be used to send data packets in a highly reliable local area network.

　　1.2 BOOTP Protocol

　　When the client starts, it needs to obtain three kinds of information from the network: the local IP address, the IP address of the download server, and the running program to be downloaded.

　　BOOTP (BOOTstrapping Protocol) can obtain all the information required for diskless machines to start up. Before sending a BOOTP request, the BOOTP client does not know its own IP address or the server's IP address, so BOOTP must send the request by broadcasting. After receiving the request, the BOOTP server finds the corresponding response table entry from the download database based on the Ethernet address, forms a BOOTP response, and then responds. For the server, the client's IP address is already known at this time, so it can respond directly without broadcasting.

　　BOOTP message transactions are a round trip of request and response. Only the client knows whether the transaction is successful or not. Therefore, when the server is shut down or the network is not working properly, it will cause transaction errors or message loss, and the client needs to retransmit (retransmit every 3 seconds). When there are multiple responses (multiple server responses or BOOTP response delay), a flag can be set so that the client only accepts and processes the first response and discards the rest.

　　1.3 BOOTP Packet Format

　　The BOOTP packet format is shown in Figure 1.

　　Packet opcode/message type: 1=BOOTREQUEST (boot request), 2=BOOTREPLY (boot reply). Hardware address type: 1=10M Ethernet. Hardware address length: 6 is 10M Ethernet. Number of hops: used for cross-network booting, used by routers. Transaction ID: a random number used to match reference requests and replies. Number of seconds used for client booting: filled in by the client, the number of seconds that have passed since the client booted. Client IP address: The BOOTP client sets this to 0 and requires the server to reply to the client's IP address. Your IP address: The BOOTP client sets this to 0. Server IP address: returned by the server in the boot reply. Gateway IP address: used for cross-network booting. Client hardware address: the client fills in the local MAC address. Server host name: used for cross-network booting. Boot file name: set to 0 in the BOOTP request, and a specific running program path name will be filled in by BOOTPTAB when the server replies. Standard options field: This field is used by the BOOTP client to obtain a series of standard options from the server, such as the network management IP address, gateway IP address, DNS domain name server IP address, client name, etc.

　　1.4 Ethernet Packet Format

　　The Ethernet request packet format is shown in Figure 2.

　　DIX Ethernet contains the destination MAC address (usually FF:FF:FF:FF:FF:FF) and the source MAC address (i.e. the MAC address of the device itself). IPV4 contains the version number, length, protocol, checksum, source IP address and destination IP address (here the IP addresses are all 0.0.0.0). UDP contains the source port, destination port, length and checksum.

　　The Ethernet boot packet format is shown in Figure 3.

　　2 Hardware Design

　　The system uses a multi-core TMS320C6670 DSP chip as the main control chip, which has a built-in gigabit network coprocessor, so the peripheral circuit only needs to add a physical layer chip. The structural block diagram is shown in Figure 4.

　　3 Download Implementation Process

　　Client: When the hardware is reset, before the RESET signal rises, configure the DIP switches SW3, SW4, SW5, and SW6 on the development board to determine that the TMS320C6670 chip is in Ethernet boot mode. RBL (ROM BootLoader) configures SerDes, SGMII, and PASS to receive boot packets from the Ethernet interface. RBL configures the sending channel to send Ethernet request packets (sent every 3 seconds).

　　The server, i.e., the PC, uses Wireshark as the packet capture software, and the Ethernet request packet is broadcast to the server, as shown in Figure 5. It can be seen that the BOOTP packet is broadcast once every 3 seconds by multiple clients.

　　FIG6 shows the main contents of the Ethernet request packet, which is consistent with the Ethernet request packet format described in the principle, including DIX Ethernet, IPV4, UDP protocol and BOOTP protocol packets.

 

　　The server receives the BOOTP protocol packet and obtains the MAC address of the client. At this time, ARP (Address Resolution Protocol) address binding is required. After completing the above two steps, the frame file is sent to the client through the host computer communication program. Figure 8 is a captured UDP sending diagram.

　　

 

　　Figure 9 shows the Ethernet boot packet content.

　　When the frame file is sent, the client processes the received data, finds the data part, and starts loading.

　　The target file generated in the CCS development environment is *.out, which is the Common Object File Format (COFF). This file can be downloaded to the DSP target board through the simulator in the CCS development environment for debugging, but the code file is not the actual program code running in the DSP . It needs to be converted into a boot table file using the Hex tool (hex6x.exe), and then converted into an Ethernet boot format data file using bconvert64x.exe and bootpacket.exe, and encapsulated into a frame file.

　　Conclusion

　　This paper introduces a DSP bootloader technology based on Ethernet . This technology has unique advantages and good application prospects in engineering application fields such as program boot and system software update of multi-core high-performance DSP systems. It has been successfully used in software update of network video surveillance systems. Practice shows that this bootloader technology is flexible and reliable, and provides convenience for debugging and updating of remote control systems.