DSP二级引导程序的设计与实现.pdf资源-CSDN文库

共3个文件

pdf：2个

asm：1个

5星 · 超过95%的资源需积分: 16 164 浏览量 2010-03-10 16:13:08 上传评论 4 收藏 297KB RAR 举报

在嵌入式系统中，Digital Signal Processor（DSP）是一种专门设计用于执行数字信号处理任务的微处理器。在本文中，我们将深入探讨“DSP二级引导程序的设计与实现”，这是嵌入式系统开发中的一个重要环节，特别是在TI（Texas Instruments）的DSP芯片上。引导程序是系统启动时运行的第一段代码，它负责初始化硬件、加载操作系统或更高层次的引导加载器。对于TI DSP，引导程序分为一级引导和二级引导两个阶段。一级引导通常存储在硬件特性更简单的存储介质上，如OTP ROM或EEPROM，其任务是加载二级引导程序到内存中。二级引导程序则更为复杂，通常存储在速度更快但需要CPU支持读取的存储器，如NorFlash。 "boot.asm"文件是用汇编语言编写的二级引导程序源代码，汇编语言是底层编程的一种，直接对应机器指令，对于理解硬件行为非常有用。在TI DSP中，二级引导程序通常包括以下步骤： 1. **硬件初始化**：初始化CPU寄存器、时钟、中断控制器和其他必要的外设，为后续操作做好准备。 2. **内存检测**：检查可用的RAM空间，确保其正常工作。 3. **加载映像**：从NorFlash中读取应用程序或操作系统映像，并将其加载到DSP的RAM中。这可能涉及到理解特定的文件格式，如Intel HEX或BIN文件。 4. **校验和验证**：为了确保加载的数据的完整性，二级引导程序会计算加载映像的校验和并与预期值比较。 5. **跳转执行**：一旦映像加载并验证成功，引导程序会将控制权转移到应用程序的入口点，开始执行。 TI提供的文档详细阐述了这个过程，包括如何配置引导程序以适应不同类型的NorFlash设备，以及如何优化加载速度。国内文档可能提供了针对中国开发者更接地气的实践经验和注意事项，帮助读者更好地理解和应用TI的指导。在实际开发中，根据具体的应用需求，二级引导程序还可能包含其他功能，如固件升级机制、安全特性等。例如，它可以支持在线更新，允许通过网络或串口接收新的固件版本，并在确认后替换旧的映像。在压缩包中的"DSP boot"文件可能包含了一些示例代码、配置文件或其他相关资源，这些可以帮助开发者了解和实现TI DSP的二级引导过程。在学习和实践中，理解汇编语言、熟悉TI DSP架构和开发工具，以及掌握存储器接口知识是必不可少的。设计和实现DSP二级引导程序是一项技术性强、要求高的任务，需要对硬件、软件以及两者间的交互有深入理解。通过阅读和研究提供的资源，开发者可以掌握这一关键技能，从而更好地进行嵌入式系统的开发工作。

资源推荐

资源详情

资源评论

收起资源包目录

DSP boot.rar （3个子文件）

DSP boot

boot.asm 2KB

DSP二级引导程序的设计与实现.pdf 240KB

2004JUN16_DSP_MEM_AN01.pdf 260KB

Application Report

SPRA999 − February 2004

Creating a Second-Level Bootloader for FLASH

Bootloading on TMS320C6000 Platform With

Code Composer Studio 2.2

Kimberly Daniel

Shivashankar Gangadhar

Digital Signal Processing Solution

ABSTRACT

In many DSP applications there is a need to copy code and/or data from one location to

another at boot. C6000 DSPs offer three types of boot configurations: no boot process, ROM

boot process, and host boot process. The most commonly selected boot configuration is the

ROM boot process. When ROM boot is selected as the boot configuration, 1K byte (on

C621x/C671x/C64x) of code will automatically be copied from CE1 to address 0 by the

EDMA following the release of /RESET while the CPU is stalled.

DSP applications are not limited to 1K byte of code. In the event the application size exceeds

1K byte, a custom boot routine will need to be developed to copy the additional sections of

code not copied by the ROM boot. The custom boot routine is referred to as the second level

bootload, or the secondary bootloader. This application note describes how to create a

secondary bootloader by converting a RAM-based application to a flash-based application.

This was done by migrating a C6000 DSP-based DSP/BIOS application developed on the

Code Composer Studio development environment to an actual embedded product. This

application note will use DSP/BIOS Reference Framework Level 3 (RF3) example to illustrate

flash booting on a dsk6713 board. The appendix of this application note also provides an

example of a secondary bootloader for a non-BIOS application. Code for both the DSP/BIOS

and non-BIOS examples are available for download with this application note.

Contents

1 Introduction 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1 Second-Level Bootload Considerations 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 COFF Section Placement 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Building and Linking the Application 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 Writing the Custom Boot Code 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.5 Burning the Application into Flash 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Bootloading a DSP/BIOS Application 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 DSP/BIOS Memory Configuration for ROM Booting 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 Defining Memory Segments 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.2 Memory (COFF) Section Placement 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Building the Application 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1 Build Options 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2 Linker Command File 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Trademarks are the property of their respective owners.

SPRA999

Creating a Second-Level Bootloader for FLASH Bootloading on TMS320C6000 Platform With Code Composer Studio 2.2

2.3 Writing the Secondary Bootloader 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.1 The Section Copy Table 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4 Programming Flash 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4.1 Hex Conversion Utility 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4.2 Flash Burn Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

3 Tips for Debugging 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 References 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix A 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.1 C620x/C670x Bootloader 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2 Bootloading a Non-BIOS Application 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2.1 Defining Memory Segments 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2.2 Memory (COFF) Section Placement 20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2.3 Creating the Section Copy Table 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Figures

Figure 1 Start-Up Sequence of Application which Uses Secondary Bootloader 3. . . . . . . . . . . . . . . .

Figure 2 Load/Run Address Specification Using DSP/BIOS GCONF Interface 8. . . . . . . . . . . . . . . .

Figure 3 Boot Code 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4 Flash Programming Sequence 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5 Hex Command File 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6 Hex Command File using the –boot Option 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure A−1 Non-BIOS Memory Segment Definition 20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure A−2 Non-BIOS Memory Section Placement 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Tables

Table 1 Memory Section Definitions 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 2 DSP/BIOS Sections and Suggested Memory Placement 7. . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 3 Copy Table Format 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 4 Hex Utility Boot Options 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Introduction

In many DSP applications there is a need to copy code and/or data from one location to another

at boot. C6000 DSPs offer three types of boot configurations: no boot process, ROM boot

process, and host boot process. The boot process that is selected is determined by the

configuration of the BOOTMODE pins. Refer to the device specific data sheet to learn about the

boot modes supported by a particular device and configuring the device for a particular boot

mode.

The most commonly selected boot configuration is the ROM boot process (also referred to as

the on-chip bootloader in this document). When selected, the ROM boot process copies a fixed

amount of memory located at the beginning of the external ROM to address 0 using the

DMA/EDMA controller. The transfer is automatically completed as a single frame block transfer

from ROM to address 0. This transfer occurs when the device is released from external reset

while the CPU is internally stalled. Upon completion of the block transfer the CPU is released

from the stalled state and starts executing from address 0.

SPRA999

Creating a Second-Level Bootloader for FLASH Bootloading on TMS320C6000 Platform With Code Composer Studio 2.2

The ROM boot process differs between specific C6000 devices.

• 620x/670x DMA copies 64K bytes from CE1 to address 0

• 621x/671x/64x EDMA copies 1K bytes from beginning of CE1 to address 0.

Application size determines whether the on-chip bootload facility is sufficient or whether there is

a need for a secondary bootloader. If the application size is less than the size copied by the

ROM boot, then a secondary bootloader (custom boot code) is not required. Typically,

621x/671x/64x applications need a secondary bootloader because the application size is greater

than the 1K bytes of memory copied by the on-chip bootloader.

In the applications that require a secondary bootloader, this custom boot code usually resides at

the beginning of ROM memory so that it can be automatically transferred by the on-chip

bootloader to internal memory, address 0. Once the transfer is complete, the CPU begins

executing from address 0 and therefore runs the custom boot code. The secondary bootloader

then copies the rest of the application into RAM. Figure 1 shows the sequence of events that

occur when the application is bootloaded using a secondary bootloader.

_c_int00

C Runtime environment

initialization BIOS_init (DSP/BIOS

scheduler initialization)

CPU Reset

Secondary bootloader copies the complete application

to its runtime memory location. At completion, the

secondary bootloader code branches to _c_int00

Device Reset

ROM boot process copies a fixed amount of memory

from the beginning of CE1 space to address 0

(the memory copied is the secondary bootloader)

main()

DSP/BIOS Scheduler

Figure 1. Start-Up Sequence of Application which Uses Secondary Bootloader

SPRA999

Creating a Second-Level Bootloader for FLASH Bootloading on TMS320C6000 Platform With Code Composer Studio 2.2

1.1 Second-Level Bootload Considerations

As discussed above, ROM booting is the preferred boot method for many of the C6000

applications. If the ROM boot mode is selected and a secondary bootloader is required, then

several things must be considered:

• COFF section placement

• Building the application

• Writing the custom boot code (secondary bootloader)

• Burning the application into flash

1.2 COFF Section Placement

A COFF section is a block of code or data that occupies contiguous space in the memory map.

COFF sections are of three types, namely code, initialized data, and uninitialized data. Each

COFF section has a load and a run attribute. The load attribute of a section tells the loader or

Flash Burn Utility where to place the section following the project build. The run attribute of a

section specifies where the section will execute from when the device comes out of RESET.

Therefore, if different load and run addresses are specified for a section, the section must be

copied from the load address to the run address by the secondary bootloader.

Consider the example below:

.text: LOAD = FLASH, RUN = IRAM

In the above case, .text is placed in flash and then copied to IRAM by the secondary bootloader

during boot. All references to the .text section in the program application refer to its run address

of IRAM. Each section with a load address in flash ROM forms part of the load image. For ROM

booting, the load image consists of sections of code and initialized data.

Determination of the run address of a section is based on how frequently the CPU accesses that

particular section. If a section is accessed only once by the CPU then typically it will not have a

run address in RAM. This will save RAM space for other purposes. For example, the .cinit

section which is accessed only once during boot, typically will have a load as well as a run

address in flash. Sections that need faster access by the CPU will have a run address in RAM.

The secondary bootloader is responsible for copying all the sections from their load space to

their run space if a particular section has different load and run addresses. All the un-initialized

data sections are placed in RAM and these sections will have the same load and run address.

Refer to the TMS320C6000 Assembly Language Tools User’s Guide (SPRU186) for more

details on COFF section description and load run specification. Table 2 gives a list of DSP/BIOS

sections and suggested memory placement.

SPRA999

Creating a Second-Level Bootloader for FLASH Bootloading on TMS320C6000 Platform With Code Composer Studio

2.2

1.3 Building and Linking the Application

After the project build, the linker will generate a map file that contains the section link information

that can be used to determine the location in memory where each section was placed. The map

file contains information such as the size of the section, the load address, and the run address.

An excerpt from a map file will look similar to the following:

.bios

90005600 00001f00 RUN ADDR = 800063e0

90005600 00000700 biosi.a62 : swi.o62 (.bios)

90005d00 00000540 lnkrtdx.a62 : rtdx.o62 (.bios)

90006240 00000400 biosi.a62 : hwi_disp_asm.o (.bios)

90006640 00000300 : prd.o62 (.bios)

90006940 00000280 : rta.o62 (.bios)

This says that the .bios section is 0x00001f00 bytes long, has a load address of 0x90005600,

and a run address of 0x800063e0. This information is needed to create the custom boot code.

The map file also contains detailed information about memory sections, sub-sections, and

symbols.

1.4 Writing the Custom Boot Code

Once the project has been built and linked, the custom boot code should be written. The custom

boot routine is typically written in assembly language because the C environment is not

initialized at boot-time. The following is a list of tasks usually performed by the custom boot

code:

1. Configure the PLL. This step is recommended for C6x devices that have a software

programmable PLL in order to improve boot performance.

2. Configure the EMIF to access external memory.

3. Copy the initialized sections from the ROM to the memory location specified by the

section’s run address.

4. Call _c_int00().

Once the custom boot code is complete, it should be included in the project and the project

should be re-built. Section 2.3.1 contains sample secondary boot code.

1.5 Burning the Application into Flash

Applications built in Code Composer Studio will be of COFF format (.out). Flash burn utilities

(ROM programmers) typically accept the file in ASCII hexadecimal format, therefore the

application COFF format output executables need to be converted into .hex format using a hex

conversion utility before burning the flash. This can be accomplished by using the hex

conversion utility that is provided with Code Composer Studio.

评论收藏

内容反馈

flounding001

2012-11-30

很有用的资料，可以帮助理解底层

bobosky1008

粉丝: 4
资源: 3

DSP二级引导程序的设计与实现.pdf

DSP二级引导程序的设计与实现

TMS320DM642 DSP二级引导程序的设计与实现

ARM DSP结构设计与实现.pdf

多DSP并行处理器的设计与实现.pdf

基于线性光耦HCNR200的DSP采集电路设计与实现.PDF

c语言的tms320c6000 二级引导程序

dsp升级，引导rom

系统引导程序的设计与实现.doc

基于Mpc823e的引导程序分析和实现.pdf

系统引导程序(Boot-loader)的设计与实现.docx

TMS320C6000 DSP系统的引导的设计和实现

用C语言设计程序实现多页程序的引导装载.pdf

DSP原理与应用.pdf

星载高速数据处理单元的设计与实现.pdf

DM642引导加载方式研究及其C语言实现.pdf

基于TMS320C6670_Boot_Loader的研究与实现_陈发堂.pdf

数字鉴相器设计与DSP实现.pdf

基于ARM的TMS320C6455 DSP HPI的动态程序加载设计与实现.pdf

基于FPGA DSP红外目标跟踪设计与实现.pdf

基于DSP的语音数据采集卡设计与实现.pdf

DSP中的一种IC 引导装载方法的设计与实现

双DSP共享Flash程序加载引导设计与实现

基于DSP的嵌入式系统的程序引导设计

基于ARM的引导程序的分析与设计.pdf

基于U-BOOT 的S3C44B0 引导装载程序的设计与实现.pdf

基于OMAP3530硬件平台的ARM和DSP协同开发方法.pdf

基于Blackfin处理器Second-stage Loader的应用程序在线升级技术.pdf

最新资源