如果按键没有按下，GPREGRET1不为0xB1，本次复位不是上次DFU的继续，并且应用程序校验通过，那么BootLoader就会直接跳到application，去执行application应用程序。那怎么去校验应用程序的有效性呢？为此BootLoader引入了一个放在Flash的结构体参数：m_dfu_settings_buffer（数据类型：nrf_dfu_settings_t），这个结构体参数虽然只有896字节，但由于Flash只能按页擦除，所以这个参数实际占用了一个Flash page，这个page称为settings page，settings page放在Flash的最后一个页面，settings page目前有2个版本：版本1（SDK15.2及以前版本）和版本2（SDK15.3及以后版本），版本2可以兼容版本1，前面所述的896字节是指settings page版本2的大小。Settings page包含的信息比较多，大家用得比较多的是：
各种版本信息
DFU升级过程信息
Application image的CRC值和大小
应用程序的bonding信息
Init command内容
application/softdevice的启动校验信息（版本2才有）
版本1的settings page只校验application image的CRC值，如果CRC匹配，则认为application有效。版本2的settings page不仅可以校验application image的CRC值，还可以校验application/softdevice的CRC值或者hash值或者签名，你可以选择你自己想要的校验方式，只有CRC值或者hash值或者签名校验通过（三选其一），应用程序才算有效，这时BootLoader才会跳到application去执行。为了保证settings page在发生意外时，比如写settings page过程中发生了复位或者掉电，系统也能正确恢复，SDK15及以后版本引入了一个backup page，backup page也占用一个Flash page，内容和settings page一模一样。
上面是没有触发升级的情况下nRF52的正常启动流程，那如果要执行DFU升级，流程又是怎么样的呢？下面详细讲一下无按键式BLE OTA的工作流程。
1) 正常启动后，系统运行在应用程序中，此时手机通过app发送一条开始DFU的指令给设备，设备收到指令后，将GPREGRET1赋值0xB1，并触发软复位
2) 复位后，系统再次进入BootLoader，因为GPREGRET1等于0xB1，BootLoader进入DFU模式，等待新固件接收
3) 手机先将init packet发送给设备，设备先做前期检验prevalidation，主要是各种版本校验以及签名验签，校验通过后，更新settings page并准备开始数据接收
4) 接收新固件。每接收4kB数据，回复一次CRC校验值，直至整个新固件image接收完毕，如果新固件校验通过（版本1校验CRC值，版本2校验hash值），就会去invalidate（无效化） bank0里面的老固件，更新settings page，并再次触发软复位
5) BootLoader启动后发现有新固件需要activate（激活），此时会去擦掉bank0里面的固件，并把bank1里面的固件拷贝到bank0，然后更新settings page，并再次触发软复位。注：上面讲的是dual bank的流程，single bank与之相似，只不过在第3）步的时候就会去擦除老固件
6) BootLoader再次启动后，检查新image的有效性，校验通过后，跳到新的application去执行代码
从上面流程可以看出，DFU过程中，系统需要跑两段完全独立的代码：Application和BootLoader，Application和BootLoader都支持蓝牙功能，也就是说，两者都有自己的蓝牙广播和蓝牙连接。这里面有一个问题：当系统从Application跳到BootLoader后，手机怎么辨别两者为同一个设备？很多人会说，可以让BootLoader和Application两者的广播名字一样，根据广播名字的一致性，来判断二者来自同一个设备。这种方法存在两个问题：一大部分手机都支持GATT cache（缓存）功能，当application跟手机相连后，手机会把application的GATT数据缓存下来以加快下次连接的速度（这个现象在苹果手机最明显），之后如果系统跳到BootLoader，然后再跟手机相连，如果两者的蓝牙设备地址一样，手机会认为是同一个设备，从而跳过服务发现的过程而直接使用之前缓存下来的GATT数据，这样会导致BootLoader的服务无法被手机发现，从而出现升级失败。二如果多个设备同时在升级，而我们仅仅依靠广播名字来决定两者属不属于同一个设备，这会导致设备A application有可能跟设备B的BootLoader进行错配。为了解决这个问题，Nordic提出了两套方案。方案一，假设application的蓝牙设备地址为x，跳到BootLoader后蓝牙设备地址会变成x+1，这样手机就可以通过这种地址+1的方式来辨别两者属不属于同一个设备，由于application和BootLoader使用不同的蓝牙设备地址，前面的GATT缓存问题也就不存在。关于方案一，有一个问题需要特别注意：如果你想修改例子默认的蓝牙设备地址（比如使用IEEE的public蓝牙MAC地址），此时一定要记得同时更改application和BootLoader的蓝牙设备地址，使他们满足+1的条件，否则Nordic手机DFU库无法辨别两者是否属于同一个设备，以致于无法完成OTA过程。方案二，application和BootLoader的蓝牙设备地址一模一样，但设备跟手机执行配对和bonding操作，设备跟手机bonding后，就可以支持service changed indicate操作，这样跳到BootLoader后可以让手机主动再执行一次服务发现过程，从而解决GATT缓存问题。