工程师学习

获取方法

1】 将下面链接中的文章分享至 朋友圈，保持3小时后截图

→→ 点这里查看文章

2】 将保持3小时的截图发送至下面公众号后台

3】 我们会在收到截图后的48小时内将下载地址通过公众号消息告知你

---

.
.
.
.
.
.
相关文章推荐
.
.

目录

1
初识Bootloader

1.1 一次Bootloader

1.2 二次Bootloader

1.3 DSP上电引导过程

2
关于c_int00

2.1 c_int00完成的工作

2.2 系统初始化

2.3 全局变量初始化

2.4 全局对象构造

2.5 main函数与exit函数的调用

3
CMD文件与DSP存储空间

3.1 MEMORY和SECTIONS指令

3.2 程序与数据“段”

4
Bootloader数据流

4.1 数据流结构

4.2 16-bit数据流

4.3 8-bit数据流

5
FLASH擦写操作 —— FLASH
API的使用

5.1 FLASH操作的重要特点

5.2 FLASH API使用步骤

5.3 FLASH API常用函数使用举例

6
Bootloader设计过程中的9大关键点

6.1 Bootloader程序在升级过程中不被擦除的实现方法

6.2 上电后先进入Bootloader再跳转至main()函数的实现方法

6.3 Bootloader程序作为CCS应用程序工程一部分的实现方法

6.4 Bootloader与上位机形成交互式通信

6.5 Bootloader程序能够对接收数据校验的实现方法

6.6 在数据出错等情况下能够自动重启的实现方法

7
CCS输出文件格式 ——
ASCII-Hex、Intel-Hex与Binary-Hex文件

7.1 CCS配置生成Hex文件的方法

7.2 ASCII-Hex

7.3 Intel-Hex

7.4 Binary-Hex

---

---

6 Bootloader设计过程中的9大关键点

Bootloader开发目标 >>

1） 要求Bootloader程序在升级过程中不被擦除，保证即使升级失败也能进入下次升级流程；

2） 上电后先进入Bootloader程序，在程序接收并存储完毕后进入main()函数；

3） 要求Bootloader程序可以作为CCS应用程序工程的一部分，而不需要将Bootloader程序与应用程序分为两个工程，方便使用；

4） 要求Bootloader与上位机形成交互式通信，Bootloader能够根据从上位机接收到的数据进行数据请求；

5） 要求Bootloader程序能够对接收到的数据进行校验，保证程序的完整性；

6） 要求Bootloader具有一定的错误处理能力，在数据出错等情况下能够自动重启。

6.1 Bootloader程序在升级过程中不被擦除的实现方法

要求Bootloader程序在升级过程中不被擦除，可以有两种方案。

方案一：将Bootloader程序存放在OTP中，该区域具有永不被擦除的特点，但要注意OTP仅仅支持一次烧写，在Bootloader程序初始开发阶段不建议采用该方案。

方案二：将Bootloader程序存放于FLASH的某一固定扇区（如Sector A），每次烧写程序时，不擦除该区域。下面将详细介绍方案二实现时的关键问题。

Key Point 1 >> 扇区A的划分

使用CMD文件对FLASH A扇区进行单独划分（CMD文件的使用方法参照《CMD文件与DSP存储空间》），将扇区A与其他区域隔离开，对于TMS320F28035，扇区A的地址范围为0x3F 6000 ~ 0x3F 8000。而扇区A内部的详细划分，建议包括以下内容：

1） 密码保护区（CSM_RSVD）与密码存储区（CSM_PWL）：

这部分出厂时就已经定义在扇区A，只需将其空间留出来即可；

2） 起始代码跳转区（BEGIN）：

通过FLASH引导的DSP程序，进入FLASH执行的第一条代码就位于该区域，该区域一般只放置一条汇编跳转语句，大小一般为0x02；

3） Bootloader所要使用的RTS库函数的存储空间（BOOT_RTS）：

Bootloader中要用到诸如exit、atexit、register_lock、register_unlock等函数，这几个函数必须固定在扇区A的某个区域；

4） Bootloader中对时间敏感的函数存放区：

Bootloader中要使用到类似Delat_us的延时函数；

5） Bootloader核心程序的存储空间：

该区域用于存放Bootloader的所有程序，占用空间较大。

而在扇区A以外，需要有应用程序开始指令存放区，如：

6） 应用程序入口区（APP_START）：

该区存放一条跳转指令：“LCR _c_int00”。

Key Point 2 >> 扇区A的擦除保护

当我们在向FLASH写入程序数据之前，需要对FLASH先进行擦除（擦除方法参考《DSP FLASH擦写操作——FLASH API的使用》）。使用Flash_Erase()函数时，第一个参数排除SECTORA，采用：

SECTORB|SECTORC|SECTORD|SECTORE|SECTORF|SECTORG|SECTORH

另一方面，在写入数据时，建议对数据存储地址进行判断，将位于扇区A（0x3F 6000 ~ 0x3F 8000）的数据忽略，防止改变A区数据。

6.2 上电后先进入Bootloader再跳转至main()函数的实现方法

Key Point 3 >> 更改BEGIN区的跳转指令

通常在TI的示例工程中，有个名为“xxx_CodeStratBranch.asm”的文件，该文件中包含一条跳转至c_int00的汇编语句，该语句被存放在BEGIN区（详细说明参考《DSP Bootloader设计（之）关于c_int00》）。在Bootloader实现时，需要将该文件中的跳转指令“LB _c_int00”，修改为“LB _BootEntry”（BootEntry为Bootloader程序入口，这里仅为示例，可根据需要自定义名称）。至此，程序跳转进入Bootloader。

Key Point 4 >> 进入Bootloader后的第一件事情

进入Bootloader后，由于C语言环境并未被初始化，需要有一段用汇编语言编写的C语言环境初始化的代码，该部分代码的详细内容与c_int00函数相同，具体参照《DSP Bootloader设计（之）关于c_int00》实现。

但与c_int00不同的是最后一条跳转指令不再是“LCR _main”（跳转至main函数），而是修改为跳转至Bootloader开始接收数据的部分，例如“LCR _BootBegin”，从而顺利执行Bootloader核心代码，这也是重写C语言环境初始化的代码的原因。另外一个重写C语言环境初始化的代码的原因是是Bootloader一直存在于扇区A，而位于其他扇区的main函数位置可能会因为编译而改变，因而“LCR _main”指向的地址将会不正确。

Key Point 5 >> 如何进入main函数

在程序的数据流中，会有明确表明程序的起始位置（c_int00的地址），参考《DSP Bootloader设计（之）关于c_int00》，因而需要在程序接收完毕后，由Bootloader给出一条入口函数调用指令，该指令跳转至扇区A以外的应用程序入口APP_START区，APP_START区存放一条跳转指令：“LCR _c_int00”。这样程序将会执行RTS库中的c_int00函数，而该函数在末尾会跳转至main函数。

6.3 Bootloader程序作为CCS应用程序工程一部分的实现方法

当Bootloader与应用程序作为同一个工程时，会牵扯到程序跳转的问题，该问题在上一节中已给出解决方案。但存在另一个难点：即Bootloader虽然与应用程序是同一个工程，但每次在线升级时，位于FLASH扇区A的Bootloader程序不会被更新，仅仅更新其它扇区的应用程序。这样导致的问题就是Bootloader与应用程序其实是两部分独立的程序，但二者之间需要相互跳转，这时就需要二者之间的接口绝对地址不变。

Key Point 6 >> Bootloader对外接口地址的固定方案

Bootloader对外的接口有：

1） 应用程序调用Bootloader的升级入口：

该入口为C语言环境初始化的开始地址，该地址已由Bootloader核心程序的存储空间划分时确定；

2） Bootloader跳转至应用程序的接口：

该接口就是Key Point 5中所提及的在程序接收完毕后由Bootloader给出的一条入口函数调用指令，该指令指向地址始终是APP_START区开始地址。

6.4 Bootloader与上位机形成交互式通信

建议Bootloader与上位机之间的通信形式采用交互式通信：即Bootloader先请求数据-上位机后发送数据的形式，而非单纯的由上位机单向向Bootloader发送数据，这样可以避免数据传输过程中的大部分错误。

Key Point 7 >> Bootloader与上位机的交互方法

该部分需要了解《DSP在线升级的Bootloader数据流》的内容。基础通信形式可以根据需求自定，例如SCI，CAN等。交互内容一般应包括：

1） 握手：完成Bootloader与上位机的首次通信；

2） 请求Boot Table数据流的头部信息，依据格式甄别数据与某地址及某数据长度等内容；

3） 依据甄别出的内容向上位机请求某地址及某数据长度的数据；

4） 向FLASH某地址写入接收到的数据；

5） 循环2）3）4）动作，直至Boot Table数据流结束。

6.5 Bootloader程序能够对接收数据校验的实现方法

Key Point 8 >> Bootloader数据校验

为了保证接收到的数据的正确性，需要对数据流进行校验，一般的校验方法为：

1） 数据流发送端（上位机）在发送数据流之前或者发送之后，依据数据流基本格式对数据的有效部分进行某种方式的校验。校验方式可以采用CRC校验或着求和校验，但需要注意仅仅对有效数据进行校验，地址、长度等无效数据需要被排除，另外CRC校验与数据顺序有关，需要在校验前对数据进行地址排序；

2） 而对于DSP端（Bootloader），需要做的是将已经接收完毕写入FLASH的数据读出，并采用与上位机同样的校验方式，CRC校验或着求和校验，得出校验值，并将校验值与上位机给出的校验值进行比较。

3） 需要注意的是，由于本Bootloader方案中FLASH扇区A是受保护不能被更新的，因而在校验过程中需要将该区域的数据排除在外。

6.6 在数据出错等情况下能够自动重启的实现方法

Key Point 9 >> Bootloader出错重启功能的实现

1） 看门狗需要在Bootloader过程中开启，并在多次执行或耗时间的程序块中“喂狗”，从而达到Bootloader程序跑飞时的重启；

2） 当出现诸如数据流校验错误、FLASH擦写等错误时，需要软件重启DSP，这时可以利用看门狗喂狗指令错误的方法达到软件重启的目的：