TM4C123-Bootloader_CAN/UART

引言：本文主要是自己在开发移植CAN flash-based bootloader过程的学习总结。 会对bootloader 的结构和使用进行一定的说明与解释，也会记录自己应用过程中的疑惑点及解决。

1.bootloader概述

TI 的TM4C123系统芯片采用的是arm -cotex M4架构，它有两类bootloader，一类是ROM -based bootloader ,另一类是Flash -based bootloader .

• ROM -based bootloader

这个boot loader 是已经预烧写在内部ROM 中的，可以通过API或寄存器来调用它，但它的方式相对固定，只支持几个固定的外设，不能灵活修改。
调用它的方式一种是通过 ROM_UpdataUART / ROM_UpdateI2C/ ROM_UpdateSSI /ROM_UpdateUSB 等API函数，另一种是配置BOOTCFG 寄存器。
因为不够灵活，我们暂且不使用它。

• Flash-based bootloader

它是通过JTAG预烧录在flash 中的一小段代码，通常烧录在flash 的起始地址0x00000000处，主要是用来烧写应用程序固件。(application Firmware )
这个bootloader 的工作流程大概是： 系统上电后执行复位处理函数，在函数中会有一个check 函数（这是官方例程中的方式，当然也可以依实际情况决定是否采用）–——CheckForceUpdate()，来检测应用程序是否需要更新。 （它是检测程序运行起始地址处前8个字节的值是否是0xFFFFFFFF,如果是0xFFFFFFFF则更新。 这个可以对照理解官方示例代码是先记录下待烧写的前8个字节于数组中，烧写成功应用程序的其余部分后回过头来烧写这8个字节。这样可以保证当后面烧写出错时，系统复位后检测是否更新依然生效，重新等待烧写应用程序。 ）

以CAN bootloader为例，如果检测到需要更新应用程序，则程序依次执行ConfigureCAN()、 UpdaterCAN()进入到更新程序的流程中。
在ConfigureCAN()中主要是执行CAN外设、传输的位速率等配置工作，UpdaterCAN() 是循环等待接收CAN指令来完成烧录和复位运行应用程序等工作。
总结而言， flash-based bootloader就是一小段简单的代码，主要完成的就是配置外设， 然后通过通信协议来接收固件的烧录地址、固件数据包等，在接收到数据包的同时进行校验和flash 烧写工作，达成烧写应用程序的目的。

2.bootloader的移植使用

以can flash-based bootloader为例，关键的代码文件有bl_config.h 、 bl_link.cmd 、 bl_startup.s、 bl_can.c、 bl_can.h bl_flash.c/h(开发环境是CCS）。
此外还需关注的是应用程序的link.cmd文件。

• bl_config.h
  这个文件中主要是一系列宏定义，通过宏定义来配置一些功能是否开启。 最基本的宏定义主要有如下几个：
  CRYSTAL_FREQ , 这个定义晶振频率，程序依靠这个值来配置时钟和位速率等。
  APP_START_ADDRESS, VTABLE_START_ADDRESS 这两个一般定义为相等值， 是程序运行和中断向量表的起始地址，注意应用程序link .cmd文件的APP_BASE要与此处的值配置一样。
  FLASH_PAGE_SIZE,对于TM4C123 internal flash而言， 是1024bytes， 上面提到的几个起始地址值也要注意是1K对齐的
  STACK_SIZE 是预申请的boot loader使用的栈空间大小。
  此外就是 使能用哪一类外设来更新固件，同时配置该外设的基址、外设引脚等。
• bl_link.cmd
  这个与正常应用程序没有差别， flash 的起始地址设为0x00000000, length可根据需要设为0x00001000等值，它表示的是bootloader使用的flash 空间。APP_START_ADDRESS 等值要大于length值。
• bl_startup.s
  官方示例程序中的启动文件较为完整，可以看到工程中不写main .c也可， 因为在启动文件中预定义了一些汇编函数来完成程序的运行和跳转。启动文件在复位处理函数中判断完是否需要更新后， 会依据宏定义来执行相应的configure函数和updater函数，在CAN bootloader中，即为跳转到bl_can.c中定义的ConfigureCAN()、 UpdaterCAN()。
• bl_can.c
  主要是定义了上面提到的两个函数以及CAN消息包的发送及接收处理。 协议处理部分位于UpdaterCAN()中，它也算是整个bootloader 程序的核心功能函数。
• bl_can.h
  定义了消息ID，命令ID等基本内容。
• 应用程序的link.cmd
  主要就是APP_BASE （即flash烧录的起始地址）要更改为与bl_config.h中一致，然后是length要改为flash大小减去APP_BASE后的值。

CAN bootloader 主要的协议指令有
PING : 0 个数据，烧录程序与device PING，收到ACK包表明通信成功
DOWNLOAD，8字节数据， 前4字节是起始地址，后4字节是固件包大小。
SEND_DATA，8字节数据。 （固件包数据，CAN消息一次最多携带8个数据）
RESET， 执行复位，然后程序会跳转到应用程序起始地址。
ACK，接收并处理消息后的回复，表明成功或失败。

3.额外说明

1.串口bootloader 跟CAN bootloader在通信协议上会有一些差别， 官方的LM FLASH Programer软件可以通过 串口bootloader烧写应用程序，要注意传输大小的设置要与 bl_config.h 中设置的 BUFFER_SIZE 一致，否则会通信失败。
2.串口bootloader 发送指令时， 第一个字节是要发送的字节个数，第二个是数据校验和，从第三个数据开始是数据。
所以假设发送一个 0X20 的PING 命令，需要发送的是 0x03 0x20 0x20 ,bootloader 发送回的数据包也是一样的格式。
3.串口bootloader 有一个缓存数组,两个指针四字节对齐来处理对全部数据包的接收和存储有效数据。
g_pui8CommandDataBuffer = g_pui8DataBuffer + 3.

4.关于cortex-m4中程序的运行机制，程序运行时是从flash中拷贝到sram中运行的。
另外，在应用程序的最开始一般是中断向量表vector table, 其中前四个最关键的有：
initial stack pointer
reset handler address
NMI handler address
hard fault handler address.

系统一复位后，处理器先load 栈顶指针， 然后开始执行复位处理函数。 当发生中断处理时，处理器会自动压栈进stack 中（8 项内容）。

bootloader 中 CheckForceUpdate()函数主要检测两点
一是合法的栈顶指针， 0x 2xxx.xxxx
另一个是合法的复位函数处理地址，0x 000x.xxxx

Vectors:
.ref __STACK_TOP
.word __STACK_TOP ;; Offset 00: Initial stack pointer
.word ResetISR - 0x20000000 ;; Offset 04: Reset handler
.word NmiSR - 0x20000000 ;; Offset 08: NMI handler
.word FaultISR - 0x20000000 ;; Offset 0C: Hard fault handler