tm4c dfu

USB DFU类定义了一些机制，USB设备可以使用这些机制将新的固件应用程序映像写入其内部存储，并可选地将当前的固件映像返回给主机。该类指定了一个功能描述符，DFU设备必须将其作为配置描述符的一部分返回，还指定了一组特定于类的请求，以及控制下载或上传操作的状态机。基本的DFU规范定义了以下操作:

USB DFU类定义了一些机制，USB设备可以使用这些机制将新的固件应用程序映像写入其内部存储，并可选地将当前的固件映像返回给主机。该类指定了一个功能描述符，DFU设备必须将其作为配置描述符的一部分返回，还指定了一组特定于类的请求，以及控制下载或上传操作的状态机。基本DFU规范定义了以下操作:

•固件映像下载到设备(写操作)

•固件映像从设备上传(读操作)

•设备状态和状态查询但不指定以下操作:

•下载或上传图像的地址选择

•删除Flash块的能力

•检查内存区域被删除的能力

•查询目标设备存储参数的方法(例如，Flash大小和可写区域地址)

虽然规范中没有明确提到这些操作，但是dfu设备制造商通常通过嵌入到下载的二进制数据中的特定于设备的命令来支持它们。在这个实现中，我们注意确保不知道这些二进制命令的主机端应用程序仍然可以使用标准的DFU下载请求将适当包装的二进制文件下载到设备。

设备操作模式

与大多数设备类不同，DFU类为设备指定了两种行时模式操作模式:运和DFU模式，每一种模式向主机发布一组不同的USB描述符。在运行时模式下，设备使用其普通的USB类描述符进行操作(例如，打印机作为打印机进行操作，而大容量存储设备提供大容量存储设备服务)，但是还发布附加的接口描述符和功能描述符，以公开它支持dfu的事实。在这种模式下，不支持实际的固件上传或下载，但是DFU规范定义了主机如何向设备发出信号，指示它应该切换到第二种模式以准备DFU操作

在DFU模式下，设备不再发布它的标准设备描述符，而是只报告它的DFU功能，所有这些功能都是通过一个接口并使用控制端点端点0来访问的。在此模式下发布的设备描述符通常包含与在运行时模式下发布的描述符不同的产品ID (PID)，从而确保连接的USB主机只有在设备处于DFU模式时才加载DFU设备驱动程序。在此模式下，可以进行固件下载(写)和上传(读)操作。从DFU模式退出时，设备通常会重新引导并运行主应用程序映像，返回到运行时模式操作

在DFU模式下，设备发布以下USB描述符:•设备•配置•接口•DFU功能

设备描述符发布的标准

设备描述符带有分配给设备制造商的供应商ID(对于Tiva示例是0x1CBE)和产品ID，后者通常不同于在运行时模式操作期间发布的ID。对于Tiva USB引导加载程序，使用产品ID 0x00FF。设备描述符的bDeviceClass和bDeviceSubclass字段都被设置为0x00，表明类和子类是在接口级别定义的。

配置描述符

由设备发布标准配置描述符。在DFU模式中，必须将bNumInterfaces字段设置为1，以指示存在单个接口。通过bInterfaceClass设置为0xFE、bInterfaceSubClass设置为0x01、bInterfaceProtocol设置为0x02来标识DFU接口，

接口描述符

通过bInterfaceClass设置为0xFE、bInterfaceSubClass设置为0x01和bInterfaceProtocol设置为0x02来标识DFU接口，发布单个接口描述符。DFU规范允许通过使用多个备用设置来标识设备内存的不同可编程区域，但Tiva USB引导加载程序只支持接口的单个备用设置。

接口不支持端点(bNumEndpoints设置为0)，因为所有DFU通信都是通过缺省控制端点端点0执行的

DFU功能描述符

设备发布的唯一特定于设备类的描述符是DFU功能描述符，它提供了关于设备的DFU能力以及在下载或上传操作期间可以写入或从设备读取的数据块大小的信息。表1显示了DFU函数描述符字段。