手机端¶
FAQ1 ota后（手表重启后）app回连手表无法连接¶
这个目前只在IOS系统遇到过，iOS 在刚打开蓝牙中心连接手表时，手表可能会disable service,手机端会收到 serviceModified 事件，在这个事件之后重新发现服务。 app 里面有轮询检查连接状态，当前失败了，也可以下一个轮询机会再连接。
原因：思澈手表固件ble连接后，会跟新服务参数。app连接后立马来发现，就会出现发现服务超时/异常。
FAQ2 iPhone8以前的frequency可以设成5(这个会出现ble传输异常，app不发数据导致手表主动断连)¶
原因：在早期的iphone手机上，它不支持持续的写入20个数据切片，固件端收包错误，断开连接。
判断一下机型低于等于iphone 8，把回复频率降低到5能得到改善。 iphone出现组包异常时，也可以适当降低默认的frequency 参数，来提高稳定性。
FAQ3 手机跟app进度对不上¶
检查手表代码，看使用的是总传输进度，还是单个bin的进度
设备固件进度份两种：
单个bin文件进度:DFU_PROGRESS_PART
单次升级所有文件总进度:DFU_PROGRESS_TOTAL
看app传输的bin文件跟要升级的bin文件是否匹配
有客户出现过全量升级后，app缓存的压缩包没清除。
下次ota时只升hcpu时导致文件异常（多了其他bin文件）。ctrl_packet.bin跟客户要升级的包对不上。
FAQ4 手机有发包，但是没发出来。手表超时15S没收到包主动断连¶
app怎么排查：
看手机log.cat。出问题的事件点，在做些什么。思澈dfu服务可以搜索sifli-DFU标志
看手机hci_log。出问题的事件点，在做些什么
一般是app在ota时有做其他事情，导致发包中断。 也有可能是手机系统宽带被其他外设占用，如wifi，蓝牙播放。
手表超时15S没收到手机的包就会断连，修改建议：要么让手机尽量不去做其他的，要么就把手表的下载超时时间改长，增加容错时间。
FAQ5 升级差分资源失败¶
app提示： load list file fail DFU end with 133
需要检查差分包文件跟list列表里的记录能否对齐，list有重名，但是实际bin文件无法存在重名文件。
FAQ6 ota偶现时间长¶
这是客户经常反馈的问题，这个问题需要抓空中包，手表hci log看是什么影响了传输速度
看ble连接间隔（是不是高速模式没切换成功）建议进入ota时由手机先发起
手表发起的连接参数更新请求，手机不一定响应。
ios跟Android的最小连接间隔也不一样。
app配置的frequency（回包频率）
手机系统宽带被其他外设占用，如wifi，蓝牙播放（这种行为就跟手表没关系，客户行为无法约束）
FAQ7 nand差分包，app里是哪个类型¶
nor方案不支持差分包，不用考虑
NAND方案 :
IMAGE_ID_HCPU = 0,
IMAGE_ID_LCPU = 1,
IMAGE_ID_HCPU_PATCH = 2,
IMAGE_ID_FS_ROOT = 3,
IMAGE_ID_LCPU_PATCH = 4,
IMAGE_ID_FS_DYN = 5,
IMAGE_ID_FS_MUSIC = 6,
IMAGE_ID_NAND_RES = 7, //差分包资源
NOR方案:
DFU_IMG_ID_HCPU = 0， //HCPU代码
DFU_IMG_ID_LCPU = 1， //LCPU RAM 代码，前提是启用了FLASH 4
DFU_IMG_ID_LCPU_ROM_PATCH = 2,
DFU_IMG_ID_RES = 3， //资源
DFU_IMG_ID_FONT = 4, //字体
DFU_IMG_ID_EX = 5,
DFU_IMG_ID_OTA_MANAGER = 6， //升级ota manager本身
DFU_IMG_ID_TINY_FONT = 7, //TINY 字体
NAND方案的IMAGE_ID_NAND_RES容易跟NOR方案的DFU_IMG_ID_RES搞混
Android nand差分包类型如下图所示
ios nand差分包类型如下图所示
