基于CAN网络BOOTLOADER设计与实现.docVIP

基于CAN网络BOOTLOADER设计与实现 　　摘 要 单片机更新程序一般使用烧写器直接烧写来完成程序的更新下载，这种方法在实际产品使用中更新程序不便，本文提出一种基于CAN网络的在线更新应用程序的解决方案，设计开发了基于CAN网络的bootloader；并从bootloader的软件架构分析了软件实现的原理，对其中关键部分的实现做了较深入的阐述，提出了基于CAN自定义协议的单片机bootloader开发思路，具备一定的通用性。 　　关键词 USB；CAN；BOOTLOADER 　　中图分类号：TP29 文献标识码：A 文章编号：1671-7597（2013）11-0000-00 　　1 系统结构 　　Can-bootloader的实现基于如图1所示系统环境结构。 　　图1 　　其中： 　　USB-CAN转接卡：实现USB总线到CAN总线的协议转换，通过该设备实现BCU的can总线与PC机的数据通信。 　　下位机板卡：运行bootloader软件，接收S19镜像文件。 　　PC机（windows）：运行上位机程序，向BCU发送S19镜像文件。 　　2 通信协议 　　BOOTLOADER通过CAN总线与USB-CAN卡通信，BOOTLOADER通过CAN总线接收从PC机发送过来的S19镜像文件（通过USB-CAN卡）进行BOOTLOADER的flash烧写。 　　整个通信协议基于文本传输格式的异步文件传输协议，PC机和CAN卡之间以128字节块的形式传输数据，CAN卡与BOOTLOADER之间以8字节的形式传输数据，采用应答传输机制来配合USB高速端的流控，CAN卡将PC机传输过来的数据块以8字节发送，发完一整包（128字节）的数据后以ACK的形式通知PC机可以发送下一包数据。 　　2.1 上位机与CAN卡通信协议 　　上位机与CAN卡之间通过USB总线连接，USB-CAN卡被windows识别为普通USB设备，上位机应用程序调用CAN卡的windows驱动程序进行数据读写，数据包长（含包头）最大为128byte。具体实施协议如下所述（USB总线物理层具备CRC校验，所以协议不需对数据进行校验。 　　2.1.1 协议包数据格式 　　协议数据包格式如图2所示。 　　图2 　　其中包长、包序号、标志皆为1byte，数据为0～125byte。具体含义如下： 　　包长：指示本包数据长度 　　包序号：指示本包序列号，第一包序号约定为1，后续序号在0～255间循环。 　　标志：指示本包数据是否为待传输文件的最后一包，若是起始包将标志置1，最后一包将标志置2，其他置0。 　　2.1.2 确认包格式 　　确认包为接收方收到正确的数据后向发送方传输，固定为1byte，值为0x 0x06。#define ACK 0x06。 　　2.2 CAN卡与BOOTLOADER通信协议 　　CAN卡与BOOTLOADER之间数据包长固定为8字节。具体实施协议如下所述： 　　2.2.1 协议数据包格式 　　（每个数据包含有125字节数据） 　　协议数据包格式如图3所示。 　　图3 　　传输文件用到的基本数据包大小为125字节，若待传输文件的大小不是125字节的整数倍，那么最后一包数据报文的长度不足部分需以CTRLZ填充报文。 　　2.2.2 协议相关控制字符 　　（文件以文本格式传送，以下控制字符不占用128个ascii码） 　　SOH 0x01； EOT 0x04 　　ACK 0x06； NAK 0x15 　　CAN 0x18； CTRLZ 0x1A 　　2.2.3 协议传输概述 　　传输启动： 　　协议传输由数据接收方发起，接收方通过向发送方发送NAK报文，发送方收到后进入发送流程。 　　传输过程： 　　当发送方接收到接收方发送的第一个NAK后，发送方进入协议的传输过程，进入传输过程后发送方需将待传送数据按照图3所示数据包格式打包，最后将打包的成帧数据包传送。 　　数据的发送接收采用ACK确认机制，发送方发送一包数据后需等待接收方的确认ACK，收到ACK后发送方才能继续发送数据；若通信的过程中发送方有可能收到NAK或CAN字节的异常处理报文，其中NAK表示接收方请求重发当前报文，CAN字节表示接收方请求停止传输。 　　结束传输： 　　如果收发通信双方传输正常，发送方需向接收方发送EOT字节以通知接受方传输正常结束。接受方收到EOT字节之后需回送ACK进行确认。当然在结束传输的过程中接收方也可以发送CAN字节来强制停止传输（发送方收到CAN字节后不需再发EOT确认）。 　　3 USB-CAN转接卡设计 　　3.1 USB从设备驱动设计 　　USB总线中的通信包含以