了解bootloader 的实现，请加QQ: 1273623966 （验证填 bootloader）；欢迎咨询或定制bootloader；我的博客主页www.cnblogs.com/geekygeek
最近给我的开发板PIC32MZ EC starter kit写了个USB 在线升级程序--USB CDC bootloader。有了它，我可以很方便的升级我的应用程序。我大概是一个星期前开始决定写这个USB在线升级程序的，USB 有两种类型，USB host和USB device。 USB host接触不多，我决定采用USB device的类型。 USB device有很多种Class， 例如HID， CDC，和MSD等，MSD device不适合做在线升级，HID用来做在线升级很不错，但是PC端需要驱动和专门的上位机。所以我决定采用CDC device， 模拟一个串口，上位机实现也简单。此在线升级程序虽然只是第一版(v 1.0)，但是经过多次测试，一直稳定可靠。
下位机
USB CDC bootloader 的实现很简单，开发环境是MPLAB X， Harmony和XC32. XC32是编译器，MPLAB X是Microchip 的免费IDE， Harmony是Microchip为PIC32架构推出软件framework. 包含了PLIB库文件和很多的示例。我的USB CDC bootloader就是在Harmony中Usb device示例--cdc_com_port_single的基础上实现的。我没有新建项目，而是把整个示例项目从安装路径中复制出来，改掉项目名（从cdc_com_port_single.X 改成 cdc_bootloader.X)。
很奇怪的是，每次使用MPLAB X打开这个改名后的工程，都有Project Loading Error。 错误提示是： Error: Project "cdc_bootloader" refers to file "bsp_config.h" which does not exist in the disk. The project failed to load. 但是编译却没有问题，估计是工程改名的后遗症，由于不影响编译，所以目前没有去深究。
我是在复制出的示例工程中的app.c中添加cdc bootloader代码的， 第一版实现，我力求简单。所以bootloader的实现基本上和“ 自己用C语言写PIC32 serial bootloader " 这篇博文中的实现是相似的。目标板上电后，都是先进入bootloader程序，进入bootloader程序后，之前是等待一小段时间，如果没有更新程序的请求，就跳转到应用程序，如果有更新程序的请求，就去更新应用程序。目前的做法稍有不同，是检查SW1按键有没有按下，SW1有按下，就去更新应用程序，SW1没有按下，就跳转到应用程序，具体可以去看“ 自己用C语言写PIC32 serial bootloader " 博文（里面含有部分的代码）。我的这种bootloader实现方式和我的其他bootloader实现方式还有一个不同的地方在于，不需要写专门的上位机，直接使用超级终端或相同功能的终端软件就可以。
USB CDC bootloader改完后，编译，烧写到我的PIC32MZ EC Starter Kit，然后USB 线一头接电脑，一头接PIC32MZ EC Starter Kit。 打开电脑的设备管理器， 发现了一个未识别的USB device， 使用Microchip提供的INF文件就可以让电脑识别这个USB device，之后每次接上我的PIC32MZ EC Starter Kit都可以识别成COM8这个设备。到这里，我就知道我已经成功了一大半了。
上位机
上位机有提到是用的超级终端，现在的Windows系统（WIN 7, WIN 8, WIN 8.1, WIN 10)已经不像之前的WIN XP自带超级终端，需要自己到网上去下载。使用超级终端的发送文本文件的功能，但是发送前要选好COM口，比如我的是COM8, 选好baud rate, 比如我的是9600。 选好8数据位和1个停止位。还有一个重要的设置是Line Delay。 发送文本文件是发送原文，每发送一行内容，就停止Line Delay定义的时间，然后再发下一行，直到结束。
升级步骤
升级时的步骤如下
1. 重启烧录好cdc bootloader的目标板
2. 立即按下SW1按键，直到USB device 完成Emulating (这个是通过LED来指示Emulating完成)。
3. 打开超级终端，设置好COM口，baud rate, 和 Line Delay等 (这一步必须在USB device的Emulating完成后)。
4. 单击发送 / 发送文本文件...， 选择要发送的hex文件。
5. 等待升级完成，bootloader每接收完一行都会原文返回，所以你可以在超级终端看到以下内容。
...
...
:020000040000fa
:020000041d00dd
:101a74000000023c00004224050040100000023c2b
:101a84000000422403004010009d023c3f0000700f
:101a9400009d023cbc1a42240500401000000000d6
:101aa400e8ffbd271400bfaf09f8400000000000a4
:081ab400ad06400b000000002c
:020000040000fa
:020000041d00dd
:101abc0000606041c000000099aa033c80bf023c5a
:101acc0055666324300040ac300043ac6655033c93
:101adc00aa996334300043ac80bf023c010003245c
:101aec00581243ac80bf023c5012428cb106400be2
:041afc0000000000e6
:020000040000fa
:020000041d00dd
:1011e40000601a40bfff1b3cffff7b3724d05b032a
:0811f40000609a40180000425f
:020000040000fa
:020000041d00dd
:0810ec000800e0030000000011
:020000040000fa
:020000041d00dd
:0810f4000800e0030000000009
:00000001FF由上可知，本实现方式，上位机只是hex原文发送，cdc bootloader接收hex，分析里面的内容，checksum检查，提取里面的地址和BIN数据，然后再完成烧写。很多脏活累活 都是在下位机里面完成。计划开发一专门的上位机程序，不用超级终端，然后脏活累活由上位机来完成。升级USB cdc bootloader到v2.0，并且会增加以下特性：
1. 握手协议
2. 通信协仪
3. Checksum检查
4. 应答机制
5. 纠错机制， 如果通信中出错，上位机允许重发三次。
6. 一致性确认，烧写后，bootloader会读出数据和写入的数据比较。
所有这些完成后，那么我的cdc bootloader的可靠性和效率都会更上一层楼。